Your Knowledge Center for all Active Directory Security-Related Research

Pass-the-Ticket

Overview
Pass the Ticket (PtT) is an attack where the adversary steals a user’s Kerberos authentication ticket in order to impersonate that user against various enterprise resources.

All Windows-based servers as of Windows 2000 use Kerberos as their default authentication protocol and as such, are susceptible to this kind of attack. However, this attack is not only confined to Windows but to any system which implements Kerberos in its backend (for example, all Linux-based systems). 

Kerberos Authentication Protocol – Background
The Kerberos authentication protocol enables the transparent Single Sign On (SSO) experience. The SSO enables users to actively authenticate (i.e. provide their password) only once even though they access various services – whether in the corporate network or in the Cloud (whereas the Kerberos ticket is translated to SAML tokens).

The Kerberos Authentication protocol works in the following manner:

 Kerberos Flow

  1. The user provides the Domain Name, user and password to access their computer.
  2. The computer authenticates to the Authentication Server (AS) residing on the Key Domain Controller (KDC). Accordingly, the KDC provides the computer with a Ticket Granting Ticket (TGT). The TGT is an identifier which enables the computer to request access to services without having the user to re-supply their credentials.
  3. Each time the computer attempts to access a service, it first identifies itself to the Domain Controller (DC), residing on the KDC, with the TGT as provided earlier by the AS. The DC, through its Ticket Granting Server (TGS), provides the user with a ticket for the particular requested service.
  4. The user provides the service ticket to the service. Since the ticket was validated by the TGS, the service grants authorization. Accordingly, the connection between the user and the service is established. 

 

Pass the Ticket Attacks
Pass the Ticket (PtT) actually includes various attack scenarios:

  1. An attacker steals tickets (whether TGT or service tickets) from the user’s local machine. By default, and by design, the tickets are stored on the end-user’s machine. Consequently, an attacker that steals a user’s ticket can impersonate the user to various enterprise services: from data stores that hold intellectual property to Cloud-based systems. A stealthy attacker can further utilize the tickets to gain lateral movement within the enterprise- say, moving from one machine to the next in order to gain elevated permissions or access a highly sensitive computer.
  2. An attacker steals users’ TGT tickets or service tickets by compromising delegated server. In this scenario, the service is delegated to request system or service access on the user’s behalf (aka “Double Hop”). As a result, the server running the delegated service must store the users’ tickets for the requested access. An attacker compromising the delegated server essentially obtains all the tickets stored on that machine and can access further services on behalf of any of the users. An attacker can also perform an effective Denial of Service (DoS) by preventing any user to continue and access further resources. 
    For instance, an SSL VPN can be configured as a “trusted for delegation” entity and, on behalf of the users, ask for their tickets to the organizational SharePoint. An attacker, on the one hand, can remotely access the enterprise’s SharePoint by impersonating any employee connecting via the enterprise’s VPN. On the other hand, the attacker can also deny users from authenticating to the SharePoint server. 
    As another example, consider the case of a database holding credit card data and is accessed via a dedicated SharePoint Web interface. Due to PCI compliance the database is separated from the SharePoint server which, in turn, is delegated to perform authorization on users’ behalf. An attacker compromising the SharePoint server obtains access to all the stored tickets and can effectively log in to the database on their behalf. 

 

Pass the Ticket Attacks – Points to Consider

  1. PtT attacks are falsely perceived as an attack which is generated only through domain computers. The reason for this misconception is that domain computers authenticate via Kerberos.
  2. The thing to notice, however, is that any computer, whether within the domain or not, can perform Kerberos authentication. For example, an attacker can inject a non-domain computer with a stolen ticket and cause the authentication process to proceed as usual.
  3. Security issues associated with delegation are exacerbated given that the KDC is controlled and maintained by IT teams – and not by the security teams. Given the less-paranoiac nature of IT admins, they may not realize that they are performing delegation (e.g. “2-click configuration”), or are not fully aware of the risks that delegation poses. Worse yet, some systems such as certain Business Intelligence services installed on SharePoint, require delegation in order to be installed. 

 

Pass-the-Ticket Attacks in the Wild
PtT attacks are easy to implement, where common automated pen-testing tools, such as WCE (Windows Credential Editor), include the support of this type of attacks. PtT attacks are also an initial step in an APT attack. In fact, Microsoft admitted to the security issue that Active Directory faces through PtT attacks already in 2013 during their BlueHat Conference.

 

Failed Attempts at Mitigating Pass-the-Ticket Attacks
Unfortunately, the following solutions and best practice have proven to fail in mitigating PtT attacks:

  • Limiting the tickets’ lifetime
    Currently, TGTs are limited to 10 hours and service tickets are limited to 10 hours. However, this timeframe is still reasonable for an attacker executing on a user’s machine and waiting for the exact timeframe to operate. More so, Windows by default allows extending the ticket’s expiration by 7 days.
  • Placing systems that randomly change the passwords.
    This solution does not attempt to address the problem since the attack has nothing to do with passwords. Once the user logs on to their computer, in whatever way, the granting of the TGT takes place.
  • Using multi-factor authentication
    Smart cards, bio metric solutions, and other multi-factor authentication measures do not attempt to address the problem either. The point is that the user receives the Kerberos ticket after the authentication process completes. In other words, once the user has authenticated – through any secure measure – an attacker is able to proceed with the ticket theft.
  • Activating logs
    Logs may indicate suspicious behavior; however, they do not detect the attack or mitigate it. More so, since in this attack the attacker impersonates a legitimate user – the indicators of attack are extremely subtle and may be drowned out by the sea of other log events.
  • Enforce the re-booting of user systems and the quitting of all client applications that access Kerberos-system when users leave their work area
    This measure will not prevent the theft of tickets since malware installed on a compromised machine can steal the user’s ticket at any stage. With today’s malwares being capable of surviving re-boots, the malware can import the stolen ticket which remains valid once the OS runs again. 

 

Detecting Pass the Ticket Attacks
Measures for detecting and preventing PtT attacks include:

  • Learning the behaviors of all entities (privileged and non-privileged in the organization) and correlating their performed activities.
  • Analyzing authentication protocols to detect and alert on violations.

Further Reading:

http://www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf

http://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2012-Sessions/BH1208

http://technet.microsoft.com/en-us/library/cc961963.aspx