Ghost Users: They Won’t Stay Dead!

As part of our extensive research on the Kerberos authentication protocol we found that contrary to the actual aim of Kerberos and as opposed to common sense, a disabled account in Windows’ network does not take effect immediately. In fact, due to design considerations disabled accounts – and the same goes for deleted, expired and locked-out accounts – effectively remain valid up to 10 hours after they had supposedly been revoked. The consequence? So-called disabled accounts expose the corporation to advanced attackers seeking to gain access to the corporate network. Unfortunately, traditional security measures, such as logs and SIEM products – which we rely upon to alert on such misuse – do not have the proper visibility to contain this type of threat.

We name these supposedly “dead” (i.e. deleted/disabled) users who are actually still very much alive as “Zombie Users”.

“Zombie Users” pose a very prevalent threat for the security of the enterprise. In the current employment market, many companies suffer from a very high employee turnover rate. In fact, in some Fortune 500 companies the median employee tenure is less than a year, which means that half of their workforce is replaced within a year’s time. All of these leaving employees must have their user account disabled and therefore each of them is a potential Zombie User. Combining this stat with the fact that 95% of Fortune 1000 companies use Windows’ based networks, yields a very ample attack surface for Zombie Users.

The issue of Zombie Users exacerbates for those companies that must comply with PCI DSS. The reason is that PCI section 8.1.3. mandates the immediate access revocation of any terminated user. This authentication flaw, ironically, makes section 8.1.3 a requirement that in reality cannot be met.

Understanding Zombie Users: a behind the scenes look at Kerberos

The Kerberos authentication protocol is Windows’ default authentication protocol, implemented in Windows’ Active Directory. Kerberos enables the transparent Single Sign On (SSO) experience which allows users to provide their password only once even though they access various services – whether in the corporate network or in the Cloud.

Kerberos works by exchanging the user’s supplied credentials (i.e. username/ password) for a ticket (formally known as the TGT – Ticket Granting Ticket). This ticket contains all of the user’s relevant authentication and authorization information. This information enables the KDC (i.e. the Key Distribution Center. Consider it as the Kerberos’ “key master” which grants specific access to other organizational services) to rely solely on the ticket information for the user’s authentication and authorization.

In other words, using a ticket Kerberos decouples the users’ credentials from the actual access to services.

This decoupling improves the Kerberos protocol’s efficiency as it eliminates any need to make further identification inquiries. It makes sense from an architectural point of view, and also from a security standpoint. However, it also the root cause of a serious security flaw, as we detail below.

The Inherent Problem? Credentials are Decoupled from the Actual Access to the Services

Since Kerberos authentication and authorization is based solely on the ticket – and not on the user’s credentials, it means that disabling the user’s account has no effect on their ability to access data and services.

This creates a peculiar situation in which these supposedly “dead” (i.e. disabled) users are actually still very much alive. As such, we aptly named the users in this limbo state as “Zombie Users”. These users will rest in peace only when their (TGT) ticket expires, typically after 10 hours.

Windows’ Approach to Zombie Users

To make things even worse, Windows does not provide any method to control issued tickets. Specifically, Windows does not provide the ability to revoke a particular ticket associated with a certain user.

Although this problem had not fully escaped the eyes of Windows’ programmers, Microsoft only addresses the case of a revoked user’s account access to new resources within the same domain and for periods longer than 20 minutes.

This may limit the scope of the problem, but it certainly does not solve it.

For the technical and IT readers, quoted is Microsoft’s official documentation (comments and emphasis are mine):

“Kerberos V5 does not enforce revocation of accounts prior to the expiration of issued tickets. If the POLICY_KERBEROS_VALIDATE_CLIENT bit is set in the AuthenticationOptions setting on the KDC, then KILE (Windows’s implementation of Kerberos) will enforce revocation on the account KDCs. When this property is set on the account KDC for the client’s domain, and the TGT is older than an implementation-specific time (20 minutes), the account KDC MUST verify that the account is still in good standing. Good standing means the account has not expired, been locked out, been disabled, or otherwise is not allowed to log on. If the KDC receiving the session ticket request is not in the user account’s domain, then the check cannot be made.“

Zombie Users Effect on the Organization’s Network Security

Zombie Users leave plenty of room for both malwares and malicious insiders. Here are just a few plausible scenarios abusing this insufficient security measure:

• Insider threat. For sake of discussion, let’s assume an employee Joe at a bank named ZBank. Joe is based in the in the USA, and unfortunately was terminated from employment. Upon notification of the upcoming termination, ZBank’s IT immediately disabled Joe’s account from the domain usa.zbank.com in the bank’s Active Directory. The thing is that ZBank enables employees to access organizational data through the employees’ mobile devices. So although Joe is not a technically savvy individual, Joe is still able to retrieve files on the file server residing in other trusted domains such as europe.zbank.com. The reason for this breach originated from the fact that the European domain cannot tell whether Joe’s account has been revoked in the US domain so it relies on the validity of Joe’s ticket.
• Targeted malware.  An advanced malware can exploit this design issue in order to leverage the 20-minute window of opportunity to wreak havoc prior to its containment. In this scenario, the malware continually asks for new tickets under a compromised legit account for continuous access to sensitive servers. Once the malware is exposed, the IT disables the compromised account. However, since the malware can also track its state on the Active Directory, it indicates it has been exposed and uses those last 20 minutes as its swan song.

Compensating Security Controls for Active Directory

Active Directory runs in 95% of Fortune 500 companies and plays a key in authentication and user account management. Despite its importance and prevalence, companies rely on the Active Directory built-in security model and so do not use external controls to compensate for its insufficient security posture.

Yet, Zombie Users are a very relevant example of Active Directory’s security gap.

Unfortunately, Windows’s Active Directory fails to solve the issue of Zombie Users. Worse yet, Active Directory does not externalize the ticket information through logs and events, and so exploitation of Zombie Users cannot be mitigated through traditional log and SIEM measures. A required solution needs to both enforce the termination of disabled user accounts as well as have visibility into the relevant information. The thing is that to prevent user accounts from using a ticket to begin with, requires a solution that knows what the ticket is. It’s exactly that type of crucial information that is missing from the traditional measures.

What can be done? We suggest a very natural solution based on the monitoring of the network traffic to Active Directory, to:

• Recouple the ticket with the user’s account in order to eliminate the root cause of the problem
• Monitor changes in user account’s state and activities and in particular, to the revocation of the user’s account
• Terminate requests of a disabled user requesting access to a resource using a valid ticket

Read more about Kerberos in our glossary -http://aorato.com/labs/kerberos/

Read more about TGT in our glossary – http://aorato.com/labs/kerberos-tgt/