Blog

QOMPLX Knowledge: Silver Ticket Attacks Explained

This is the second in a series of posts we are calling “QOMPLX Knowledge.” These posts are intended to provide basic information and insights about the attack activity and trends that are driving the malicious campaigns that QOMPLX front line staff encounters in our work with customers.


As we noted in our recent “ManyKatz” report: AD attacks are a common thread in many of the most high profile breaches in recent years. Ticket forgery tactics are among the most damaging tools in the Active Directory hacker’s tool box. In our last post, we profiled Kerberos Golden Ticket attacks in which an adversary gains control over an Active Directory Key Distribution Service Account (KRBTGT), and uses that account to forge valid Kerberos Ticket Granting Tickets (TGTs) for that domain.

In this post, we’re going to explain a close cousin to those: so-called “Silver Ticket” attacks. Though less flexible than Golden Ticket attacks, Kerberos Silver Ticket attacks are, in some ways, even more dangerous because they’re harder to detect. Here’s what you need to know:

Key Points

  • A Silver Ticket is a forged Kerberos Ticket Granting Service (TGS) ticket (aka “service ticket”).
  • Kerberos Silver Ticket attacks are related to- but more limited in scope than Golden Ticket attacks. They give attackers access to a single service on an application, not any Kerberos-authenticated service, as with Golden Tickets which give power over an entire domain.
  • Kerberos Silver Tickets require attackers only to have access to credentials harvested from the computer’s Security Account Manager (SAM) or local service account.
  • An adversary forges the TGS ticket using the service account password hash. No intermediary TGT (Ticket Granting Ticket) is needed. That means Silver Ticket attacks can be created without any communication with a Domain Controller, making them easier to generate and harder for targeted organizations to detect. It also means that network taps and span port devices typically used for network security monitoring won’t reliably observe the attack.
  • Domain administrators must have the ability to monitor for the tell-tale signs of these stealthy Active Directory attacks. Fast, accurate, and deterministic detection of Silver Ticket attacks is what QOMPLX’s technology makes possible and are one of the few ways to spot attacks on Active Directory early enough to enable rapid response and remediation.

History of Silver Ticket Attacks

Silver Ticket attacks were first introduced in 2014 by Benjamin Delpy and Skip Duckwall, inventors of the Mimikatz tool. Both the Silver Ticket and Golden Ticket attacks were discussed at a series of public and private talks, including a talk entitled “Reality Bites” (PDF) which was given at Microsoft’s internal Blue Hat security conference in 2014 and the talk “Abusing Microsoft Kerberos: Sorry You Guys Don’t Get It” at the Black Hat Briefings in the same year.

Less powerful and dramatic than the Golden Ticket attack, Silver Ticket attacks were not as widely publicized at the time. However, the low threshold for carrying out a successful Silver Ticket attack and their utility in escalating privileges as part of an attack chain on a compromised environment have since made them a widely used tool both by internal “red teams” and by malicious cyber criminal and nation state attack groups. Support for generating Silver Tickets is now a standard feature on tools including Mimikatz, further lowering the bar to their use in attacks by even low-skill adversaries.

How Kerberos Silver Ticket Attacks Work

Silver Ticket Attacks are post-exploitation attacks. That means that a threat actor must already have compromised a target system in the environment before they can generate a Kerberos Silver Ticket.  The initial system compromise may involve the use of a phishing email campaign, exploitation of a vulnerable or misconfigured, public facing IT asset, or a malware infection—targeted or otherwise.

Whatever the circumstances, once an attacker has a foothold on a single network system, they can start laying the groundwork for forging a Kerberos Silver Ticket. This involves:

  1. Conduct reconnaissance to gather information about the domain, such as the domain name and domain security identifier (SID), both of which are relatively easily obtained by a whoami command on Windows.
  2. Obtain the DNS name under which the service principal name (SPN) for the targeted, local service they wish to attack is registered as well as the service type.
  3. Use Mimikatz or a similar tool to obtain the local NTLM password (or password hash) for the Kerberos service running on the compromised system, for example: Windows file share, SQL, email, Microsoft Sharepoint and so on. Service password hashes can be obtained from a number of sources on a compromised local system. For example, they can be dumped from the local computer’s Security Account Manager (SAM) or local service account.
  4. Obtain the unencrypted password for the service. These can be obtained from the hash using methods like offline cracking (“Kerberoasting”) to obtain the unencrypted password data.
  5. Use Mimikatz or a similar tool to forge a Kerberos Ticket Granting Service (TGS) ticket allowing the attacker to authenticate to the targeted service.
  6. Authenticate to the local service directly using the credentials and forged TGS.
  7. Manipulate the TGS to elevate the attacker’s permissions to that of Domain Administrator.

The power of Silver Ticket attacks is that an adversary can leverage low level access to a single compromised system in an environment and use that to authenticate to- and gain control over a Kerberos service on that system. That, in turn, can allow them to run code as the local system.

Their other advantage is that, because of common configuration flaws, TGS tickets can be forged locally, without communicating with the local Domain Controller. This allows attackers to avoid having to first obtain credentials for the Domain Controller (a much higher bar to clear). Microsoft added a security check to its implementation of Kerberos known as the Privilege Attribute Certificate (PAC) that requires the TGS to be signed by the KDC using the krbtgt encryption key. However, this check is often disabled in customer environments. The result is that an attacker can generate a TGS directly without obtaining a TGT from a KDC. The TGS can then be used to authenticate to the service locally without any input from the Kerberos Domain Controller (KDC).

How to Stop Silver Ticket Attacks

Attackers who have forged a Kerberos “Silver Ticket” are difficult to spot. For one thing: Silver Tickets can be generated locally on a compromised host, without any communications to or authentication by the local KDC. With the access granted by a Silver Ticket, a knowledgeable attacker can quickly escalate their privileges on a network, eventually obtaining access to a local Domain Controller and, potentially, generating a Golden Ticket that will give them a more-or-less permanent foothold within a target environment. Still, Silver Ticket attacks can be identified and stopped. Here are very basic steps to mitigate these dangerous attacks:

Prevent Attacks with Patching

Stop compromises before they happen by reinforcing security education awareness, including training about password reuse and phishing attacks, and conducting vigilant patch management.

Enforce User Least Privilege

Rely on a least-privilege model to restrict user and domain administrator access; limit the number of administrator accounts. Limit Domain Administrator accounts as well to those running on the Domain Controller and to servers where Domain Controller level access is required.

Audit and Strengthen User and Service Accounts

Because offline cracking of credentials is a key component of Silver Ticket attacks, ensure that local user, administrator and service accounts use strong, unique passwords. In addition, organizations should make sure that credentials are not shared across accounts on the local system or with other network services and resources.

Enforce PAC Authentication for TGS

Make sure that your Kerberos implementation is leveraging the Privilege Attribute Certificate (PAC) and requiring the TGS to be signed by the KDC using the krbtgt encryption key.

Validate the Kerberos Protocol

Implement tools that allow you to conduct external, stateful validation of the Kerberos protocol. This is required to ensure that every ticket presented by a Kerberos principal (i.e. service client) has been issued by a legitimate key distribution center.  This requires collecting and validating all Kerberos authentication messages for each SPN being protected.

Conclusion

As sophisticated attackers turn their attention to critical identity infrastructure like Active Directory, enterprises need to be ready: shoring up the security of critical infrastructure like Active Directory and MIT Kerberos environments on Linux.

Real-time analytics with external stateful validation means that Kerberized applications can still be authenticated with confidence. However, no analytics can offer similar levels of confidence for NTLM.

QOMPLX’s technology helps organizations establish “ground truth” within organizations. By validating critical platforms like AD, QOMPLX helps ensure that other security controls, tools, and processes continue to operate as intended. As attacks on AD and other identity infrastructure proliferate, QOMPLX makes it faster and easier for organizations to integrate disparate internal and external data sources across the enterprise via a unified analytics infrastructure that supports better decision-making at scale.

Additional Reading

More Posts

Card image cap
Ransomware's Effects Linger Long After Attack, Study Finds

Published Oct 15, 2020

Card image cap
October: Cybersecurity Awareness Month and Its Discontents

Published Oct 02, 2020

Card image cap
CISA Report: Unpatched VPN, Credential Theft Fueled Agency Hack

Published Sep 28, 2020

Card image cap
Zerologon is a Big Deal. Here’s Why.

Published Sep 21, 2020