T1558.002: Silver Ticket

Silver Ticket is a Windows Kerberos credential-access technique where an adversary with a target service account password hash can forge service tickets for a specific resource such as MSSQL or SharePoint. Its business significance is that the abuse can be narrower than a domain-wide Golden Ticket but harder to see if monitoring depends only on the Key Distribution Center, because forged service tickets may be created without KDC interaction.

Executive priority

Prioritize this where Windows domain services rely on high-value service accounts. Leaders should ask whether service account hashes are protected, whether privileged/service account use is logged and reviewed, and whether detection can connect service access to legitimate Kerberos activity. This is especially relevant for identity assurance, incident response scoping, audit evidence around privileged account control, and continuity of critical Windows-hosted applications.

Technical view

For SOC and IR teams, validate coverage around T1558.002 as part of the broader Steal or Forge Kerberos Tickets technique. The key defensive question is not only whether Kerberos ticket requests are logged, but whether teams can identify suspicious service access when no corresponding KDC interaction is observed. Use the DET0241 relationship as the ATT&CK detection-strategy anchor, and correlate with precursor evidence for OS Credential Dumping or Kerberoasting where available. Also account for related software relationships: Mimikatz, Empire, AADInternals, and Rubeus are listed as using this technique, so endpoint and scripting telemetry can provide important context.

Likely telemetry

Windows Kerberos authentication and service-access records for domain resources such as database or collaboration services
KDC/TGS request logs or equivalent identity-provider telemetry to compare expected ticket issuance with service access
Service account logon and privileged account activity logs
Endpoint process execution and command-line telemetry on Windows systems
PowerShell activity where relevant to related tooling such as Empire or AADInternals

Detection direction

Do not rely solely on KDC-side Kerberos request visibility; the ATT&CK description notes Silver Tickets can be created without KDC interaction.
Validate DET0241-aligned analytics for forged Kerberos Silver Ticket behavior in the local Windows domain environment.
Correlate access to a specific service with whether a legitimate TGS request was observed for that account, service, and timeframe.
Tune for the fact that Silver Ticket scope is service-specific; detection should focus on sensitive service accounts and high-value resources rather than only domain-wide anomalies.
Use related-tool telemetry as context, but avoid treating tool names alone as proof of Silver Ticket use without Kerberos/service-access evidence.

Mitigation priorities

Strengthen privileged and service account management per M1026: enforce least privilege, restrict service account scope, monitor privileged use, and maintain accountability through logging and auditing.
Apply strong password policy controls per M1027 to reduce the likelihood that service account credentials or hashes remain useful for long periods.
Protect sensitive information per M1041 where applicable, especially credential material and systems that store or process service account secrets.
Prioritize service accounts tied to critical Windows-hosted resources such as databases or collaboration platforms.
During IR, rotate or otherwise invalidate affected service account credentials when evidence indicates a service account hash may be compromised, following local change-control requirements.

Analyst notes and limits

ATT&CK provides no official detection text for this object, but it does provide a detection-strategy relationship, mitigation relationships, related software, and key behavioral constraints. The most decision-useful point is the KDC visibility gap: service-side and endpoint evidence matter because forged TGS tickets may not create normal KDC request telemetry.

This take is based only on the supplied ATT&CK fields, references, and relationships. It does not assert active exploitation, attribution, customer exposure, or guaranteed detection. Exact event IDs, vendor detections, and response playbooks require local Windows domain architecture, logging configuration, service account inventory, and SIEM/EDR capability review.

Official MITRE ATT&CK definition

Silver Ticket

Adversaries who have the password hash of a target service account (e.g. SharePoint, MSSQL) may forge Kerberos ticket granting service (TGS) tickets, also known as silver tickets. Kerberos TGS tickets are also known as service tickets.[1]

Silver tickets are more limited in scope in than golden tickets in that they only enable adversaries to access a particular resource (e.g. MSSQL) and the system that hosts the resource; however, unlike golden tickets, adversaries with the ability to forge silver tickets are able to create TGS tickets without interacting with the Key Distribution Center (KDC), potentially making detection more difficult.[2]

Password hashes for target services may be obtained using OS Credential Dumping or Kerberoasting.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1558	Steal or Forge Kerberos Tickets	This object subtechnique of Steal or Forge Kerberos Tickets.

Associated objects

Groups, software, and campaigns

S1071: Rubeus

Rubeus is a C# toolset designed for raw Kerberos interaction that has been used since at least 2020, including in ransomware operations.[1][2][3][4]

Windows

S0677: AADInternals

AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[1][2]

WindowsOffice SuiteIdentity Provider

S0002: Mimikatz

Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks. [1] [2]

Windows

S0363: Empire

Empire is an open-source, cross-platform remote administration and post-exploitation framework that is publicly available on GitHub. While the tool itself is primarily written in Python, the post-exploitation agents are written in pure PowerShell for Windows and Python for Linux/macOS. Empire was one of five tools singled out by a joint report on public hacking tools being widely used by adversaries.[1][2][3]

LinuxmacOSWindows

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1027: Password Policies Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise uses · Tool S1071: Rubeus Enterprise detects · Detection Strategy DET0241: Detect Forged Kerberos Silver Tickets (T1558.002) Enterprise uses · Tool S0677: AADInternals Enterprise uses · Tool S0002: Mimikatz Enterprise subtechnique of · Technique T1558: Steal or Forge Kerberos Tickets Enterprise uses · Tool S0363: Empire Enterprise mitigates · Mitigation M1041: Encrypt Sensitive Information Enterprise

Mitigations

Mitigation direction

M1027: Password Policies

Set and enforce secure password policies for accounts to reduce the likelihood of unauthorized access. Strong password policies include enforcing password complexity, requiring regular password changes, and preventing password reuse. This mitigation can be implemented through the following measures:

Windows Systems:

- Use Group Policy Management Console (GPMC) to configure: - Minimum password length (e.g., 12+ characters). - Password complexity requirements. - Password history (e.g., disallow last 24 passwords). - Account lockout duration and thresholds.

Linux Systems:

- Configure Pluggable Authentication Modules (PAM): - Use `pam_pwquality` to enforce complexity and length requirements. - Implement `pam_tally2` or `pam_faillock` for account lockouts. - Use `pwunconv` to disable password reuse.

Password Managers:

- Enforce usage of enterprise password managers (e.g., Bitwarden, 1Password, LastPass) to generate and store strong passwords.

Password Blacklisting:

- Use tools like Have I Been Pwned password checks or NIST-based blacklist solutions to prevent users from setting compromised passwords.

Regular Auditing:

- Periodically audit password policies and account configurations to ensure compliance using tools like LAPS (Local Admin Password Solution) and vulnerability scanners.

*Tools for Implementation*

Windows:

- Group Policy Management Console (GPMC): Enforce password policies. - Microsoft Local Administrator Password Solution (LAPS): Enforce random, unique admin passwords.

Linux/macOS:

- PAM Modules (pam_pwquality, pam_tally2, pam_faillock): Enforce password rules. - Lynis: Audit password policies and system configurations.

Cross-Platform:

- Password Managers (Bitwarden, 1Password, KeePass): Manage and enforce strong passwords. - Have I Been Pwned API: Prevent the use of breached passwords. - NIST SP 800-63B compliant tools: Enforce password guidelines and blacklisting.

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

M1041: Encrypt Sensitive Information

Protect sensitive information at rest, in transit, and during processing by using strong encryption algorithms. Encryption ensures the confidentiality and integrity of data, preventing unauthorized access or tampering. This mitigation can be implemented through the following measures:

Encrypt Data at Rest:

- Use Case: Use full-disk encryption or file-level encryption to secure sensitive data stored on devices. - Implementation: Implement BitLocker for Windows systems or FileVault for macOS devices to encrypt hard drives.

Encrypt Data in Transit:

- Use Case: Use secure communication protocols (e.g., TLS, HTTPS) to encrypt sensitive data as it travels over networks. - Implementation: Enable HTTPS for all web applications and configure mail servers to enforce STARTTLS for email encryption.

Encrypt Backups:

- Use Case: Ensure that backup data is encrypted both during storage and transfer to prevent unauthorized access. - Implementation: Encrypt cloud backups using AES-256 before uploading them to Amazon S3 or Google Cloud.

Encrypt Application Secrets:

- Use Case: Store sensitive credentials, API keys, and configuration files in encrypted vaults. - Implementation: Use HashiCorp Vault or AWS Secrets Manager to manage and encrypt secrets.

Database Encryption:

- Use Case: Enable Transparent Data Encryption (TDE) or column-level encryption in database management systems. - Implementation: Use MySQL’s built-in encryption features to encrypt sensitive database fields such as social security numbers.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release: 19.1
Object version: 1.1
Created: Feb 11, 2020, 19:14 UTC (UTC+00:00)
Modified: Oct 24, 2025, 17:49 UTC (UTC+00:00)
Raw hash: 480a8b7f1e22efaa...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.1	Oct 24, 2025, 17:49 UTC (UTC+00:00)	Current bundle	`480a8b7f1e22…`

Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
ADSecurity Silver Tickets

Sean Metcalf. (2015, November 17). How Attackers Use Kerberos Silver Tickets to Exploit Systems. Retrieved February 27, 2020.
Open source URL
[2]
ADSecurity Detecting Forged Tickets

Metcalf, S. (2015, May 03). Detecting Forged Kerberos Ticket (Golden Ticket & Silver Ticket) Use in Active Directory. Retrieved December 23, 2015.
Open source URL
[3]
Medium Detecting Attempts to Steal Passwords from Memory

French, D. (2018, October 2). Detecting Attempts to Steal Passwords from Memory. Retrieved October 11, 2019.
Open source URL
[4]
mitre-attack T1558.002
Open source URL

Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams