This is the latest 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.
Recently we described Kerberos Silver Ticket attacks. These are a dangerous type of Kerberos ticket forgery in which an adversary gains control over a local or domain administrator account in an Active Directory environment and abuses that access to forge a Kerberos Ticket Granting Service (TGS) ticket (aka “service ticket”). This gives the attacker access to a single service on an application. That limited access is often exploited to elevate an attackers privileges on a local host and commence lateral movement within a compromised environment.
Now that we have explained how Silver Ticket attacks work, it’s time to talk about how to best investigate and recover from them. Here are the steps organizations should take to detect, analyze, and recover from Kerberos Silver Ticket attacks.
- Basic security hygiene is critical in preventing attackers from gaining a network foothold and initiating a Silver Ticket Attack that facilitates privilege escalation and lateral movement. That means: keep Windows clients and servers up-to-patch, because most initial incursions exploit weaknesses for which there are already patches available.
- Silver Ticket attacks begin with compromises of local user and service accounts. That puts the onus on organizations to enforce strict access controls: employing user "least privilege" and auditing both user and service accounts for password strength and other risk factors.
- In the event of a Silver Ticket attack, determine if subsequent actions were taken to elevate the attackers’ permissions and execute a Domain Controller compromise.
- If a domain compromise is detected subsequent to a Silver Ticket attack, reset the KRBTGT service TWICE in order to generate a new signing key, and ensure the compromised key has been deleted.
- During recovery, parse and analyze Kerberos logs and Active Directory information to understand which network resources a threat actor accessed subsequent to launching the Silver Ticket attack, and what data may have been taken. Technology such as QOMPLX’s allows organizations to ingest, parse and analyze this data.
As we discussed in our prior blog post, a Kerberos Silver Ticket gives adversaries the ability to forge new Kerberos Ticket Granting Service (TGSs) tickets within a compromised Active Directory environment. An adversary forges the TGS ticket using the service account password hash. No intermediary TGT (Ticket Granting Ticket) is needed. That means Silver Ticket forgeries can be created without any communication with a Domain Controller. Also: any event logs that might reveal the Silver Ticket attack are stored on the targeted server, meaning that careful attackers can simply modify or delete them to remove evidence of their activity. Once created, the forged TGS can be used to authenticate to the service locally without any input from the Kerberos Domain Controller (KDC).
While more limited than Golden Ticket forgeries, Silver Tickets are both easier to generate and harder for targeted organizations to detect; network taps and span port devices typically used for network security monitoring won’t reliably observe a Silver Ticket attack.
Step 1: Prevention
Silver Ticket Attacks are post-exploitation attacks. A threat actor must already have compromised a target system in an environment before they can generate a Kerberos Silver Ticket. That initial system compromise will likely follow a well established pattern, for example: a phishing email campaign, exploitation of a vulnerable public-facing IT asset, or a malware infection impacting one or more network endpoints.
Given the difficulty of detecting Silver Ticket attacks as they happen, an enterprise's best and most effective defense is to prevent exploitation of its network in the first place. The best way to do that is to promote and enforce basic security hygiene as a front-line defense. That includes:
- Providing rigid security awareness training that teaches employees safe internet habits, including how to spot phishing attacks, where to report them, the business consequences of clicking on random links in email, social media, messaging applications, the risks of removable media, and more.
- Enforcing the principle of least privilege for user accounts. Organizations should strictly limit the number of admin accounts and remove all regular users from local admin groups. Beyond that, policy should dictate that user and local accounts have access only to those resources required to carry out their job functions. That same principle should also apply to applications, limiting their access to resources as well.
- Prioritizing vulnerability and configuration management, and patch high-risk systems. Eliminating exploitable security holes is the best way to reduce the number of potential exposures that can be leveraged by an external threat actor or malicious insider.
- Enabling security features designed to prevent ticket forgeries such as the Microsoft Privilege Attribute Certificate (PAC) that requires the TGS to be signed by the KDC using the KRBTGT encryption key.
Step 2: Detection
As we noted, a compromise that leverages a Kerberos Silver Ticket can be difficult to detect. Attackers who have forged Silver Tickets are indistinguishable from legitimate, credentialed services within a network. Also, attackers will quickly use the limited access provided by the Silver Ticket forgery to further escalate their privileges and access hosted services with administrative rights on the compromised host.
Silver Ticket 'Tells'
Silver Ticket detection need not be complicated. For example, User and Entity Behavior Analytics (UEBA) tools running on networked endpoints can spot suspicious or malicious activity, such as the installation or use of tools like Mimikatz that create the Kerberos forgeries. That's especially true if attackers don't take steps to disguise the Mimikatz executable or fail to change telltale Mimikatz default settings when generating their Silver Ticket.
Even if you are unable to spot deployment of tools like Mimikatz, researchers like Sean Metcalf, founder and principal consultant at security consultancy Trimarc, have noted that forged Kerberos tickets generated by Mimikatz and other tools differ in subtle ways from (legitimate) Kerberos tickets generated by Active Directory. While many of those discrepancies have been addressed in recent releases of Mimikatz and other tools, some notable gaps still exist. For example, RC4 encrypted Kerberos tickets are rare on modern networks as AES Kerberos encryption has been supported by Windows since the release of Windows Vista and Windows Server 2008. Modern networks, Metcalf suggests, would not use a broken cipher such as RC4, and today’s Windows would support reliable encryption ciphers such as current versions of AES.
Stateful Inspection of Kerberos
Detection requires organizations to validate the Kerberos protocol to spot forged Silver Tickets from otherwise legitimate network traffic. Implement tools, such as QOMPLX's Q:CYBER Identity Assurance (IA) that allow you to conduct external, stateful validation of the Kerberos protocol. Q:CYBER IA can 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.
Q:Cyber Identity Assurance maintains this stateful view of Kerberos authentication with a ledger of valid tickets issued from domain controllers. New authentication requests are compared to a known list of valid tickets, allowing QOMPLX:CYBER to detect Silver and Golden Tickets regardless of attempts to simulate a validly issued Kerberos ticket.
Step 3: Response
Recent incidents have shown how compromises of Active Directory often precede devastating hacks, including deployment of ransomware and wholesale theft of data and intellectual property. That’s why, if detected or even suspected, a forged Kerberos ticket attack should trigger an immediate response from your security operations center (SOC), computer incident response team (CIRT), or third-party service provider.
As part of their response to Kerberos forgeries, organizations will want to answer some form of the following questions during what are often catastrophic breaches enabled by Golden- and Silver Ticket Attacks. Among those questions:
- How did the attackers initially access the network?
- What accounts were compromised by the attackers?
- Which IT assets have attackers accessed and/or compromised?
- What information have the attackers accessed and exfiltrated?
With a Kerberos Silver Ticket, attackers access is limited in scope to the targeted service on the compromised server. Still, it is critical to monitor for efforts to leverage Silver Tickets to elevate privileges and move laterally within an environment.
Step 4: Re-image, or Watch and Learn
Once a forged Silver- or Golden Ticket Attack has been detected and the basic dimensions of the compromise are understood, organizations face a choice: shut down affected accounts and take compromised assets offline to stop the attack, or hold back and observe the attackers at work.
Resources, visibility may limit choices
In QOMPLX’s experience, most compromised organizations choose the former; they shut down affected accounts, reset passwords, re-image systems, change remote access systems, and implement additional controls in the hopes of shutting down all avenues to future threat actors. A rebuild may be an organization’s best option given available resources and visibility into such network activity. While understandable, this response eliminates the possibility of analyzing the attack and determining its full extent: what was accessed, and possibly who was behind the attack.
Observation carries risks
For organizations that choose to delay a response in order to learn about the compromise, technology such as QOMPLX’s can be used to observe the attackers as they move laterally on the network. The knowledge gained in observing attackers’ access to a compromised environment can be used to create events and rulesets as activity emerges. For example, victims can identify call-outs to certain command and control infrastructure, browsing of internal data stores, opening ports, accessing new accounts, and more. As this observation continues, behind the scenes, security organizations should also work closely with senior management, legal, and human resources teams during a compromise to prepare should the conditions change and a more active response becomes necessary.
No easy answers
By allowing an attack to continue, organizations accept short term pain (continued attacker access to their environment) for long term gain: better knowledge of how many accounts have been compromised; which systems those accounts have accessed; and whether the attack can be traced using logs and tools. Further observation might reveal how the attackers gained a foothold and what they were after; all of this better informs next steps for decision makers. However, there is no guarantee that victims will be successful in observing attackers: behavior might get missed, or attackers may become aware they are being watched and act accordingly by accelerating their attack and forcing the organization’s response. The choice to either respond or to observe isn’t binary and organizations should develop detailed contingency plans should their stealth observation fail and active response becomes necessary.
Step 5: Reset and Recover
Once the organization has a fuller understanding of the incident, it is well positioned to recover from it. This could include disabling all but a few of the lowest-privileged accounts, blocking external IP addresses associated with the attacks and, implementing redirects for suspicious traffic to honeypots.
By monitoring the few remaining active accounts, investigators could understand secondary attack paths used by the threat actors and whether they have dropped a backdoor into an organization that could be used indefinitely.
External validation of Kerberos
First, external validation of the Kerberos protocol is required to assure that every ticket presented by a Kerberos principal (i.e. service client) was in fact issued by a legitimate key distribution center. Microsoft has created a script to facilitate changing KRBTGT account passwords to minimize negative impacts.
Reset KRBTGT account
The next step in recovery is resetting the KRBTGT. For forged tickets, the KRBTGT service must be reset twice, once to generate a new key and a second time to delete the compromised key. It’s worth noting that if the attack paths used by a threat actor have not been addressed and shut down, resetting the KRBTGT account would be at best a temporary safety measure as an attacker could re-use their access to compromise other accounts and forge new tickets.
Rebuild and recover
Breached organizations may opt to immediately rebuild compromised systems, including resetting both end-user and service accounts and limiting access from outside in order to ensure continuity. Credentials and keys should likewise be reset for any “crown jewel” services or anywhere that evidence suggests a compromise has taken place. This is a disruptive, time consuming and costly process, but it can be a more favorable option than monitoring an attacker’s movements for a longer period of time, depending on data sensitivity, system visibility, and the ability to accept downtime.
The biggest challenge in this scenario is that it becomes nearly impossible to confirm how access was first achieved. As a result, recovery may not be complete at this point. Subsequent investigation should consider network assets such as VPN connections or local accounts that could be missed during cleanup. A thorough accounting of these and continued monitoring is needed to prevent an attacker from gaining a foothold and finding their way back into the network.