QOMPLX Knowledge: Pass-the-Ticket Attacks Explained

This is the latest in a series of posts we’re calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving malicious campaigns and that QOMPLX researchers encounter in our forensic work with customers.

--

Pass-the-Ticket attacks take aim at Kerberos much in the same way as Golden Ticket and Silver Ticket attacks, both of which exploit unfixable weaknesses in the authentication protocol. Except with Pass-the-Ticket attacks, a threat actor won’t be forging Kerberos tickets. Instead, they will steal valid tickets that have already been created and issued, and pass them from one system to another in order to access resources as a legitimate, privileged user.

Key Points

• Pass-the-Ticket attacks are valid Kerberos ticket granting tickets (TGTs) and service tickets that are stolen from authenticated users and passed between services for privileged access.
• Common hacking tools such as Mimikatz and Rubeus facilitate Pass-the-Ticket attacks by extracting TGTs and service tickets from the LSASS process in Windows.
• Detection and mitigation of Pass-the-Ticket attacks are challenging and require technology that monitors Kerberos traffic for the same ticket appearing in multiple sessions.
  
  

How a Pass-the-Ticket Attack Works

Pass-the-Ticket attacks are a category of post-exploitation attacks involving the theft and re-use of a Kerberos ticket to authenticate to systems in a compromised environment. In Pass-the-Ticket attacks, adversaries steal a Kerberos ticket from one computer and re-use it to get access to another computer in a compromised environment.

Within Active Directory, a Ticket Granting Ticket (TGT) provides proof that a user is who they say they are. Domain controllers, which respond to and verify authentication requests, receive requests for access to services, validate the TGT, and then package the rights conferred in the TGT with the service ticket, encrypting it so that only the domain controller and service can decrypt the ticket. The service inherently trusts the domain controller, so the ticket is passed and decrypted, and the user gains access to the service.

From the perspective of an attacker, Pass-the-Ticket attacks provide a way to gain privileged access to network resources without needing to obtain an actual user password. Using a host of available tools and techniques—most notably Mimikatz and Rubeus—an attacker can harvest these tickets, which are cached in the memory of compromised systems, and present them in order to request Kerberos service tickets from the Kerberos Ticket Granting Service (TGS) and access resources elsewhere on the network.

In such a post-exploitation attack, a threat actor must first penetrate a system, often via phishing or by using social engineering to gain valid user credentials. Once an attacker is on a system, they will attempt to elevate privileges to get access to tickets stored in other Active Directory sessions. Tools such as Mimikatz or Rubeus can be loaded onto a compromised Windows machine in order to extract the TGT from the Local Security Authority Subsystem Service (LSASS) process where it is stored.

Multiple accounts may be logged in to a system, each with its own session. Furthermore, sessions are isolated within AD in order to prevent other sessions from accessing any data. If an attacker is able to elevate to administrator or system privileges, they can reach into other sessions and extract valid tickets from other users, extending their access to network resources.

If an attacker has administrator privileges on that computer and access to that user’s valid tickets, they can pass those tickets as they move laterally within an environment, gaining access to services such as file shares or platforms such as Exchange or SharePoint. This activity can last as long as the ticket is valid—usually for 10 hours.

Responding to Pass-the-Ticket Attacks

Detecting and mitigating Pass-the-Ticket attacks is challenging. Kerberos—the underlying ticketing protocol used by Active Directory—is a stateless protocol, meaning that transactions are not retained throughout an authentication session, or after. That makes Kerberos—and Active Directory, by extension—vulnerable to Pass-the-Ticket attacks, as well as potentially devastating Golden Ticket and Silver Ticket attacks that used forged tickets to grant domain or service rights, respectively. Kerberos’s stateless design also makes re-use of stolen credentials a security and privacy issue. External, stateful validation of the Kerberos protocol is required to assure that every ticket presented by a Kerberos principal (i.e. service client) was issued by a legitimate key distribution center.

Detecting Pass the Ticket Attacks

At a high level, organizations can detect Pass the Ticket attacks by detecting the re-use of the same Kerberos session ticket on two or more different computers. Technology such as QOMPLX’s Q:Cyber helps organizations do just that: monitor and audit Kerberos traffic for tickets that appear on multiple system IP addresses.

Q:Cyber’s approach is to instrument endpoints such as domain controllers and servers with agents that do passive, stateful validation of Kerberos traffic. The technology maintains a ledger of Kerberos transactions, enabling it to validate requests for access to services, and detect Pass-the-Ticket and ticket forgery attacks in near-real time.

Additionally, organizations should audit Kerberos authentication and credential events for discrepancies, such as remote authentication that correlates with suspicious activity. Such events could indicate a Pass-the-Ticket attack is taking place.

Organizations may also rely on endpoint detection and response technology to do local detection of multiple tickets for the same session. Microsoft has introduced some hardening in Windows 10 that will defend against Pass-the-Ticket and Pass-the-Hash attacks targeting domain credentials.

Mitigating Pass the Ticket Attacks

Upon detecting a Pass-the-Ticket attack, your response depends on the level of access the attack provided. If the compromised account from which the TGT or service ticket was stolen was a low privilege account with limited or no permissions outside of the compromised system, mitigation could be as simple as resetting the user’s Active Directory password. That would  invalidate the stolen TGT or service tickets and prevent the attacker from generating new tickets using the stolen password hash.

However, if the Pass-the-Ticket attack is associated with a privileged account, containing the damage is considerably harder. In these scenarios, organizations should respond as they would to a Golden Ticket or Silver Ticket Kerberos forgery attack: resetting the KRBTGT service TWICE in order to generate a new signing key, and ensure the compromised key has been deleted.

Organizations should further analyze Kerberos logs and Active Directory information to understand which network resources a threat actor accessed via the Pass-the-Ticket compromise and what data may have been taken. Technology such as Q:Cyber allows organizations to ingest, parse and analyze this data.

Additional Reading:

Here are the previous entries in our QOMPLX Knowledge series; look for more in our QOMPLX Knowledge series in the days and weeks ahead:

QOMPLX Knowledge: Golden Ticket Attacks Explained

QOMPLX Knowledge: Silver Ticket Attacks Explained

QOMPLX Knowledge: Responding to Golden Ticket Attacks

QOMPLX Knowledge: DCSync Attacks Explained

QOMPLX Knowledge: DCShadow Attacks Explained

Other links to consider:

MITRE Att&ck: Pass the Ticket

Gentil Kiwi: Pass the Ticket

AD Security: Mimikatz and Active Directory Kerberos Attacks

QOMPLX: The Importance of Lateral Movement Detection

Tarlogic: How to attack Kerberos

Rubeus