Kerberoasting is an Active Directory attack technique in which an attacker requests Kerberos service tickets for accounts associated with Service Principal Names (SPNs) and attempts to crack the tickets' encrypted portions offline to recover the associated service account passwords.
Primary risk: Offline password cracking against Kerberos service-ticket material.
Common targets: Active Directory service accounts associated with SPNs.
Potential impact: Service account compromise, privilege escalation and lateral movement.
Key investigation evidence: Kerberos Event ID 4769, SPN enumeration, service account activity and endpoint telemetry.
Primary defences: Strong service account credentials, group Managed Service Accounts (gMSAs), least privilege and Kerberos monitoring.
Imagine an organisation running an internal SQL Server, a web application and several scheduled background services. Each service uses a dedicated Active Directory account to authenticate and access the resources it needs.
These accounts often operate without direct user interaction. Some may run continuously, access sensitive databases or have permissions across multiple systems.
An attacker who gains access to an ordinary domain account may discover that they can request Kerberos service tickets for accounts associated with registered services.
The attacker does not necessarily need to compromise the service itself. Instead, they can collect relevant ticket material and attempt to recover the associated password offline.
This technique is known as Kerberoasting.
The central security issue is that service tickets can provide material for offline password guessing. If the associated service account uses a weak or predictable password, an attacker may recover it and potentially gain access to the services and resources available to that account.
Importantly, requesting a service ticket is a normal part of Kerberos authentication. Detecting Kerberoasting therefore requires more than simply identifying a successful ticket request.
Kerberos is an authentication protocol widely used in Windows Active Directory environments. It allows users and services to authenticate without repeatedly transmitting their passwords.
Three components are particularly relevant to Kerberoasting.
An SPN uniquely identifies a service instance within an Active Directory environment for Kerberos service authentication.
SPNs are associated with the accounts under which services run. These may be ordinary domain user accounts, computer accounts or other supported service identities.
Examples of services that may use SPNs include SQL Server, web applications and other network services.
After successful initial Kerberos authentication, a client can use its TGT to request service tickets from the Key Distribution Center (KDC), which operates on domain controllers in a typical Active Directory environment.
A TGS ticket, commonly called a service ticket, is issued for a particular service. Its encrypted components are associated with the service account's long-term key.
Kerberoasting targets suitable service-ticket material because an attacker can attempt password guesses offline and compare the resulting cryptographic output with the captured ticket material.
Offline cracking does not require the attacker to submit each password guess to the domain controller. Consequently, traditional failed-login monitoring may not reveal the guessing process itself.
The feasibility of recovering a password depends on factors such as password strength, ticket encryption type and the attacker's available computing resources.
Key distinction: A service-ticket request does not mean a password has been cracked. Password recovery is a separate step that may or may not succeed.
An attacker obtains access to an Active Directory account through phishing, credential theft, exploitation or another method.
Kerberoasting can be possible with ordinary domain user access, depending on the environment.
The attacker identifies accounts associated with SPNs. These accounts may run database services, web applications, scheduled jobs or other network services.
The objective is to identify accounts for which Kerberos service tickets can be requested.
The attacker requests service tickets for selected SPNs.
The domain controller processes these requests as part of normal Kerberos functionality. A request is not inherently malicious because legitimate applications routinely request service tickets.
The attacker collects suitable service-ticket material for offline analysis.
The value of that material depends on the account's password strength and the cryptographic properties of the ticket.
The attacker attempts password guesses against the collected ticket material without repeatedly authenticating to the domain.
If the password is weak or predictable, the attacker may recover it. Strong, randomly generated credentials can make this process substantially more difficult.
If the password is recovered, the attacker may attempt to authenticate as the service account or use the recovered credentials in other compatible authentication paths.
The impact depends on the account's privileges, where the credentials are valid and which resources the account can access.
A compromised service account may provide access to sensitive systems or resources. If the account has excessive privileges, the consequences can extend beyond the service it was originally created to support.
These outcomes are not automatic. They require successful credential recovery and an applicable path to further access.
Service accounts are often designed for reliability and continuous operation. Unfortunately, older account-management practices can leave them exposed.
Passwords based on service names, company names, seasons or predictable patterns may be easier to recover through offline guessing.
Long-lived passwords can increase risk when they are not rotated after exposure or are reused across systems.
A service account may have been granted local administrator rights, broad database permissions or access to multiple servers simply to make an application work.
If the account is compromised, those privileges may provide an attacker with a wider path through the environment.
Some organisations create ordinary domain user accounts for services and retain static passwords for years.
These accounts can become difficult to manage when multiple applications depend on the same credentials.
If a service account's password is reused in another context, a successful recovery may have consequences beyond the original service.
Credential reuse should therefore be investigated as a separate exposure risk.
Service accounts may not generate the same interactive login patterns as human users. Their legitimate activity can be difficult to distinguish from malicious use without an established baseline.
Consider a hypothetical alert: a domain controller records a burst of service-ticket requests associated with several SPNs. The requesting account rarely accesses some of these services, and the activity occurs shortly after a suspicious endpoint alert.
The SOC analyst must determine whether the requests reflect normal application behaviour, service discovery or a Kerberoasting attempt.
Event ID 4769 — A Kerberos service ticket was requested is one of the most relevant Windows Security events for investigating Kerberoasting.
Review available fields, including:
Requesting account.
Requested service or service account.
Client address.
Ticket encryption type.
Status or failure information.
Timestamp.
Other ticket-related fields available in the event schema.
Investigate whether a single account requests tickets for an unusual number of distinct services or accesses SPNs outside its normal activity pattern.
A burst of Event ID 4769 records is not proof of Kerberoasting. Applications, users and automated services can legitimately request many service tickets.
Compare the activity with normal authentication behaviour for the requesting account, workstation and environment.
Questions to consider:
Does this account normally request tickets for these services?
Is the source workstation expected to perform service discovery or administration?
Did the requests occur during a deployment or maintenance window?
Are the requested services consistent with the account's business function?
Is there an unusual change in the number or variety of SPNs requested?
The baseline should reflect actual organisational activity rather than a universal threshold.
Kerberos ticket encryption information can provide useful context.
Historically, Kerberoasting has often been associated with service tickets encrypted using RC4-HMAC, which uses the account's NT-derived key. However, AES-encrypted tickets can also be targeted by offline password guessing.
A ticket encrypted with RC4 is not automatically evidence of an attack. Legacy compatibility requirements may explain its presence.
Likewise, an AES ticket does not prove that an account is protected against Kerberoasting. Password strength remains an important factor.
Use encryption type as one part of the investigation, not as a standalone verdict.
For the accounts associated with the requested SPNs, review:
Password-management method.
Password age and rotation history.
Privileged group membership.
Local administrator access.
Database and application permissions.
SPN registrations.
Whether the account is still required.
Whether the service uses a managed service account.
Prioritise accounts with excessive privileges, weak credential-management practices or access to sensitive systems.
Review EDR alerts and process telemetry from the requesting endpoint.
Look for suspicious directory discovery, unexpected administrative tooling, credential-access activity or other signs of Active Directory reconnaissance.
The use of a legitimate administrative tool does not by itself prove malicious activity. Consider the user's role, the tool's execution context and the surrounding events.
Offline cracking may not generate corresponding failed authentication events because password guesses occur outside the domain controller.
Instead, look for subsequent activity that could indicate the service account was compromised:
New authentication from an unusual endpoint.
Unexpected interactive or remote logons.
Access to resources outside the service's normal scope.
Changes to account permissions or group membership.
Unusual service activity.
Remote administration or lateral movement.
Correlate these events with the ticket-request timeline and the account's normal behaviour.
Classify findings according to the evidence:
Unusual Kerberos activity: Ticket requests differ from the established baseline.
Suspected Kerberoasting: The request pattern and context suggest systematic collection of service tickets for offline cracking.
Confirmed credential exposure: Evidence establishes that the service account password was recovered or otherwise compromised.
Confirmed service account abuse: The compromised account was used for unauthorised access or activity.
A burst of service-ticket requests alone does not prove that a password was cracked.
Kerberoasting has no single definitive indicator of compromise. Detection depends on authentication telemetry, account configuration and subsequent activity.
Evidence sourceWhat to investigateWindows Security Event 4769Service-ticket requests, requesting accounts, SPNs and encryption typesWindows Security Event 4768TGT requests and the broader authentication timelineActive Directory inventorySPN registrations, account types and account privilegesEDR telemetrySuspicious enumeration, tooling and credential-access activityIdentity logsUnusual authentication and access patterns for service accountsDatabase and application logsUnexpected use of service identitiesWindows Security Event 4624Successful logons associated with a potentially compromised accountWindows Security Event 4672Special privileges assigned to a logon, where applicableChange and audit recordsUnexpected account changes, privilege changes or SPN modificationsOne account requests tickets for many unrelated SPNs in a short period.
A workstation requests service tickets for services it does not normally use.
Service-ticket requests coincide with suspicious Active Directory discovery.
RC4-encrypted service tickets appear in a context inconsistent with normal activity.
A service account begins authenticating from an unusual system after suspicious ticket requests.
A potentially exposed account accesses resources beyond its established operational scope.
These patterns are investigation leads rather than proof of compromise. Legitimate software can generate bursts of ticket requests, and RC4 may remain in use for compatibility.
An effective detection strategy combines service-ticket telemetry with account context and subsequent authentication activity.
Monitor Event ID 4769 from domain controllers.
Group requests by requesting account, source host, destination SPN and time window.
Identify unusual numbers of distinct service accounts or SPNs requested by a single identity.
Enrich the activity with ticket encryption type, account privilege and normal usage patterns.
Correlate the events with endpoint discovery alerts and subsequent service account authentication.
Prioritise activity involving privileged service accounts or sensitive systems.
Avoid relying exclusively on a fixed ticket-request threshold or RC4 usage. A robust detection should account for application behaviour, account role and the environment's normal Kerberos activity.
T1558.003 — Kerberoasting: The specific technique involving Kerberos service tickets and offline password cracking.
T1087.002 — Domain Account Discovery: Relevant when evidence shows discovery of domain accounts.
T1003 — OS Credential Dumping: Relevant only if evidence indicates credential material was extracted from an operating system.
T1078 — Valid Accounts: Potentially relevant if recovered service account credentials are subsequently used for unauthorised access.
Do not assign every technique to every Kerberoasting alert. Map the behaviours established by the investigation.
The strongest defences reduce the likelihood of password recovery and limit the impact of a compromised service account.
Where supported, use group Managed Service Accounts (gMSAs) for appropriate Windows services.
gMSAs support automated password management and can reduce the need for manually maintained service account passwords. Access and deployment must still be configured correctly.
For service accounts that require manually managed passwords, use long, unique, randomly generated credentials.
Avoid predictable patterns, service names and passwords reused across accounts.
Give service accounts only the permissions required for their specific functions.
Review domain group membership, local administrator rights, database permissions and access to sensitive servers.
Audit SPNs to identify unnecessary, duplicate or stale registrations and determine which accounts actually need to run services.
Remove obsolete service accounts and SPNs through controlled change procedures.
Review Kerberos encryption configuration and reduce legacy encryption dependencies where operationally feasible.
Moving away from RC4 can improve the cryptographic posture, but it does not eliminate Kerberoasting. Strong account passwords and appropriate service account management remain essential.
Establish baselines for service account authentication, expected source systems and normal destination services.
Investigate new interactive logons, unusual remote access and changes in account behaviour.
Avoid using highly privileged domain accounts to run ordinary applications. Separate service identities from administrative identities and restrict where privileged accounts can authenticate.
Prepare procedures for investigating suspicious service-ticket requests, assessing potential password exposure and rotating affected credentials without unnecessarily disrupting production services.
When Kerberoasting is suspected:
Preserve evidence: Collect Event ID 4769 records, endpoint telemetry and relevant Active Directory information.
Identify the requesting identity: Establish the source account, workstation and requested SPNs.
Assess the target accounts: Review password management, privileges and service dependencies.
Investigate follow-on activity: Look for unusual service account logons, resource access or privilege changes.
Contain confirmed exposure: Restrict affected accounts or services where warranted.
Rotate credentials safely: Coordinate password changes with service owners and validate application dependencies.
Reduce future risk: Move suitable workloads to managed service accounts, strengthen passwords and remove excessive privileges.
Validate recovery: Confirm that affected services operate correctly and monitor for further suspicious authentication.
Kerberoasting demonstrates how normal Kerberos functionality can be abused to target service account passwords. By requesting suitable service tickets and attempting offline password cracking, an attacker may recover weak credentials without generating the repeated failed logons associated with online password guessing.
For SOC analysts, the priority is to identify unusual service-ticket request patterns, understand the accounts involved and investigate subsequent authentication activity. For defenders, the most effective measures include managed service accounts, strong random credentials, least privilege and appropriate Kerberos monitoring.
The key lesson: Service accounts deserve the same level of identity security as privileged human accounts because their credentials can provide access to critical systems.
MITRE ATT&CK — T1558.003: Kerberoasting
Microsoft Learn — Kerberos authentication overview
Microsoft Learn — Windows Security auditing and Event ID 4769
Microsoft Learn — Group Managed Service Accounts overview
Microsoft Learn — Kerberos encryption and Active Directory security guidance
Continue reading
Identity & Credential Attacks
NTLM relay attacks exploit weaknesses in authentication workflows by forwarding a legitimate user's NTLM authentication exchange to another service. Rather than cracking a password...
Identity & Credential Attacks
AS-REP Roasting is an Active Directory attack technique that targets user accounts configured not to require Kerberos pre-authentication. An attacker can request authentication dat...
Identity & Credential Attacks
Pass-the-Ticket (PtT) is a credential abuse technique in which an attacker steals and reuses Kerberos tickets to authenticate to network resources without necessarily knowing the a...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
