T1558: Steal or Forge Kerberos Tickets

Kerberos tickets are a core trust mechanism in many enterprise authentication environments. If an adversary can steal or forge them, they may be able to reuse authentication material for Pass the Ticket-style access without needing a user’s plaintext password. For business leaders, this makes Kerberos abuse a high-value identity security concern: it can affect domain trust, privileged access, lateral movement readiness, and confidence in audit evidence around who accessed what.

Executive priority

Prioritize this as an identity and Active Directory resilience issue, not just a malware detection problem. Leaders should ask whether Kerberos-reliant environments have strong AD configuration, privileged account controls, password policy enforcement, credential access protections, and usable audit trails. The ATT&CK relationships also show sub-techniques across Golden Ticket, Silver Ticket, Kerberoasting, AS-REP Roasting, and Linux/macOS ccache file theft, so coverage should be assessed across both Windows domain infrastructure and non-Windows Kerberos credential cache use where present.

Technical view

SOC and IR teams should validate Kerberos visibility rather than assume endpoint alerts will be enough. ATT&CK provides no official detection text for T1558, but it links to a detection strategy, DET0522, for Kerberos ticket theft or forgery. Defenders should evaluate authentication and ticket activity around domain controllers/KDCs, service accounts, privileged accounts, and endpoints where tickets may be cached. On Windows, the built-in klist utility can list and analyze cached Kerberos tickets, which may be relevant during response and validation. For Linux and macOS, the related ccache sub-technique highlights the need to understand krb5 configuration and credential cache locations.

Likely telemetry

Kerberos authentication and ticket-granting activity from domain controllers/KDCs
Windows security logs and AD audit events related to account logon, ticket requests, and service ticket use
Privileged account and service account activity, especially accounts tied to SPNs
Endpoint process and command telemetry where Kerberos ticket utilities or credential access behavior may appear
Cached Kerberos ticket evidence on Windows systems, including artifacts assessable with klist during investigation

Detection direction

Start with coverage validation for DET0522: confirm what data sources are collected, retained, normalized, and alertable for Kerberos ticket theft or forgery scenarios.
Tune detections around abnormal Kerberos ticket behavior in context of the sub-techniques: forged TGTs, forged service tickets, Kerberoasting, AS-REP Roasting, and ccache theft.
Use service-account baselines carefully; high-volume service ticket activity can be legitimate, so false-positive handling should consider known SPNs, administrative workflows, and expected application behavior.
Validate that monitoring includes domain controllers and identity infrastructure, not only workstations and servers.
For Linux and macOS Kerberos use, confirm whether credential cache paths and environment-variable-driven locations are visible to endpoint monitoring; this is a common blind spot when teams focus only on Windows AD logs.

Mitigation priorities

Harden Active Directory configuration first, using centralized policy to reduce unauthorized access and lateral movement risk.
Apply privileged account management: restrict administrative scope, enforce least privilege/RBAC, and monitor privileged account use.
Strengthen password policies, especially for accounts whose credentials or service tickets could enable Kerberos abuse.
Implement credential access protection to reduce exposure of passwords, hashes, tokens, keys, and cached authentication material.
Encrypt sensitive information at rest, in transit, and during processing where relevant to credential and ticket protection.

Analyst notes and limits

This is a parent ATT&CK technique for Kerberos ticket theft or forgery under Credential Access across Linux, macOS, and Windows. The most actionable risk analysis comes from its sub-techniques: Golden Ticket, Silver Ticket, Kerberoasting, AS-REP Roasting, and Ccache Files. ATT&CK relationships also associate this technique with Akira and the 2025 Poland Wiper Attacks, but local relevance depends on whether the environment uses Kerberos, Active Directory, service accounts, or non-Windows Kerberos credential caches.

The supplied ATT&CK object does not include official detection guidance for T1558, so detection recommendations are framed as validation directions based on the description, external references, and related detection/mitigation objects. This take does not assert existing detection coverage, active exploitation in any specific environment, or guaranteed prevention. Local architecture, logging depth, ticket lifetimes, account configuration, and Kerberos deployment details are required for a defensible assessment.

Official MITRE ATT&CK definition

Steal or Forge Kerberos Tickets

Adversaries may attempt to subvert Kerberos authentication by stealing or forging Kerberos tickets to enable Pass the Ticket. Kerberos is an authentication protocol widely used in modern Windows domain environments. In Kerberos environments, referred to as “realms”, there are three basic participants: client, service, and Key Distribution Center (KDC).[1] Clients request access to a service and through the exchange of Kerberos tickets, originating from KDC, they are granted access after having successfully authenticated. The KDC is responsible for both authentication and ticket granting. Adversaries may attempt to abuse Kerberos by stealing tickets or forging tickets to enable unauthorized access.

On Windows, the built-in klist utility can be used to list and analyze cached Kerberos tickets.[2]

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 5 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1558.003	Kerberoasting Sub-technique	Kerberoasting subtechnique of this object.
Enterprise	T1558.002	Silver Ticket Sub-technique	Silver Ticket subtechnique of this object.
Enterprise	T1558.005	Ccache Files Sub-technique	Ccache Files subtechnique of this object.
Enterprise	T1558.004	AS-REP Roasting Sub-technique	AS-REP Roasting subtechnique of this object.
Enterprise	T1558.001	Golden Ticket Sub-technique	Golden Ticket subtechnique of this object.

Associated objects

Groups, software, and campaigns

G1024: Akira

Akira is a ransomware variant and ransomware deployment entity active since at least March 2023.[1] Akira uses compromised credentials to access single-factor external access mechanisms such as VPNs for initial access, then various publicly-available tools and techniques for lateral movement.[1][2] Akira operations are associated with "double extortion" ransomware activity, where data is exfiltrated from victim environments prior to encryption, with threats to publish files if a ransom is not paid. Technical analysis of Akira ransomware indicates variants capable of targeting Windows or VMWare ESXi hypervisors and multiple overlaps with Conti ransomware.[3][4][5]

C0063: 2025 Poland Wiper Attacks

2025 Poland Wiper Attacks is a Russian state-sponsored campaign that conducted destructive cyberattacks against Polish energy infrastructure in December 2025. Targets included more than 30 wind and photovoltaic farms, a combined heat and power (CHP) plant, and a manufacturing sector company. The attacks on the distributed energy resources (DER) disrupted communications between affected facilities and the distribution system operator, but did not impact electricity generation or heat supply. Across the campaign, threat actors deployed two previously undocumented wiper tools, DynoWiper, a Windows-based wiper and LazyWiper, a PowerShell wiper, distributed via malicious Group Policy Objects. At the CHP plant, threat actors had maintained access since at least March 2025, using that foothold to obtain credentials and move laterally before attempting wiper deployment. Some reporting has assessed the activity to be consistent with Russian Federal Security Service (FSB) threat activity group Dragonfly, also tracked as STATIC TUNDRA, while other reporting attributes the destructive wiper activities to the Russian General Staff Main Intelligence Directorate (GRU) threat activity group ELECTRUM, also tracked as Sandworm Team.[1][2][3][4]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1015: Active Directory Configuration Enterprise mitigates · Mitigation M1043: Credential Access Protection Enterprise uses · Campaign C0063: 2025 Poland Wiper Attacks Enterprise mitigates · Mitigation M1041: Encrypt Sensitive Information Enterprise uses · Group G1024: Akira Enterprise subtechnique of · Technique T1558.003: Kerberoasting Enterprise mitigates · Mitigation M1027: Password Policies Enterprise detects · Detection Strategy DET0522: Detect Kerberos Ticket Theft or Forgery (T1558) Enterprise subtechnique of · Technique T1558.002: Silver Ticket Enterprise subtechnique of · Technique T1558.005: Ccache Files Enterprise mitigates · Mitigation M1047: Audit Enterprise subtechnique of · Technique T1558.004: AS-REP Roasting Enterprise subtechnique of · Technique T1558.001: Golden Ticket Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise

Mitigations

Mitigation direction

M1015: Active Directory Configuration

Implement robust Active Directory (AD) configurations using group policies to secure user accounts, control access, and minimize the attack surface. AD configurations enable centralized control over account settings, logon policies, and permissions, reducing the risk of unauthorized access and lateral movement within the network. This mitigation can be implemented through the following measures:

Account Configuration:

- Implementation: Use domain accounts instead of local accounts to leverage AD’s centralized management, including group policies, auditing, and access control. - Use Case: For IT staff managing shared resources, provision domain accounts that allow IT teams to log in centrally, reducing the risk of unmanaged, rogue local accounts on individual machines.

Interactive Logon Restrictions:

- Implementation: Configure group policies to restrict interactive logons (e.g., direct physical or RDP logons) for service accounts or privileged accounts that do not require such access. - Use Case: Prevent service accounts, such as SQL Server accounts, from having interactive logon privileges. This reduces the risk of these accounts being leveraged for lateral movement if compromised.

Remote Desktop Settings:

- Implementation: Limit Remote Desktop Protocol (RDP) access to specific, authorized accounts. Use group policies to enforce this, allowing only necessary users to establish RDP sessions. - Use Case: On sensitive servers (e.g., domain controllers or financial databases), restrict RDP access to administrative accounts only, while all other users are denied access.

Dedicated Administrative Accounts:

- Implementation: Create domain-wide administrative accounts that are restricted from interactive logons, designed solely for high-level tasks (e.g., software installation, patching). - Use Case: Create separate administrative accounts for different purposes, such as one set of accounts for installations and another for managing repository access. This limits exposure and helps reduce attack vectors.

Authentication Silos:

- Implementation: Configure Authentication Silos in AD, using group policies to create access zones with restrictions based on membership, such as the Protected Users security group. This restricts access to critical accounts and minimizes exposure to potential threats. - Use Case: Place high-risk or high-value accounts, such as executive or administrative accounts, in an Authentication Silo with extra controls, limiting their exposure to only necessary systems. This reduces the risk of credential misuse or abuse if these accounts are compromised.

**Tools for Implementation**:

- Active Directory Group Policies: Use Group Policy Management Console (GPMC) to configure, deploy, and enforce policies across AD environments. - PowerShell: Automate account configuration, logon restrictions, and policy application using PowerShell scripts. - AD Administrative Center: Manage Authentication Silos and configure high-level policies for critical user groups within AD.

M1043: Credential Access Protection

Credential Access Protection focuses on implementing measures to prevent adversaries from obtaining credentials, such as passwords, hashes, tokens, or keys, that could be used for unauthorized access. This involves restricting access to credential storage mechanisms, hardening configurations to block credential dumping methods, and using monitoring tools to detect suspicious credential-related activity. This mitigation can be implemented through the following measures:

Restrict Access to Credential Storage:

- Use Case: Prevent adversaries from accessing the SAM (Security Account Manager) database on Windows systems. - Implementation: Enforce least privilege principles and restrict administrative access to credential stores such as `C:\Windows\System32\config\SAM`.

Use Credential Guard:

- Use Case: Isolate LSASS (Local Security Authority Subsystem Service) memory to prevent credential dumping. - Implementation: Enable Windows Defender Credential Guard on enterprise endpoints to isolate secrets and protect them from unauthorized access.

Monitor for Credential Dumping Tools:

- Use Case: Detect and block known tools like Mimikatz or Windows Credential Editor. - Implementation: Flag suspicious process behavior related to credential dumping.

Disable Cached Credentials:

- Use Case: Prevent adversaries from exploiting cached credentials on endpoints. - Implementation: Configure group policy to reduce or eliminate the use of cached credentials (e.g., set Interactive logon: Number of previous logons to cache to 0).

Enable Secure Boot and Memory Protections:

- Use Case: Prevent memory-based attacks used to extract credentials. - Implementation: Configure Secure Boot and enforce hardware-based security features like DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization).

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.

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.

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

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.

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.7
Created: Feb 11, 2020, 19:12 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 5e71a76e70e62f38...

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.7	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`5e71a76e70e6…`

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 Kerberos Ring Decoder

Sean Metcalf. (2014, September 12). Kerberos, Active Directory’s Secret Decoder Ring. Retrieved February 27, 2020.
Open source URL
[2]
Microsoft Klist

Microsoft. (2021, March 3). klist. Retrieved October 14, 2021.
Open source URL
[3]
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
[4]
AdSecurity Cracking Kerberos Dec 2015

Metcalf, S. (2015, December 31). Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain. Retrieved March 22, 2018.
Open source URL
[5]
CERT-EU Golden Ticket Protection

Abolins, D., Boldea, C., Socha, K., Soria-Machado, M. (2016, April 26). Kerberos Golden Ticket Protection. Retrieved July 13, 2017.
Open source URL
[6]
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
[7]
Microsoft Detecting Kerberoasting Feb 2018

Bani, M. (2018, February 23). Detecting Kerberoasting activity using Azure Security Center. Retrieved March 23, 2018.
Open source URL
[8]
Microsoft Kerberos Golden Ticket

Microsoft. (2015, March 24). Kerberos Golden Ticket Check (Updated). Retrieved February 27, 2020.
Open source URL
[9]
Stealthbits Detect PtT 2019

Jeff Warren. (2019, February 19). How to Detect Pass-the-Ticket Attacks. Retrieved February 27, 2020.
Open source URL
[10]
mitre-attack T1558
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