Kerberos Token Bloat - Details, Example, Token Size Calculation Tools and Security Implications

Folks,

My apologies for the continued delay in sharing insights. As the CEO of a $B cyber security company that has customers in 6 continents, time has become my biggest constraint. However, this week onwards, I plan to share something valuable every week.

Although we’re primarily focused on helping organizations worldwide address the world’s top cyber security risk, we often get requests from organizations to assist with related issues. A few weeks ago, a world famous Swiss bank reached out to us requesting our assistance in helping them efficiently address the issue of KerberosToken Bloat. (And help them we did.)

The issue of Kerberos Token Bloat potentially impacts the security of every organization running on Active Directory, and thus is worth addressing. So, today, I was determined to take out some time and share a few thoughts with you on this topic.

[NOTE - If you’re short of time, and are looking for an easy/automated way to correctly determine the token size of any/all domain user accounts in your Active Directory, you can skip to the second-last section of this post, or click here.]

The Crux of the Issue

There appear to be many sources of information on this topic online, and many re-hashed blogs, but not too many sources that provide a sufficiently deep technical explanation, so this is my humble attempt to do so. 

• Disclaimer: Kindly note that my core expertise is in Active Directory Security, not in the inner workings of every detailed aspect of Windows Security (which, like the field of medicine, is an ocean of a subject), such as the inner workings of the Kerberos SSP, and I only had 30 minutes to devote to this blog entry, so the Crux session is a best-effort basis presentation put together within the given time constraint.

Full details on this topic could take an entire chapter in a book. However, in the interest of time, I'll attempt to share its crux -

In Microsoft Windows Server environments, the Microsoft Security Services Provider Interface (SSPI) is the foundation of authentication. It lets applications use any of the available security packages without changing the interface to use security services. It also provides a mechanism to carry opaque authentication tokens over the existing communication channel between the client and server. Each network protocol, including Kerberos, is provided in the form of a Security Service Provider (SSP) and the 5 default SSPs in Windows Server - Negotiate (SPNEGO), Kerberos, NTLM, Schannel, and Digest authentication protocols, are all plugged into the SSPI in the form of DLLs.

When two parties (client and server) require authentication for secure communication, their requests for authentication are routed to the SSPI, which completes the authentication process, regardless of the network protocol currently in use. However, before the two parties can use SSPI, they must agree on the security package they wish to use. Once the two parties have agreed on a security package, they can use the SSPI API to establish network authentication.

Most of the SSPI functions have variable length arguments for the caller (application) to provide message data to the security package and for the security package to return security data to the caller.  For example, the caller can use security buffers to pass message data to the security package, or to receive an output security token from the security package.
 
Security buffers can be passed in as an array of buffers. The security buffer descriptor identifies the number of buffers and the starting address of the buffer array. Each security buffer also has a buffer type field to identify the contents of the buffer.
 

Each time a security API is called that takes a SecBufferDesc parameter, it should be setup with one or more SecBuffers. For example, there can be two security buffers, one that contains input message data and the other for the output opaque security token returned by the security package. The order of security buffers in the security buffer descriptor is not important, but they should be tagged with the appropriate type.

 

However, the size of the output buffer that is expected to contain the security token is important.

 

The caller (application) determines the maximum token size for a security package during initial setup by calling the QuerySecurityPackageInfo() function for a specific security package, and using the returned cbMaxToken value.

 

It is based on this value that the application then initializes the buffer pointers and sizes in the buffer description.

 

NOW, as you may know, the default maximum token size for the Kerberos authentication package (i.e. Kerberos SSP) was 8000 bytes in Windows 2000 and is 12,000 bytes in Windows Server 2003/8.

 

As a result, when the caller (application) calls QuerySecurityPackageInfo() function to determine the maximum token size for the Kerberos package, the cbMaxToken value that is returned to the user is 8000 bytes in Windows 2000 and 12,000 bytes in Windows Server 2003/8. It is based on this return value that the caller initializes buffer pointers and sizes.

 

The client and server then each call AcquireCredentialsHandle(), following which the client calls InitializeSecurityContext() and the server calls AcquireSecurityContext(). Under the hood, the Kerberos SSP on the client's machine takes care of requesting a session ticket from the KDC and sending it across to the server, and the Kerberos SSP on the server's machine takes care of receiving and decrypting the ticket. If all's well thus far, the server can then call ImpersonateSecurityContext().

 

Under the hood, during the above, when the KDC receives the session ticket request, it generates and inserts the list of SIDS of all the global, universal and domain local security groups that the user is a member of directly or indirectly, (plus SIDHistory) in the user's Privilege Attribute Certificate (PAC),  which is stored in the Authorization-Data (Optional) field of the service ticket that the KDC issues to the client for submission to the server. (As you may know, strictly speaking, it copies the PAC from the client's TGT into the service ticket's PAC, then adds the list of all DLGs to which the user directly or indirectly belongs, to it.)

 

Then, at the server side, when the Kerberos SSP receives and decrypts the service ticket, it verifies/validates the PAC and then generates and return an output security token via the output buffer that was initialized and provided by the caller (application).

 

Now, remember that the size of this output buffer was based on the value of the maximum token size provided to the caller when it called the QuerySecurityPackageInfo() function to query the cbMaxToken size for the Kerberos package.

 

If the user belongs to a large enough number of groups, the amount of memory needed for the output security token (containing the SIDs of all the security groups to which the user belongs) will exceed the amount of space allocated for the output buffer, and thus the authentication request will fail, and as a result, the user will not be able to successfully logon.

 

In essence, the crux of the issue is that the amount of memory (default maximum token size) that the caller ends up allocating for the output buffer could be insufficient to hold the resulting output security token when the number of SIDs is large enough, and this can cause the authentication request to fail, resulting in a logon failure.


An Example of Kerberos Token Bloat

This issue is perhaps best illustrated with an example, so I’ll share an example with you which covers 2 scenarios –

1. A domain user account holder U from domain A logs to a machine Ma, wherein this machine Ma also belongs to the domain A (i.e. is domain-joined to domain A)
2. This same user U then proceeds to use a client-server application with the server component hosted on a machine Mb, wherein machine Mb is domain-joined to domain B

 

Scenario 1: Interactive Logon to a machine on Domain A

 

Here is (roughly) what happens when domain user account A attempts to interactively logon to domain-joined machine Ma–  

1. Domain user account holder U invokes the Secure Attention Sequence (SAS) on the machine by pressing Alt-Ctrl-Del.
2. Upon invocation of the SAS, Winlogon switches to the logon desktop, and dispatches GINA to collect the logon data.
3. GINA collects and returns the user’s logon data to Winlogon, which then sends the data to the LSA by calling LsaLogonUser.
4. The LSA immediately converts user’s plaintext password to a secret key by passing it through a one-way hashing function.
5. The LSA then creates pre-authentication data by encrypting a timestamp with the secret key derived from the user’s password.
6. The LSA then invokes the Kerberos SSP and sends a KRB_AS_REQ message (which includes this pre-authentication data) to the user’s KDC authentication service.
7. The KDC’s authentication service uses the user’s identity (UPN) contained in the KRB_AS_REQ to locate the user in its account database (Active Directory).
8. The KDC then uses the account’s hashed password to attempt to decrypt the pre-authentication data.
9. If the KDC is able to successfully decrypt the pre-authentication data, it then proceeds to evaluate the timestamp. If the timestamp passes the test, the KDC can authenticate the user.
10. If the user is authenticated, the KDC then identifies all the universal and global groups to which the user belongs (directly or indirectly) and packages them in a PAC.
11. The KDC then builds a TGT for the user, inserts this PAC in it, and replies back with a KRB_AS_REP message, which includes this TGT for the user.
12. The LSA then sends a KRB_TGS_REQ message to the KDC’s ticket-granting service to request a session ticket for the user for admission to this computer.
13. Since this computer belongs to the same domain, the KDC then identifies all the domain local security groups (in this domain) to which the user belongs (directly or indirectly.)
14. It then copies the data from the PAC stored in the TGT into a new PAC created for this session ticket, and it adds all the identified domain local security groups to this PAC.
15. It then creates a service ticket good for admission to this computer, inserts the new PAC in it, and replies back with a KRB_TGS_REP message, which contains this service ticket.
16. Upon receipt of the user’s session ticket for this computer, the LSA decrypts it with the computer’s secret key, and extracts the PAC (which contains the user’s authorization data.)
17. It then queries the local Security Accounts Manager (SAM) database to determine if the user is a member of any machine local security groups (directly or indirectly.)
18. If it finds any local security groups that the user might be a member of, it then adds this list of groups taken from the PAC.
19. It then creates an access token for this user and passes it back to Winlogon. (Technically it creates a logon session, and the access token is associated with the logon session.)
20. Winlogon then creates a window station and several desktop objects, attaches the user’s access token, and starts the shell process designated for this user.

The user’s access token is subsequently inherited by any application process that he starts during the logon session.

The key points to note here are that during the creation of the PAC for the session ticket –

1. The Global and Universal Group memberships were taken from the PAC in the TGT
2. Only those Domain Local Groups that belong to the computer’s domain (and of which the user is a member directly or indirectly) were included.

Now, let’s assume that the user was a member of 10 universal groups, 15 global groups and 25 domain local groups from the computer’s domain (which in this case is the same as the user’s domain).

 

In this case, the PAC in this Session Ticket contained 50 security groups in all, and that the resulting Kerberos token size would have been approximately 1200 + (40*25) + (8*(15+10)) bytes = 2400 bytes, based on Microsoft's recommended formula, details of which are provided below.

 

Since 2400 bytes is well below the 12000 byte MaxTokenSize limit, the user did not experience any issues with the logon.

 

 

Scenario 2: Network logon to a machine on Domain B

Now let us assume that immediately after logging on, the user U launches the client side of a client-server application, the server side of which is running on a domain joined machine Mb in domain B (i.e. the machine is joined to the domain B.)

 

Assume that this client-server application use SSPI for network authentication, prefer to use Kerberos, and that the client knows the SPN of the server-side of the application.

Here is (roughly) what happens under the hood in this scenario –

1. The user launches the client side of the application.
2. The client side of the application establishes a socket connection with the server
3. The client and server sides each proceed to call QuerySecurityPackageInfo() to determine the max token size for Kerberos
4. Then the client and server sides each proceed to call AcquireCredentialsHandle() passing in the name of the Kerberos package, to acquire a handle to their pre-existing credentials
5. Then, the client calls InitializeSecurityContext() to give the SSP a chance to prepare an outgoing token (; this token is not to be confused with a “Windows access token”)
6. The client then transmits the resulting token to the server
7. When the server receives this token, it calls AcceptSecurityContext() to pass the token to its SSP. (This function may be called two times.)
8. Upon a successful final pass of the AcceptSecurityContext() function on the server side, the system will generate a new network logon session for the client (i.e. the user)
9. The server-side will then call ImpersonateSecurityContext() to ask the SSP to place a token for the client’s logon session (on the server)
10. Finally when done, the server-side will call RevertSecurityContext() to discontinue the impersonation of the caller

Now, in case you find yourself wondering where the necessary Kerberos related exchanges are in the description above, the answer is that they are automatically handled by the SSP between steps 5 – 8 above since the SSP abstracts protocol specific details.

As it pertains to Kerberos, here’s (roughly) what happens under the hood between steps 5 through 8 above –

1. The client sends a KRB_TGS_REQ to the client’s KDC client, presenting its TGT, an authenticator, and the name of the target server (the Server Principal Name or SPN.)
2. The client’s KDC uses the SPN to determine that it is belongs to another realm, so it creates a TGT that the client can submit to a KDC in the server’s domain for requesting the service ticket
3. Before returning this TGT to the user, the KDC copies the PAC from the initial TGT into this TGT
4. The client then sends a KRB_TGS_REQ to the server’s KDC, presenting the new TGT, an authenticator, and the name of the target server (the Server Principal Name or SPN.)
5. The server’s KDC verifies the TGT (since it was signed by the client’s KDC, and these two Kerberos realm KDCs trust each other) and proceeds to generate a service ticket to the client for the server
6. Prior to the generation of the service ticket, the server’s KDC identifies all the domain local security groups from the server’s domain to which the user belongs (directly or indirectly.)
7. It then copies the data from the PAC stored in the presented TGT into a new PAC created for this session ticket, and it adds all the domain local security groups identified above to this PAC.
8. It then creates a service ticket good for admission to the server, inserts this new PAC in it, and replies back with a KRB_TGS_REP message, which contains this service ticket.
9. Upon receipt of the user’s session ticket for the server, the client sends a KRB_AP_REQ message along with the ticket and a new authenticator, to the target server, requesting access.
10. The server decrypts the ticket, validates the authenticator, and and extracts the PAC (which contains the user’s authorization data.)
11. It then queries the local Security Accounts Manager (SAM) database to determine if the user is a member of any machine local security groups (directly or indirectly.)
12. If it finds any local security groups that the user might be a member of, it then adds this list of groups taken from the PAC.
13. It then creates an access token for this user. (Technically it creates a network logon session, and the access token is associated with this network logon session.)

Now, above we had assumed that the user was a member of 10 universal groups, 15 global groups and 25 domain local groups from the user’s domain (which in this case is the same as the user’s domain).

Now, let us also assume that this user also happens to be a member of 300 domain local security groups in the server’s domain.

In this case, the PAC in this Session Ticket will contain 325 security groups in all, and the resulting Kerberos token size would be approximately 1200 + (40*300) + (8*(15 + 10)) bytes = 13500 bytes.

Since 13500 bytes is above the 12000 byte MaxTokenSize limit, the user will actually not be able to logon and the Kerberos SSP will most likely throw an error during the AcceptSecurityContext() call on the server.

The end result will be that the user will not be able to successfully authenticate to the server, and if this server was running Windows Server 2008, you might see the following message in the Kerberos event log –

Event Details
Product: Windows Operating System
ID: 6
Source: Microsoft-Windows-Security-Kerberos
Version: 6.0
Symbolic Name: KERBEVT_INSUFFICIENT_TOKEN_SIZE
Message:
The Kerberos SSPI package generated an output token of size 34BC bytes, which was too large to fit in the token buffer of size 2EE0 bytes, provided by process id 0. The output SSPI token being too large is probably the result of the user U being a member of a large number of groups.It is recommended to minimize the number of groups a user belongs to. If the problem can not be corrected by reduction of the group memberships of this user, please contact your system administrator to increase the maximum token size, which in term is configured machine-wide via the following registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize.



Potentially Impacted Services in Windows

It is worth noting that in a Microsoft Windows Server environment, many distributed services use SSPI to access the Kerberos protocol. Here is a partial list of the various ways in which the Kerberos protocol is used for authentication -

• Print spooler services
• CIFS/SMB remote file access
• LDAP queries to the Active Directory
• Distributed file system management and referrals
• IPsec host-to-host security authority authentication
• Reservation requests for network Quality of Service
• Intranet authentication to Internet Information Services
• Remote server or workstation management using authenticated RPC
• Certificate requests to Certificate Services for domain users and computers

Increasing the Size via the MaxTokenSize Registry Key

When Windows 2000 initially came out, the maximum size of a Kerberos authentication package specific token was hard-coded to be 8000 bytes in the RTM version of Windows 2000. It appears that way back in 2001 (see this KB and FAQ on same page), Microsoft released a Hotfix, which allowed admins to increase this value, based on a registry key called MaxTokenSize -

 

MaxTokenSize
 

Although this value is theoretically configurable to a value up to 65535 bytes, practically, it is recommended not to exceed 48000 bytes  because of HTTP’s base64 encoding of authentication context tokens. (Finally, there are also issues reported when IT personnel accidentally set the value to 65535 Hex, instead of 65535 decimal.)

 Today, the default maximum size of a Kerberos authentication package specific token is 12000 bytes in Windows Server 2003 and Windows Server 2008, and 48,000 bytes in Windows Server 2012.

Microsoft has also provided efficient ways to add this Registry key to mulitple computers in a domain. Options include a GPO based ADM file application in Windows Server 2003, using the Registry client-side extension in Windows 2008 and using a newly defined GPO setting (see below) in Windows Server 2012.


Set maximum Kerberos SSPI context token buffer size

In Windows Server 2012 and in Windows 8, Microsoft has introduced a new GPO to help make it easy to have this registry key be set on multiple computers. This new setting is under System > Kerberos, and it is called titled Set maximum Kerberos SSPI context token buffer size -

The description of this setting reads -

"This policy setting allows you to set the value returned to applications which request the maximum size of the SSPI context token buffer size. The size of the context token buffer determines the maximum size of SSPI context tokens an application expects and allocates. Depending upon authentication request processing and group memberships, the buffer might be smaller than the actual size of the SSPI context token. If you enable this policy setting, the Kerberos client or server uses the configured value, or the locally allowed maximum value, whichever is smaller. If you disable or do not configure this policy setting, the Kerberos client or server uses the locally configured value or the default value."

(This is in line with the crux of the issue described above.)

Microsoft's Recommendations for Token Size Calculation

In order to help organizations address this issue, Microsoft provides the following formula to help determine the maximum token size of a given domain user account -

     Token Size = 1200 + 40d + 8s

     This formula uses the following values:

• d: The number of domain local groups a user is a member of plus the number of universal groups outside the user's account domain that the user is a member of plus the number of groups represented in security ID (SID) history.

• s: The number of security global groups that a user is a member of plus the number of universal groups in a user's account domain that the user is a member of.

• 1200: The estimated value for ticket overhead. This value can vary, depending on factors such as DNS domain name length, client name, and other factors.

(This is a verbatim quote from the “More Information” section of the Microsoft Knowledge Base article 327825)

 

 

1015 Groups - Another Related Limitation

 

I'll digress for 30 seconds.

 

Based solely on the formula above, it might be possible for a user to be a member of say 2500 global groups and yet be able to logon (assuming an increased token size of 48000 bytes.) However, there is one other system limitation in Windows that will prevent this user from logging on, which is as follows.

 

In Windows, the maximum number of security identifiers (SIDs) that can be contained in a user's Windows access token is 1024. Now, assuming that the LSA can add upto 9 SIDs representing the type of logon etc, the realistic maximum limit is 1015.

 

Thus, irrespective of the token size calculations, the maximum number of groups that a user can be a member of is 1015.

 

End of digression.

A Small Ambiguity in Microsoft's Formula

 

This might sound obvious to many, but it is nonetheless worth mentioning and noting that when calculating the value of the variable d in the above mentioned formula, in regards to the number of domain local groups, it is important to understand that only those domain local groups that belong to the same domain as does the target server/resource and to which the user directly or indirectly belongs, need to be taken into account.

 

Here's why -

1. An access token generated for a domain user account on a domain-joined machine, is always specific to the machine’s domain and to the machine, and
2. An access token generated for a domain user account on a domain-joined machine, will only contain those DLGs that belong to the machine’s domain

I felt the need to share this because in our experience at Paramount Defenses, our Security Specialists have seen many instances wherein, in a multi-domain environment, IT administrators would take into account domain local groups from all domains, not just the target domain, thus incorrectly calculating this value.

 

Similarly, it is equally important to ensure that one also does not add global groups from any domain other than the user's domain, because a given domain user account can only be a member of global groups that belong to his own domain.

 

(Again, for many of you this might be obvious, but I'm told there's at least one script out there that may be adding global groups from other domains as well, thus potentially delivering inaccurate results.)

 

 

Existing Tools/Scripts to Calculate Token Sizes

 

There are 3 primary tools/scrips that seem to be in prevalant use -

1. Tokensz - A free command-line tool provided by Microsoft
2. CheckMaxTokenSize - A free script put together by a Microsoft employee
3. Get-TokenSizeReport - A free script derived from CheckMaxTokenSize by an independent consultant

(I commend the developers of these scripts for the efforts they have put in to develop these scripts.)     

Here are some relevant details -

Tokensz is a free command-line tool provided by Microsoft that seems to be designed to assist organizations in simulating authentication requests and reporting the size of the resulting token.for a given account to a given service.

It offers various options, the main one being /compute_tokensize, which uses the SSPI functions InitializeSecurityContext() / AcceptSecurityContext() to compute the maximum token size for a given user. (In nearly all cases, the maximum token size is determined by the first call to InitializeSecurityContext().)

However, in order to compute the Token Size for a given domain user account, the tool needs to be run in the user's context i.e. either by the user, or with the knowledge of the user's password. One alternative is to embed it in a logon script, and then have the output for each user be output to a specific location, and then collect, assemble, and collate the data for each user to arrive at the token size list for multiple user accounts. In essence, it can definitely help determine token sizes but it requires a fair amount of additional work to put results for all domain user accounts together.

 

CheckMaxTokenSize is a free script put together by a Microsoft employee (and I'm assuming) with the intention of helping organizations determine the token size for a given user, by querying the Active Directory for all relevant group memberships for the given user and using Microsoft's recommended formula to arrive at an approximate token size for a given user. While the script seems to fulfill a real need for many organizations, it does require that it be run in the user context and that it can only be run interactively. In other words, an IT admin can send the script to the user, requesting him to run the tool and send the results back to the admin. It is very nice to see a Microsoft employee demonstrate the passion that makes Microsoft the great company that it is, in his personal efforts to help folks.


Get-TokenSizeReport is a script derived from the CheckMaxTokenSize script and put together by an independent consultant (and I'm assuming) with the intention of making it a little easier to run it on multiple user accounts. While it seems to be very popular, one of the drawbacks seems to be that, as mentioned above, based on its description, it appears that it may possibly be including groups that do not need to be included (e.g. global groups from all domains) and thus that its results may not be reflecting the real picture. (I do not know if there are other factors that may have been unintentionally be included as well, so I cannot comment on its accuracy without a thorough review of the code, but unfortunately I don't have time to do so.) I do however commend its author for putting in considerable time and effort to try and make this easier for everyone.

 

The one other thing to keep in mind about the CheckMaxTokenSize script, is that Microsoft views it as a sample script, and thus provides it with the following disclaimer -

• "The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages."

In other words, you're welcome to use it at your own risk.

  

 

A Professional, Automated Multiple Domain User Acccount Token Size Calculator

 

As I had indicated above, one of the reasons I made the time to write this blog entry is because a few weeks ago, a world famous Swiss bank had reached out to us requesting our assistance in helping them effiiciently address this issue.

This issue was important for them, and they were hesitant to rely on scripts to address this problem. (Apparently one of the main concerns they had with scripts is that they were worried that anyone with sufficient write-access to the script file could modify it either unintentionally or intentionally thus compromising its integrity.) They also did not want to go through the laborious exercise of having to deploy Tokensz as a logon-script via GPO, then collect and collate the results to get all the data.

Here is the essence of their requirements -

1. We need to be able to calculate the maximum token size of multiple domain user accounts
2. We need to be able to compute domain-specific token sizes, since we have multiple domains
3. We do not wish to ask the user to run a script, or use a logon script to output results
4. The approach should not require administrative access to run, or the requirement to be run on a DC
5. The approach should be based on Microsoft's recommended formula (Token Size = 1200 + 40d = 8s)
6. The approach should allow us the ability to control the accounts on which it is run (via an LDAP filter)
7. We should be able to have the results in a CSV file so that our IT personnel can perform their analysis
8. It would be nice to have a breakdown of the various group types that show up in a user's token
9. Ideally, the solution should require zero to minimal extra work to be done by our IT staff
10. Most importantly, the code of the solution should not be tamperable 

Although, as a company, we're focused on helping organizations worldwide solve a problem that's substantially more critical than this one, we decided to help them fulfill this requirement, because we felt that a vast majority of organizations could benefit from such a solution.

I am glad to report that our Engineering teams were able to successfully build a solution that delivered on all their requirements, and in fact we were able to add this capability to Gold Finger by simply adding a new report to its Token Viewer capability -  

Kerberos Token Size Calculator Tool

As displayed above, Gold Finger now also offers the world's first professional-grade, fully-automated, multiple domain user account Kerberos Token Size Calculator, and makes the challenge of trying to calculate Kerberos token sizes for all domain user accounts, as easy as touching a button.

Here are some details -

1. It fully automates the calculation of token sizes for multiple domain user accounts
2. It lets you calculate both domain and target-type (Member Server/DC) specific token sizes
3. It lets you specify the set of domain user accounts you wish to focus on via application of LDAP filters
4. It provides you a complete breakdown of the various groups contained in each user's token
5. It calculates token sizes based on Microsoft's recommended formula (Token Size = 1200 + 40d = 8s)
6. It even shows you the d and s values, as well as which group types contribute to which value
7. It correctly includes all relevant security group memberships (e.g. domain local group memberships)
8. It can run in the security context of any domain user account; no admin privileges needed to run
9. It lets you export the entire output of the assessment to a CSV file
10. Its integrity is protected by state-of-the-art anti-tampering measures as well as digital signatures

A sample CSV output file for Domain-Controller specific access tokens can be found here.

We believe that this can help thousands of organizations worldwide easily, efficiently and reliably address this vital problem, and save IT personnel worldwide hundreds of hours of laborious, detail-oriented and error-prone work, thus helping them to focus on their core responsibilities and providing organizations a reliable way to solve this problem.

Should you wish to learn more, the details can be found here.



Security Ramifications of Kerberos Token Bloat

The main reason I wanted to blog about  this is to help folks understand the security ramifications of Kerberos Token Bloat. If you give it due thought, you'll see that this is an issue that potentially impacts organizations of all sizes.

From a security perspective, the main point here is that this issue can result in a Denial-of-Service (DoS) for the impacted user. In most cases, this DoS could be caused by the fact that the user is actually a member of a large number of groups, and that is scenario that most organizations currently deal with.

However, it is also possible for a malicious insider (or an outsider who can gain control of specific machines) to very quickly launch a domain-wide denial-of-service attack against all or a targeted set of domain user accounts. To do so, all the malicious insider would have to do is create a large enough number of groups, make one a member of the other, an then add a group like Domain Users to the last group (or say in a targeted attack, add a group such as "Executive Users".) 

This would easily cause the targeted users to experience denial-of-service, and though IT personnel will ultimately be able to figure out what happened, the DoS attack could last long enough to cause potentially material damage. (For instance, hours before a public organization's earnings call, the entire Finance team could be prevented from logging on for hours, thus resulting in a situation where in key executives like the CFO may not be able to logon and thus send email, or access vital documents during those few critical hours.)

Of course, if someone were to target a Domain Controller's account, things could get ugly very quickly.

Now, the reason this impacts organizations of all sizes, is that, even in a small organization with only a handful of groups, someone could maliciously create a large number of security groups and launch an attack impacting all the domain user accounts in the domain, even though the number of domain user accounts is relatively small.

In other words, a small $500M publicly traded company with just a 100 employees is equally susceptible to being a victim in such an attack.

It also helps to keep in mind the smart attackers seldom carry out the attack in real-time. Instead, they'll just script the attack, and have it scheduled to run at some pre-determined time in the future. So while auditing might catch such an attack in progress, its source could very well be a (semi-)privileged service account running on some domain-joined machine, making it very difficult to catch the real perpetrator.

Thus, at an absolute minimum, it is very important for organizations to have precise answers to at least 4 questions at all times -

1. Who can create security group memberships?
2. Who can modify existing group memberships?
3. Who can create domain user accounts?
4. Who can create Organizational Units?

Here's why -

Anyone who can create security groups can potentially launch such an attack very quickly using the power of automation. Now, although the ability to create a large number of security groups can be prevented by using Quotas, the quota limit restriction can be partly circumvented if the attacker can create new user accounts, and use those accounts to create additional security groups.

This is why it is equally important to know who can create user accounts, where and how.

Finally, even if you know who can create user accounts, you should also know who can create Organizational Units (and strictly speaking who can modify permissions on existing OUs as well) because if you can create OUs, or modify permissions on OUs, you could grant any domain account of your choice, the ability to create accounts and groups.

One other thing - along the same lines, if someone can modify the membership of a large number of security groups, he could also launch this attack, and quotas would not prevent him from doing so, since quotas only impact object creations.

This is why it is very important to know exactly who is currently delegated the ability to perform these tasks in your Active Directory environment -

Who can create security groups in Active Directory?

Oh, and this point can never be over-emphasized - "Finding out who has what permissions in Active Directory IS NOT THE SAME as finding out who can perform these tasks." In fact, if you merely rely on the former, you're in dangerous territory because you're operating on inaccurate information.

In order to correctly find out who is delegated these tasks in your environment, you have to first determine true effective permissions on virtually all objects in your Active Directory, and based on that determine who is truly delegated the ability to perform these tasks.

In fact, the mission-critical subject of how to correctly determine true effective permissions in Active Directory will be the subject of my next blog entry. Until then, if you want some more info on it, you can find it here.

Alright, my time's up.

Best wishes,
Sanjay

PS: I generally prefer to let my work speak for itself, but sometimes it is important to address vital issues. Also, in case you liked this, you may also like this and my take on the OPM Data Breach

PS2: If you found this useful, you're welcome to share it. I only ask that since this is copyrighted material, if you do quote any of it, please do acknowledge the source with a link. Thank you.

Gold Finger 6.0, the Lamborghini of Active Directory Audit Tools

Folks,

Please accept my sincere apologies on account of the lapse in sharing thoughts via this blog. Something important came up, and required my personal involvement. Its taken care of now, and I look forward to getting back to sharing my 2c with you, with the intention of sharing potentially valuable insights on Active Directory security.

 

Anyway, before I get back to sharing insights, I just wanted to personally also introduce the latest version of Gold Finger, version 6.0, which in my humble opinion is the world's most capable Active Directory Audit  Tool –

Gold Finger 6.0

Here is a link to the Press Release - http://finance.yahoo.com/news/paramount-defenses-one-worlds-top-173000714.html

About two years ago, we shipped Gold Finger 5.0, and back then we referred to it as the Ferrari of Active Directory Security Solutions, because its capabilities represented the finest in Active Directory security analysis. Today, of course, Gold Finger 5.0 is deployed in five continents worldwide and it helps some of the world’s most important business and government organizations gain valuable security and access insight.

 

Gold Finger 6.0 – The Lamborghini of Active Directory Audit Tools

If Gold Finger 5.0’s unique and valuable capabilities made it the Ferrari of Active Directory Audit Tools, then Gold Finger 6.0’s speed and finesse surely make it the Lamborghini of Active Directory Audit Tools.

 

 

You see, when developing Gold Finger 6.0 we primarily focused our efforts on one thing - making it fast. Really fast!

 

I’m pleased to let you know that Gold Finger 6.0 is up to 5 times faster than Gold Finger 5.0. So, what used to sometimes take up to an hour in Gold Finger 5.0 can be done in about 5 minutes with Gold Finger 6.0. Five minutes.

For instance, if you wanted to find out exactly -

1. who can reset whose passwords in an Active Directory containing 20,000 accounts
2. who can create user accounts where in an Active Directory containing a 1000 OUs
3. who can change the security group memberships of each one of over 5,000 groups
4. who can delete which user accounts in an Active Directory containing over 10,000 accounts

... all you'd have to do is touch a button, and give it a few minutes. That's it.

 

Incidentally, in order to make any of the determinations listed above, one needs to analyze millions of security permissions and determine effective permissions on 1000s of objects. With Gold Finger, one can make these determinations in minutes. Without Gold Finger, making the same determinations could take months or even years.

This primarily being a technical blog, here's an enumeration of Gold Finger’s technical capabilities (listed in increasing order of difficulty) –

1. Generate 100+ fully customizable (via LDAP filters) security audit reports, with scope control and scope depth control
2. Enumerate the complete group membership of any Active Directory Security group, as well as view group nesting details
3. Enumerate the complete list of security groups to which a domain user or computer account belongs
4. View the contents of any domain user’s domain-specific and machine-type specific access token
5. View the ACL of any Active Directory object, both in a simple view and in a detailed view that provides unmatched clarity
6. Export/dump the ACLs of all objects in an Active Directory tree, with the ability to control tree depth
7. Perform comprehensive Active Directory permissions analysis/reporting, with unmatched flexibility in filter specification
8. Determine true effective permissions on any object in any Active Directory partition
9. Enumerate the list of all administrative tasks delegated on a given Active Directory object, including a list of delegatees
10. Find out exactly who has what effective administrative access, where and how across an entire Active Directory domain

Of course, each of the enumerations listed above can be done on-demand within mintues, at the touch of just ONE button.


Designed to Empower YOU

Gold Finger 6.0 is the embodiment of over half a decade of innovative cyber security research and development. Built at a cost of almost $10 million, today, it makes what is generally considered impossible as easy as touching a button.

We primarily built Gold Finger to help organizations worldwide swiftly and reliably mitigate the world's #1 cyber security risk - Active Directory Privilege Escalation based on the identification and exploitation of unauthorized grants in Active Directory deployments.

Along the way, we also got great feedback from some of the world's best Active Directory Security Practioners, most of whom are our customers today, and we embraced their feedback, resulting in the addition of over half a dozen valuable capabilities ranging from basic security audit reporting to true effective permissions.

In essence, we built this tool to empower all IT personnel worldwide, who, in our humble opinion, play a very important role in the protection of their organizations, because they help secure and defend the very foundation of their organizations, and because they work tirelessly to keep the lifeline of their organizations, the Active Directory, up and running, safe and sound, round-the-clock.

They already have a LOT on their plates, and the least we can do is empower them to obtain the mission-critical insight they need to keep their Active Directory deployments safe and secure at all times, quickly and easily, so they don't have to put in hundreds of hours to accomplish something that can now be done within minutes.

I personally have the greatest respect for all IT personnel, and I dedicate Gold Finger 6.0 to them. This one's for all of you, because the work that you do is VERY important, and I for one, know and deeply respect that. 

Kindest regards,
Sanjay

PS: With this behind us, you can expect me to get back to blogging again, very soon.

5 Facts You Must Know about Active Directory Privilege Escalation

Folks,

Last month, we declassified the #1 cyber security risk to Active Directory deployments - Active Directory Privilege Escalation.

Active Directory Privilege Escalation based on identification and exploitation of unauthorized access grants in Active Directory deployments.

Today, I wanted to share with you 5 things that we all must know about Active Directory Privilege Escalation –

#5 – Domain Admin accounts only account for 1% of the attack-surface. Accounts of delegated admins, executive and regular employees, and all other Active Directory content (i.e. all group memberships, GPOs, OUs etc. ) accounts for 99% of the attack surface

#4 – We may not know it or realize it yet, but most Active Directory deployments worldwide are currently exposed to this risk today. In fact, most domain user and computer accounts, domain security groups, GPOs, OUs, SCPs etc are potentially at risk of compromise.

#3 – This risk is far more damaging and easier to carry out than even the risk posed by the Pass-the-Hash (PtH) attack vector, because unlike Domain Admins, the likelihood of a non-admin user logging on to the attacker’s machine is quite low. (Consider this - what is the likelihood that your organization's CEO will logon to your machine, whether for legitimate reasons, or even if social engineered into doing so?)

#2 – This risk exists because Active Directory lacks the ability to help IT personnel precisely assess and verify provisioned access. Active Directory does let us precisely provision access, but it is unable to help us precisely assess/verify/audit effective provisioned access.

#1 – The presence of an Auditing solution does nothing whatsoever to mitigate this risk. It merely helps detect its occurrence. By the time an associated event shows up in the audit log, it is already too late, because the damage has been done. (E.g. - if a malicious entity has been able to reset a Domain Admin's password, or the CEO's password, even though the event may show up in the audit log, by the time you react to it, the damage is already done.)

In days to come, I will share with you how organizations can assess whether they're at risk, and how they can mitigate this risk.

For now, perhaps its worth asking yourself a simple question – “Do we know exactly who can do what in our Active Directory, especially in light of the fact that anyone with a domain user account can find this out on any object within minutes?”

Best wishes,
Sanjay

PS: This is a very simple and fundamental problem that stems from the lack of verifiable implemented least privilege access (LPA) in a major foundational technology. Frankly, I’m really surprised that over 80% of organizations worldwide still do not realize this simple fact! The only thing more concerning is that based on our intelligence, the Chinese have most likely already figured this out.

How an Insider Could Easily Compromise the CFO's Account - An Example of Active Directory Privilege Escalation Based on Access Grant Exploitation

Folks,

Today, I will share with you a concrete example of how any insider could potentially compromise the user account of the Chief Financial Officer (CFO) of an organization by exploiting weaknesses in access grants provisioned in Active Directory, which is the basis of the Active Directory Privilege Escalation security risk that I declassified one week ago.

Chief Financial Officer

This specific example is a very realistic illustration of this risk, that today could be carried out in most organizations worldwide.


SUMMARY -

• Target: The CFO's domain user account which resides in the Finance OU in the Active Directory
• Attacker: John Doe, a temporary contractor working on some project, who has a domain user account

• Attack Methodology -
• Step 1 - Obtain a tool that can aid in performing Active Directory Security Analysis.
• Step 2 - Use this tool to a) locate the CFO's domain user account in Active Directory, and then b) analyze access provisioned in the ACL of the CFO's domain user account to identify the list of all individuals who can reset the CFO's password.
• Step 3 - Use the same tool to analyze security permissions on the user accounts of each of these individuals to identify who can reset their passwords. Iterate this process on this list of accounts, and continue iterating until the single weakest link i.e. an account that can be easily compromised by  the attacker, has been found.
• Step 4 - Begin by compromising the account identified as the weakest link. Then, login using that account and reset the password of the next account in the chain. Repeat this process until you have reset the password of a delegated admin who can reset the CFO's user account.
• Step 5 - Login using the final compromised delegated admin's account, and reset the CFO's password.
• Time Requirement - The exploitation process is very quick, since a password reset operation only takes 5 seconds, and a subsequent logon about 30 seconds. The only part that takes some time is the process of determining who can actually reset a target account's password.

• Compromising the Initial Account - The initial account can be compromised by any one of various means, an encyclopedia of which is known to most malicious individuals. Examples of such means include Password Guessing, Password Stealing (Keystroke Logger), Phishing, Hash Replays (Pass-the-Hash) etc.

DETAILS -


Step 1 - Obtain a tool that can aid in performing Active Directory Security Analysis

Since John already has a domain user account, he already has complete read access to Active Directory content. All he needs is an Active Directory Security Analysis tool to view Active Directory content, analyze Active Directory permissions and enumerate group memberships i.e. aid in the process of determining effective access in Active Directory.

The Advanced Security Settings Tab of the Active Directory Users and Computers Tool

There are many freely available tools that can aid the attacker in performing Active Directory Security Analysis, such as Microsoft Active Directory Users and Computers Snap-In, Administrative Center, dsacls, acldiag, LDP, LIZA etc.


Step 2a - Use this tool to locate the CFO's domain user account in Active Directory

Once John has installed a tool of his choice, he can launch it to view the contents of the Active Directory. Using the tool's inbuilt search abilities, he should easily be able to locate the CFO's account -

Locating the CFO's User Account in Active Directory

 

 

CFO's User Account in Active Directory

Once John has located the CFO's domain user account, he can access the ACL protecting the account. Since authenticated users have default read access in Active Directory, no special access is needed to access and examine AD ACLs.


Step 2b - Use this tool to analyze access provisioned in the ACL of the CFO's domain user account to identify the list of all individuals who can reset the CFO's password.

The next step is to analyze the object's ACL to identify the list of all individuals who can reset the CFO's password. The following is the access control list (ACL) protecting the CFO's domain user account -

Analyzing Security Permissions Specified in the ACL of the CFO's User Account

In order to determine who can reset the CFO's password, John will need to determine who effectively has Reset Password rights granted on the CEO's user account.

To do so, he will need to engage in the process of determining who has what effective access in Active Directory. Kindly note that this process is NOT the same as the one involved in determining who has what permissions in Active Directory.

In essence, all John needs to do is determine who effectively has Reset Password rights allowed on the CFO's user account. Anyone who is effectively allowed the Reset Password extended right, or All Extended Rights, or Full Control over the object will make the list. This is because All Extended Rights includes the Reset Password right, and because Full Control includes All Extended Rights.

As you can see above, there are many security permissions specified in the ACL, each one specified in an individual access control entry (ACE). Some ACEs grant permissions whereas others deny permissions. Some are explicitly specified on the object, whereas others are inherited. Some inherited ones apply to the object (CIID), whereas others merely exist to be inherited down to other objects (CIIO).

In order to determine effective access on the CFO's object, John will need to perform a process similar to the following -

1. Identify all relevant ACEs i.e. all ACEs that allow/deny Reset Password, or All Extended Rights or Full Control.

2. Then flatten all group memberships for which access is specified in all relevant ACEs, generating lists that enumerating the list of all individuals who are allowed access, as well as enumerating the list of all individuals who are denied access. (Ensure that any and all nested group memberships are completely flattened as well.)

3. Then, intersect these lists taking into account all pertinent factors, such as inheritance rules, ACE applicability, conflict resolution etc. to ultimately arrive at a list of all individuals who can reset the CFO's password.

Upon completion of these steps, John would have the list of all individuals who can effectively reset the CFO's password.


List of individuals who can reset the CFO's password

It is worth noting that even if John did not know how to do engage in this process with 100% precision, even with 80% precision, he could determine 80% of the individuals who could reset the CFO's password.


Step 3 - Analyze security permissions on the accounts of these individuals to identify who can reset their passwords.

If John is already a delegated admin, and his account is already on that list, he may not need to analyze effective access on any more accounts. However, if his account is not on that list, then he could continue the process to find a weakest link, which is described below.

Once John has put together the list of all the individuals who can reset the CFO's password, he would then proceed to determine who can reset the passwords of these individuals. This would give him a broader attack base, and one that would also usually constitute a set of weaker targets to compromise.

He could then iterate this process on this new list of accounts, and continue iterating until the single weakest link i.e. an account that can be easily compromised by the attacker, has been found.

Any ONE of a large number of IT admins may be the starting point for privilege escalation i.e. the weakest link

For instance, he might find that a total of 12 individuals can reset the CFO's password, but that a total of 36 individuals can reset the passwords of these 12 individuals. He could iterate further to find potentially 50 or so individuals who could in turn reset the passwords of these 36 individuals.

He only needs to iterate the process until he can find at least one account that is easily or readily compromisable i.e. until he has found the weakest link. For instance, he could stop identifying accounts as soon as he finds the account of a single local IT admin whose account he could compromise using various known means.

By engaging in this process, he would have in effect identified a privilege escalation path, which would start from an easily compromsable account and lead all the way up to the CFO's user account.


Step 4 - Escalate Privilege by Performing Password Resets

Once John has identified a privilege escalation chain, all he needs to do is act upon it at a day and time of his choosing and to his advantage. He would begin by compromising the first account using any one of several known means to do so.

Once he has compromised the first account, the rest of escalation is simply a matter of logging in using the compromised account, then resetting the next target's password, then logging off, and logging on using the next compromised account, and so on, and by the end of it, he would have effectively escalated his privilege to that of the CFO of the company

Final Privilege Escalation Step - Resetting the CFO's account's password

In most cases, John would only have to repeat these steps 2 to 4 times (i.e his privilege escalation depth would be 2-4.)


Step 5 - Login as the CFO

Once John has reset the CFO's account's password to one of his choice (e.g. Th@WasEasy!), he can instantly login as the CFO i.e. using the CFO's account -

Once logged in as the CFO, he would have whatever read and modify access the CFO's account may have been provisioned across the IT infrastructure. Since in most organizations, single-sign-on is in use, he could almost instantly access, copy, change or delete any information that the CFO's account might have access to.

(Imagine the financial and legal ramifications of John being able to access the organization's quarterly earnings numbers just 10 minutes before the official scheduled earnings release, using the CFO's account, and then leaking them on the Internet.)


Some Observations about Active Directory Privilege Escalation Based on Exploitation of Unauthorized Access Grants

As seen above, the process of identifying and exploiting unauthorized access grants in Active Directory is rather simple. Here are some noteworthy observations -

• Easier than the Pass-The-Hash (PtH) Attack Vector - This attack vector is much easier than the PtH attack vector because of the following reasons -
• Opportunity - The PtH attack vector may be easy to carry out against Domain Admins because the likelihood of having a Domain Admin logon to a machine the attacker controls is high. However, the likelihood of a specific non-administrative high-value account such as that of the CFO, CEO, CIO, CISO, IT Director, a Vice President, a manager etc. logging on to a machine controlled by the attacker is rather low. (Most folks usually logon to their own dedicated machines.) Thus, the likelihood of compromising a non-administrative account with PtH is low, whereas with this attack vector it is high.
• Lower Bar - In most organizations, there is already sufficient awareness about the PtH attack vector, and administrators are careful as to not to logon to machines they do not trust. However, most organizations still have no idea as to exactly who can reset whose passwords, so there are ample opportunities to escalate privilege by resetting passwords and thus the bar is much lower
• No Specialized Tooling Required - Unlike the PtH attck vector, this attack vector does not require any specialized tooling. It only requires some security analysis and the enactment of basic tasks, which can easily be carried out using Microsoft's native tools.
• Higher Probability - If a potential target never logs on to the attacker's host, the attacker will NEVER be able to use PtH to escalate privilege. However, with password resets, not only does the potential target not need to logon to the attacker's machine, the probability of finding at least one unauthorized individual who can reset the target user's account is substantially higher.

• A Vast Attack Surface - It is not just domain user accounts that are vulnerable. All Active Directory content, including security groups (and their memberships), computer accounts, GPOs, entire organizational units (OUs), service connection points (SCPs) etc. can all be compromised by simply determining who can manage them and then using this approach to take over the account of a delegated administrator who can manage that object.

• AdminSDHolder Protection does not mitigate this risk - Contrary to popular belief,  AdminSDHolder does not mitigate this risk for two reasons -
• Non-administrative accounts - AdminSDHolder only serves to ensure that a standard set of permissions in applied to all administrative accounts and groups. It does not provide any protection for non-administrative accounts and groups. So for example, executive (C*O) accounts, VP accounts, director and manager accounts are not protected by it, neither are regular employee and contractor accounts.
• Administrative accounts - Even for administrative accounts, it only serves to ensure that a single standardized set of permissions are applied to all accounts. It does NOT protect the groups to whom access is specified in the ACL of the AdminSDHolder object itself, or the users that belong to these groups. Thus, this attack vector can also be used against all administrative accounts and groups.

• Security Analysis is not Audited - The act of performing security analysis only involves read access to Active Directory. Read access to Active Directory is almost never audited because of the sheer volume of read access that takes place everyday in the course of normal business/IT operations. As a result, it is virtually impossible for IT personnel to know whether or not, and if so, when, someone might be performing such security analysis in their environments. This aspect gives attackers the luxury of time. They could take anywhere from hours to weeks to identify weaknesses, then act at a day and time of their choosing to exploit their findings.

• This Risk is 100% Mitigatable - This risk is 100% mitigatable. In other words, organizations can easily take steps to mitigate it, such that even if every user in the environment were to scour all their Active Directory ACLs, all they would find are tightly locked access grants i.e. least privilege access (LPA) implemented in their Active Directory. In order to mitigate this risk and attain an LPA state in their Active Directory, all that organizational IT personnel need to do is identify and eliminate unauthorized access grants in their Active Directory. This can easily be done by using any advanced Active Directory Security Analysis Tool that is capable of determining True Active Directory Effective Permissions (i.e. true/accurate effective permissions on Active Directory objects). Organizations that have abundant IT resources and expertise could also choose to develop and test their own Active Directory effective access assessment capabilities in-house.

Real-World Proof

For most IT personnel familiar with Active Directory, the example presented above should be sufficient to illustrate the risk.

For those who must have real-world proof, you can use this tool (its free), to see for yourself, in under 2 minutes, exactly how many individuals can reset your own password, as well as the password of any of your colleagues, including that of your organization's CFO.

Need one say more?

Best wishes,
Sanjay

Active Directory Privilege Escalation based on Exploitation of Unauthorized Access Grants in Active Directory - The #1 Insider Threat to Organizations

Folks,

Today, I will objectively substantiate not only why the risk I declassified yesterday (i.e. Active Directory Privilege Escalation based on Exploitation of Unauthorized Access Grants in Active Directory) is the #1 cyber security risk to Active Directory, but also why it is also the #1 insider threat to 85% of organizations worldwide -


The Building Blocks of Security in an Organization

In every IT infrastructure, there is a security infrastructure that is responsible for providing Authentication, Authorization and Auditing (AAA), which provides the foundation upon which all secure access is based i.e. it facilitates secure authenticated and authorized access to securable resources and it enables the auditing of access to these resources.

In the IT infrastructure of every organization in the world, no matter how small or large, there are 5 basic building blocks of the security infrastructure that together facilitate AAA / secure access to resources -

1. The User Accounts (and their passwords/ other credentials) that are used to uniquely identify and authenticate users

2. The Computer Accounts that represent the computing devices in the system on to which users logon, and on which all computing occurs i.e. your laptops, desktops, file servers, application servers, database servers etc.

3. The Securable Resources to which access can be granted, i.e files, directories, applications and their content, databases and their content, directory services and their content etc.

4. The Security Groups that are used to aggregate users for the purposes of authorization

5. The Auditing Mechanisms that enable the auditing of secure access to securable resources

Together, these User Accounts, Computer Accounts, Security Groups and the Auditing Mechanisms facilitate secure authenticated, authorized and auditable access to all Securable Resources in the organizations IT infrastructure,  24-7.



Where are the Building Blocks of Security Stored, Managed and Protected?

In IT infrastructures powered by Microsoft's Windows Server platform, i.e. in about 85% of IT infrastructures worldwide, these building blocks are stored and managed in, and protected by the Active Directory.

Specifically -

1. All User Accounts and their passwords are stored in the Active Directory

2. All Computer Accounts representing all domain-joined hosts are stored in the Active Directory

3. All Securable Resources in turn are stored on domain-joined machines, which can be completely controlled via Group Policy from the Active Directory

4. All Security Groups and their memberships, that are used to specify access to all Securable Resources (e.g. files, directories, shares, SharePoint portals etc.) are all stored in the Active Directory

5. All Auditing for identity & access management is done on Domain Controllers (i.e. machines that host Active Directory)

In other words, it is Active Directory that stores and protects (directly or inditectly) the entirety of all security building blocks, as well as facilitates their management by administrative IT personnel.



What are the Consequences of the Compromise of These Building Blocks?

Now let us consider what the consequences of the compromise of any of these building blocks could be, and how they could impact organizational security.

  Specifically -

1. If a specific User Account, such as that of the CEO is compromised, the attacker can instantly access everything the CEO has access to, including all confidential data, documents, groups, databases etc etc. as well as modify or destroy everything the CEO has modify access to.

2. If a Computer Account, such as that of a file server that stores highly confidential information (e.g. trade secrets, blue prints, financials, customer records) etc. is compromised, the entirety of data stored on that server can be easily accessed, tampered, divulged or destroyed.

3. If a Securable Resource, such as the spreadsheet that contains Earnings Numbers can be accessed and leaked minutes before a public organization's Earnings Call, the untimely disclosure of that data could result in a loss of billions of dollars in market capitalization.

4. If a Security Group such as Human Resources Personnel can be compromised, i.e. if an attacker can add his/her account to this group, all confidential information such as all employee records being protected by that group can now be instantly accessed by that attacker.

5. If the Auditing settings can be tampered with, than an attacker can disable auditing in the system, before he/she proceeds to engage in other malicious tasks, thus ensuring that there is no trail of malicious actions left.

In other words, the amount of damage that can be done by an attacker if he/she can compromise the very foundational building blocks of security is potentially colossal, and can result in serious consequences ranging from substantial monetary loss to reputational damage.



What is the Easiest Way for Someone to Compromise These Building Blocks?

In light of these consequences of the compromise of any of these building blocks, let us consider what is the easiest way that someone could use to compromise these building blocks.

 
Specifically -

1. The easiest way to compromise a User Account is to reset the user's account's password to one of your choice (e.g. H@cked!) then instantly login as the user.

2. The easiest way to compromise a Computer Account is to take over its computer account in Active Directory, and/or cause a Group Policy designed to take over the computer to be sent out to the computer via the trusted channel between the computer and the DC, by applying it to the OU in which the computer account resides.

3. The easiest way to compromise any Securable Resource is to find out which Security Group has modify access to it, then just add your own account to that security group, to instantly gain access.

4. The easiest way to compromise a Security Group is the find out who can change its membership, and compromise that individual's account by resetting their password, then login as that individual and add your own account to the group.

5. The easiest way to compromise Auditing is to turn either turn OFF auditing in the Active Directory, or modify the SACL of objects to disable auditing on specific objects.

In other words, the easiest way to compromise the building blocks of security is to find out who has what access on them, then compromise their accounts to take control of the building blocks.



In Most Organizations, No One Knows Exactly Who can do What on these Building Blocks?

In most Active Directory deployments large number of IT personnel currently posses the ability to perform various administrative tasks on these building blocks, but NO ONE really knows EXACTLY who can do what on these building blocks in their Active Directory deployments.

This most simply put, is primarily because all of these building blocks are protected by Active Directory's security model, which makes it very easy to precisely provision secure access but lacks the ability to help IT personnel precisely assess/audit effective provisioned access.

As a result, although IT admins provision access for delegating administrative responsibilities frequently, due to the lack of a single point of control on both delegations and group memberships, as well as the sophistication of Active Directory's security model, they have no way of knowing whether access was infact provisioned on the principle of least privilege, or whether they may have accidentally/inadvertently ended up granting additional IT personnel access that they should not ideally have. They also have no way to precisely assess/verify/audit provisioned access, so they continue fulfilling provisioning needs based on "approximations" and over time (years), the presence of excessive unauthorized administrative access in Active Direcory deployments becomes pervasive.

As a result, IT admins may have an "approximate" idea of who has what access, but most do not have "precise" insight, and almost always, the difference between security and compromise is "precision" (referred to as "vulnerability" in security parlance.)



ANY Insider Can Potentially Assess Security (Effective Access) on and Compromise these Build Blocks

Anyone with a domain user account, from IT Personnel to Executives, and from Executive Assistants to Contractors, can with some basic and readily available free tools EASILY access and analyze the universe of all security permissions that protect all of these building blocks, and with a little skill and sufficient time (hours/weeks/days), easily find out exactly who has what access over these building blocks, and (mis)use this information to compromise virtually any IT asset of choice.

The "little skill" requirement, as well as the "sufficient time" requirement can be easily obviated by the availability of tools (e.g. an Active Directory Permissions Analysis Tool, or an Active Directory Password Reset Analysis Tool) that automate the determination of effective access in Active Directory.

Whether analyzed manually or via a tool, these access assessment are all read-only in nature, and thus IT personnel cannot audit or detect the occurrence of such an access assessment. Once completed, such an assessment can provide a very rich "road-map" of sorts to insiders, as to how to go about compromising anything from a basic file all the way to down to how to completely take over and control the entire Active Directory deployment.



The #1 Insider Threat to Organizations

For reasons stated below, I believe that Active Directory Privilege Escalation based on Exploitation of Unauthorized Access Grants in Active Directory, is the #1 insider threat to organizations today -

1. It can be carried out by ANY insider, from highly technical delegated administrators to completely non-tech savvy Executive Assistants. Tech-savvy individuals can use Microsoft's native tools (e.g. dsacls) to assessments and non-tech savvy individuals can use 3rd party tools (e.g. any Active Directory Password Reset Analysis Tool) to do so.

2. The attack surface is VAST, because literally the entirety of all Active Directory content, i.e. any user account, computer account, security group, OU, GPO, Service Connection Point etc. is a potential target.

3. The analysis part of the attack vector only involves READ access which is NOT audited, and cannot be realistically audited, thus can hardly ever be detected.

4. The exploitation part of the attack vector (i.e. one involving the password resets or the group membership changes) literally takes seconds and can at best be responded to, meaning the damage would already have been done. In most cases, by the time someone responds, it would have been too late (; e.g. sure you can catch the individual who leaked the earnings report, but the damage (in billions of dollars) would already have been done.

5. Unlike the sophisticated Pass-The-Hash (Pth) attack, this attack vector does not require ANYONE to LOGON to any machine. It only requires READ access to Active Directory, which everyone has, basic (e.g. dsacls) or advanced tooling (e.g. any Active Directory Permissions Analysis Tool), and the implementation of basic tasks for which User Interfaces (e.g. Active Directory Users and Computers Snap-In) are freely and readily available from Microsoft.

In light of the above, given the fact that ANY insider can enact this threat, the VAST attack surface, the inability to audit the core part of this attack vector (read-only effective permissions analysis) and the availability of the tooling required to enact this threat, it is clearly a very serious insider threat to organizations today.

From gaining unauthorized access to a single confidential document to automating the destruction of the entire Active Directory deployment, the expanse of the damage an insider can do with it is limited only to their skill. In that light, it may be very well be the #1 insider threat to Active Directory today.



But We don't worry about Insider Threats

Organizations that do not worry about insider threats need only be reminded of one name - Edward Snowden, the classic Trusted Insider, who may not only have caused monumental and irreversible damage, but also great embarrassment to arguably the world's most powerful and clandestine national security agency, the U.S. NSA.

Best wishes,
Sanjay


PS: If you're still not convinced, I'll prove it to you - using this free tool you can see for yourself just how many people could reset your password and login as you today. (The threat, in most cases, is not directly from them, but frm someone who first resets their password, then resets yours to login as you.) In case you didn't know, a password reset takes about 5 seconds to perform.

Active Directory Privilege Escalation based on Exploitation of Unauthorized Grants in Active Directory - The #1 Cyber Security Risk to Active Directory

Folks,

The #1 cyber security risk to Active Directory deployments is summarized in the following Executive Summary document (which can be downloaded by clicking the image below, or by clicking here) -

Active Directory Privilege Escalation Executive Summary - 
 

  To access this Executive Summary, click image above, or here.
 

Those who understand it, know that it is powerful enough that it can be used to instantly compromise any Active Directory deployment in the world. (We can demonstrate its enactment in any production Active Directory deployment in the world.)

Those who don't understand it yet may wish to ramp up their Active Directory Security skills. A good starting point is to research "Active Directory Effective Permissions" and "Active Directory Privilege Escalation".

In days to come I will shed light on its various aspects, such as what makes it substantially more critical than the Pass-the-Hash attack vector, etc. Until then, here are some thoughts, some details, and a concrete example.

Best wishes,
Sanjay

PS2: For those of you who downloaded the password-protected version of the document this past week, the password to that document was "SkyFall"