What is Kerberoasting and why it matters for cybersecurity

Kerberoasting is a notable cybersecurity threat that exploits weaknesses in how enterprise authentication systems are used and managed. This technique has drawn attention because attackers can abuse legitimate processes to extract credentials without triggering obvious alerts.

Understanding the risks associated with Kerberoasting helps organizations strengthen their security posture and reduce the chance of unauthorized access to sensitive systems and data. This guide explores how the attack works, why it’s effective, and what teams can do to identify and reduce their exposure.

What is Kerberoasting?

Kerberoasting is a cybersecurity attack technique that targets service account credentials within Microsoft Active Directory (AD) environments. Let’s explain the basic terms first.

AD is a directory service widely used by organizations to manage users, computers, and permissions within a network. It provides a centralized way to control access to resources like files, applications, and services.

Kerberos is the authentication protocol that AD uses to securely verify the identities of users and services. It works by issuing “tickets” that grant access to various network services without requiring repeated password entry.

Kerberoasting exploits how Kerberos issues service tickets for service accounts in AD environments. While Kerberos itself is functioning as intended, attackers can abuse this process to obtain encrypted ticket data and attempt to crack service account passwords offline.

If a service account password is weak or reused, a successful attack may give an attacker access to additional systems or sensitive resources within the network. For this reason, Kerberoasting is considered a significant enterprise security risk, underscoring the importance of strong service account credentials and effective monitoring for suspicious authentication activity.

How Kerberoasting works

Kerberoasting involves obtaining Kerberos tickets and attempting to crack the encrypted portion offline to recover service account credentials. However, success is not guaranteed; long, random, well-managed service account passwords can make recovery impractical or infeasible. Here’s what the process typically looks like:

1. Identifying service accounts with service principal names (SPNs): Attackers look for service accounts linked to SPNs, which indicate services that can be issued Kerberos service tickets within an AD environment.
2. Requesting Kerberos service tickets: Using an existing authenticated domain account, attackers request ticket-granting service (TGS) tickets for one or more of these SPNs.
3. Collecting encrypted ticket material: The returned service ticket includes encrypted data that is protected using a key derived from the service account’s password. This step is central to Kerberoasting when weak or poorly managed passwords are in use.
4. Attempting offline password cracking: Attackers may attempt to brute-force the encrypted data offline, trying to recover the service account password. Because this happens outside the network, it avoids triggering account lockouts and may evade some traditional defenses, though unusual ticket activity can still be monitored.
5. Misusing recovered credentials: Once a password is recovered, attackers may authenticate as the service account and abuse its permissions, potentially enabling lateral movement or access to sensitive resources.

Why Kerberoasting is dangerous

Kerberoasting poses a significant threat because it targets weaknesses in how identity and authentication credentials are managed within a Windows domain.

Impact on Active Directory security

AD sits at the heart of identity and access management (IAM) in many organizations. A successful Kerberoasting attack can expose service account credentials used by Kerberos to secure access to services, particularly when those credentials are weak or poorly managed.

Because service accounts may have elevated privileges or access to critical systems, compromising one can allow attackers to impersonate that account and access sensitive resources. This can enable attackers to move beyond an initial foothold, supporting privilege escalation and lateral movement using legitimate credentials, which makes detection and containment more difficult.

Credential exposure and lateral movement risks

As mentioned above, the goal is to obtain reusable credentials that are accepted wherever the service account is legitimately authorized, such as application pools, scheduled tasks, or service-to-service authentication.

Once a service account password is recovered, attackers can blend into normal network traffic and move laterally using standard authentication and remote management mechanisms that rely on legitimate credentials. The extent of lateral movement depends on the permissions assigned to the compromised account, and broad service permissions or privilege creep significantly increase the attack radius.

Because these credentials appear legitimate, they can be reused until rotated or revoked, frequently for longer than organizations expect, given how infrequently service account passwords are changed.

What makes an environment vulnerable to Kerberoasting

Below, we break down the key conditions that increase risk and explain why they matter.

Where SPNs create Kerberoasting risk

SPNs are important because they allow authenticated domain users to request Kerberos service tickets encrypted with the service account’s password. This behavior is part of normal Kerberos operation, but it means encrypted ticket material may be exposed if service account passwords are weak or poorly managed.

The presence of an SPN itself is not inherently vulnerable. However, in larger or more mature environments, SPNs often reflect a growing number of service identities, each with its own credentials and permissions. This increases the risk of configuration drift, privilege creep, and inconsistent password management over time.

Kerberoasting risk also grows through lifecycle “leftovers.” Services get migrated, renamed, or decommissioned, but SPNs and their associated accounts are not always cleaned up promptly. These stale SPNs can remain active on enabled accounts with unclear ownership and outdated password practices.

From a defensive standpoint, such accounts are particularly risky because they may still receive service tickets, receive less monitoring, and rely on passwords that have not been rotated regularly.

Visibility gaps in authentication monitoring

Kerberoasting attacks are easier to miss when Kerberos activity is neither visible nor actionable. Even with solid identity hygiene, insufficient monitoring limits detection capabilities:

• Inadequate Kerberos logging: Without Kerberos auditing enabled, key service ticket activity is not recorded. Enabling relevant audit categories, such as event IDs 4768 for ticket-granting ticket (TGT) requests and 4769 for service ticket requests, is crucial for detection.
• Lack of anomaly detection: Kerberos logs generate high event volumes, and individual requests rarely appear suspicious. Effective detection depends on identifying unusual patterns, such as spikes in ticket requests, requests for uncommon services, or use of weaker or legacy encryption types. Without correlation and tuned alerts, Kerberoasting blends into routine traffic.
• Limited identity and behavior analytics: Since Kerberoasting abuses allowed protocols without requiring malware or malicious binaries, signature-based detection and perimeter defenses often miss these attacks because they rely on legitimate authentication behavior rather than malware or exploits.
• No visibility into SPN reconnaissance: Attackers often start by enumerating SPN-bearing accounts via directory queries. If this activity is not monitored or analyzed, early indicators of Kerberoasting risk may be missed.
• Overreliance on perimeter detection: Kerberoasting typically occurs post-compromise within the internal network. Because Kerberos requests to domain controllers are expected, perimeter-focused monitoring may fail to detect the activity until attackers use stolen credentials elsewhere.

Where Kerberoasting exposure builds up over time

Kerberoasting often exploits environments where service accounts are managed more like infrastructure components than as high-value identities. Common risk factors accumulate gradually, including:

• Weak or reused service account passwords: Credentials are sometimes copied across applications or environments for convenience. Password reuse means that cracking one password can unlock multiple services.
• Passwords that never expire and rarely rotate: To avoid service outages, service accounts are often configured with “password never expires,” leading to long-lived credentials and larger attack windows.
• Unnecessary or orphaned SPNs: Migrated, renamed, or decommissioned services sometimes leave behind SPNs and accounts that remain active but are poorly monitored.
• Overprivileged service accounts: Many service accounts have broader permissions than necessary (such as local admin rights, wide file-share access, or delegated directory permissions), which escalates the impact if compromised.
• Legacy or weaker Kerberos encryption types still allowed: Environments that continue to support older encryption protocols increase exposure, especially if modern defaults aren’t consistently enforced.
• Lack of managed service accounts: When service accounts are manually managed, password strength, rotation, and ownership depend heavily on process discipline. Using managed service accounts, where supported by the application and environment, helps reduce hygiene gaps that can scale across a domain.

How to detect Kerberoasting activity

Detecting Kerberoasting is less about spotting a single “bad” event and more about identifying suspicious patterns over time. Since the attack uses legitimate Kerberos authentication flows, signals often appear as unusual volume, unexpected targets, or the use of legacy encryption methods.

Common signs of Kerberoasting attempts

Kerberoasting can manifest as unusually high volumes of TGS requests, sometimes across many SPNs in a short period, or as smaller spikes focused on specific high-value services. If a low-privilege account suddenly requests multiple service tickets at a rate or to services it normally doesn’t access, this is a strong warning sign.

Requests for service tickets linked to high-value systems (like databases or core enterprise applications) that are out of character for the requesting account should also raise suspicion. Establishing baselines based on roles and normal activity is crucial to recognizing these anomalies.

Modern environments typically encrypt Kerberos service tickets using strong protocols like Advanced Encryption Standard (AES). However, if logs reveal tickets encrypted with older protocols, such as Rivest Cipher 4 (RC4), this can indicate either legacy configurations or attempts to obtain easier-to-crack tickets.

Kerberoasting activity itself appears as ticket requests, but related suspicious behavior may also be visible on endpoints (such as unusual scripting, credential dumping tools, or unexpected directory queries), which helps raise detection confidence.

A particularly effective detection method is creating a decoy service account with an SPN that isn’t used by any legitimate service. Any ticket requests for this SPN should be treated as highly suspicious and worth immediate investigation, since legitimate systems shouldn’t be using it.

What to monitor in Kerberos authentication logs

Kerberoasting detection is pattern-driven. It relies on seeing abnormal Kerberos service ticket behavior, not on identifying a single “malicious” request. MITRE’s Kerberoasting detection guidance emphasizes monitoring for anomalous TGS activity, including unusual ticket request volume, unusual targeting, and encryption red flags.

• Request volume and timing: Tracking the number of 4769 events per account within specific time windows and flag spikes or outliers compared to the baseline.
• Encryption types: Monitoring for service tickets encrypted with legacy or weaker algorithms.
• Target analysis: Identifying service tickets requested for SPNs that don’t align with the account’s typical access patterns, particularly those associated with sensitive systems.

Kerberoasting in real intrusions

Kerberoasting can seem theoretical until it appears in intrusion reports. Real-world cases demonstrate when Kerberoasting occurs, what attackers aim to achieve, and which security gaps enable it. Notable examples include:

• BlackSuit ransomware (reported in 2024): DFIR Report documented Kerberoasting observed during a BlackSuit intrusion as part of broader credential access activity.
• APT40 (advisory published in 2024): The Australian Signals Directorate’s Cyber Security Centre (ASD’s ACSC), along with the other authoring agencies, reported post-compromise activity involving service ticket requests tied to SPN accounts.
• Akira ransomware (updated 2025): The FBI/Cybersecurity and Infrastructure Security Agency (CISA)/partners advisory notes that Akira actors have been observed using post-exploitation techniques, including Kerberoasting.
• VICE SPIDER (reported in 2023): CrowdStrike’s Threat-Hunting Report highlighted a major rise in Kerberoasting activity and identified VICE SPIDER as a frequent associated actor in their reporting period.

How to protect against Kerberoasting

Effective mitigation of Kerberoasting starts with using strong, complex, unique passwords for accounts with an SPN, because Kerberoasting relies on offline password-guessing against service ticket encryption. While ticket requests themselves are part of normal Kerberos behavior, strong credentials make successful cracking far less likely, and rotation, where feasible, reduces the window of exposure.

Group Managed Service Accounts (gMSAs), which support automatically managed long, random passwords, help minimize risks associated with manual password management.

Service accounts often have extended password lifecycles or “password never expires” settings, which increase the window for attackers to harvest and crack Kerberos tickets. When frequent password rotation is not feasible, organizations typically rely on compensating controls such as very strong unique passwords, documented exceptions/ownership, tight privilege scoping, and monitoring.

Limiting service account permissions and disabling interactive sign-in help contain the impact of compromised credentials. While least privilege cannot prevent ticket harvesting itself, it reduces the risk that a cracked password grants widespread administrative access.

Over time, environments can accumulate stale service accounts and SPNs, creating unnecessary targets. Regular inventory and audit processes identify unused or orphaned accounts, validate SPN necessity, and assess password age and account privileges. Maintaining dedicated, compartmentalized service identities and avoiding dual-use admin accounts reduces the impact if credentials are compromised.

Additionally, adopting zero-trust principles, where internal credentials are not automatically trusted, and layering stronger authentication measures such as multi-factor authentication (MFA) for interactive and privileged access paths can further limit credential misuse after an initial compromise.

Incident response steps if Kerberoasting is suspected

Kerberoasting typically indicates an attacker already has authenticated domain access (a foothold), which can signal a broader intrusion. Typical response steps include:

• Containing the foothold: Use domain controller ticket activity to identify the requesting account and likely source host, then disable or restrict the account and isolate the machine to stop further ticket requests.
• Rotating the password and recovering: Map requested SPNs to their owning service accounts, rotate those passwords quickly (since offline cracking can continue after ticket collection), and coordinate changes to avoid breaking critical services.
• Scoping the intrusion: Determine how the initial account was compromised and review recent authentication and endpoint activity around the suspected foothold.
• Hardening the environment: Remove or disable stale service accounts and SPNs; enforce strong, regularly rotated passwords for SPN-bearing accounts; reduce service account privileges; and strengthen monitoring for ticket anomalies and legacy encryption.
• Documenting and escalating: Follow internal/regulatory notification needs and record the timeline, impacted accounts/SPNs, actions taken, and lessons learned for future detection and response.

Kerberoasting vs. other credential attacks

Kerberoasting is one of several AD credential-access techniques. It’s helpful to compare Kerberoasting with other common credential-based attacks to understand its distinctiveness and its place in the threat landscape.

Kerberoasting vs. NTLM-based attacks

New Technology LAN Manager (NTLM) is a legacy Microsoft authentication protocol still found in many Windows environments, often due to legacy applications or fallback configurations. NTLM-based attacks often involve reusing stolen NTLM password hashes (pass-the-hash) or relaying NTLM authentication exchanges (NTLM relay) to authenticate without recovering the user’s plaintext password.

Detection focuses on identifying unusual NTLM authentication patterns or lateral movement associated with hash reuse or relay activity.

The outcome for attackers differs as well: successful Kerberoasting may recover a service account’s plaintext password, which can then be reused where that account is authorized, whereas many NTLM attacks authenticate via hash/relay without needing plaintext.

Kerberoasting vs. password spraying

Password spraying is typically an online guessing attack where a small set of common passwords is tried across many accounts, often spaced out to avoid triggering account lockouts. In contrast, Kerberoasting is a post-compromise technique: once attackers have a foothold, they request service tickets and crack them offline, without triggering account lockouts.

Password spraying is a breadth-first approach that targets many regular accounts to find any that accept common passwords. Kerberoasting is a depth-first method that focuses on service accounts with SPNs, as cracking a single service account credential may provide broad access to systems and data associated with that service.

From a detection standpoint, password spraying typically appears as an increase in failed login attempts across multiple accounts. Kerberoasting is detected through abnormal patterns in Kerberos ticket requests and encryption signals.