Critical Kerberoasting (Active Directory service-account credential theft)
At a glance
- Class
- Kerberoasting, catalogued by MITRE ATT&CK as Steal or Forge Kerberos Tickets (T1558.003): offline cracking of the Kerberos service ticket returned in a TGS-REP
- Severity
- Critical where a privileged account's password is recovered and the privilege path is verified. High where a recovered password grants broad rights short of the directory, or where a privileged kerberoastable account with RC4 and a human-set password exists but no crack completes inside the test window. Medium for kerberoastable accounts without privilege, and for service principal name hygiene.
- Reference
- CWE-521 weak password requirements; CWE-916 use of password hash with insufficient computational effort; CWE-250 execution with unnecessary privileges; MITRE ATT&CK T1558.003
- Reachable from
- Any host that can reach a domain controller on the Kerberos and LDAP ports, domain-joined or not, on any operating system, holding one set of domain credentials, a stolen NT hash or a valid Kerberos ticket. A clock inside the five minute skew is the only other environmental requirement.
- Privilege required
- One ordinary domain account, the kind a phishing reply or a reused password yields
- Affects
- Active Directory domains in which a user-class account carries a service principal name and that account's password is set by a person. Domains whose service principal names sit only on computer accounts, group managed service accounts or delegated managed service accounts are not exposed by this path, although write access over a privileged user object can create one.
- Why it is missed
- Ticket requests resemble normal service authentication and the cracking runs offline, so nothing fails and nothing locks out
What it is
Kerberoasting is an Active Directory attack in which any authenticated domain user requests Kerberos service tickets for accounts that run services, takes those tickets off the network, and cracks the service account's password offline. It works because the domain controller's key distribution centre, the KDC, issues a service ticket to any valid domain account without checking whether that account is entitled to use the service, and because the encrypted portion of every ticket is protected with a key tied to the service account's password. Nothing is exploited in the usual sense: the attack uses Kerberos as designed, which is why patching and endpoint detection do not address it. The weakness is that the password is chosen by a person, often set once and never changed, and that the account it protects typically holds more rights across the domain than its application needs. Only user-class accounts carrying a service principal name are candidates, since a name sitting on a computer account, a group managed service account or krbtgt is protected by a long machine-generated password that offline cracking will not recover.
The commercial problem is the gap between how ordinary the attack looks and how far it reaches. Service accounts get created for SQL Server instances, IIS application pools, backup agents, monitoring collectors, manufacturing execution systems and scheduled tasks, and the quickest way to make such an application work is to place its account in Domain Admins or grant it rights on every server, which is how those memberships arise. In a manufacturing setting the same credential then opens engineering file shares, the backup infrastructure and the jump hosts that reach the plant floor, which is the sequence ransomware operators follow once they are inside a network. Internal network penetration testing therefore treats a kerberoastable privileged account as a priority finding rather than a configuration note. A red team assessment answers the companion question, which is whether anyone notices the ticket requests before the credentials are used.
How the attack unfolds
Mechanism, not a recipe. Reproduction detail stays in client reports, because a page that hands a reader a working attack is a liability.
An ordinary domain account is enough to begin
Kerberoasting needs no administrative privilege and no software vulnerability, only a valid domain account and network reachability to a domain controller. That account can come from a phishing reply, a credential reused from a breached third-party service, a shared login written into a maintenance procedure, or an unattended domain-joined workstation on the shop floor. The attacking host does not have to be domain-joined or running Windows, so a contractor laptop, a Linux build server or a published remote session serves equally well.
From there the attacker is an authenticated user asking the directory ordinary questions.
Any authenticated user can list every service principal name in the domain
An account that runs a service carries a service principal name, and in a default Active Directory any authenticated user can read that attribute. One directory query returns the accounts, the hosts they serve, their group memberships and how long ago each password was set, which is what an attacker needs to pick the account worth attacking. The filter that matters is the object class: only user-class accounts are worth roasting, because computer accounts, group managed service accounts and krbtgt hold machine-generated keys that no cracking rig will recover.
Accounts belonging to backup software, database engines and production systems tend to sit at the top of the shortlist, because broad rights are what make them work in the first place. Group membership read from the account itself is only the first pass, since nested groups, the primary group and foreign security principals carry rights that a direct listing does not show.
The KDC hands over a crackable ticket on request
When a user asks for access to a service, the KDC returns a reply containing a service ticket whose encrypted portion is protected with the service account's long-term key: the NT hash itself where RC4 is in play, or an AES key derived from the password with a realm and username salt. That portion is what the attacker takes away, and the remainder of the reply is encrypted under the requester's own key and is of no use to them. The controller does not verify that the requester is permitted to use the service, because that enforcement is designed to happen at the service itself, which the attacker never contacts.
Cracking runs offline, so no password is ever tested against the domain
The encrypted portion of each ticket is attacked on the attacker's own GPU hardware, against wordlists and rule sets built from the organisation's naming habits. Because no authentication attempt is made against the domain, there are no failed logon events, no account lockouts and no password spray pattern in the authentication telemetry. The collection step before it is visible: each request is recorded as event 4769 on the issuing domain controller, characteristically one account asking for many distinct service tickets in a short window, so this phase is routinely missed rather than inherently invisible.
How long the crack takes follows from composition and encryption type, not from password age: a dictionary word or predictable pattern on an RC4 ticket can fall in minutes on commodity hardware, because an RC4 key is a single unsalted MD4 pass over the password, while an AES key is derived through thousands of salted iterations and cuts candidate throughput by orders of magnitude. A password that survives a tester's time box is not evidence of safety, because an attacker keeps the ticket indefinitely and can bring more hardware to it.
A recovered service password works beyond the service it was issued for
The crack yields plaintext, and unless the account is explicitly constrained that plaintext works for interactive logon, SMB file access, remote management and database authentication. Those constraints are frequently absent, and where the account holds Domain Admins membership or equivalent delegated rights, a single crack converts into control of the directory. That outcome needs three conditions together: a user-class account carrying a service principal name, rights on that account that reach privilege directly or through a path, and a password crackable inside a realistic attacker budget.
Where any one of them is missing the finding is real but smaller. Where the same password has been reused on a second service account or on a local administrator, the reach widens again.
Replication rights turn one account into every account
006). That removes any need to crack anything further. Those rights arrive with Domain Admins, Administrators or Domain Controllers membership, or with an explicit permission entry on the domain object, and they do not come with Server Operators, Backup Operators or local administrator rights on an application server.
This step is therefore a precondition to verify with an effective-rights check, not an assumption to carry forward.
Reach into the plant network depends on how the two environments are joined
Control of the enterprise directory confers nothing by itself on a separate OT domain or forest, on a one-way replicated DMZ, or on engineering stations, HMIs and controllers that are not domain-joined. Where the jump hosts bridging the office network to production are joined to the enterprise domain, or the OT domain shares a trust with it, the same credentials open the engineering file shares holding product designs and controller project files, the backup servers that recovery depends on, and those jump hosts. Testing establishes which of those holds, and the reporting line separates what can be demonstrated, which is authentication to an in-scope host, from what follows only with control of OT assets, which is interference with a running process.
The absence of service principal names is not a boundary
An attacker holding write access over a privileged user object, through GenericAll, GenericWrite or write permission on the servicePrincipalName attribute, can add a service principal name to an account that carries none and roast it on demand, so an inventory showing no user service principal names is a snapshot rather than a guarantee. Those write entries are more often reached through a misconfigured access control entry than through group membership, which is why the check belongs with permissions review and not only with account listing. 004).
Business impact
The data reachable from a compromised domain is the organisation's engineering record. Product designs, CAD and CAM files, controller and robot program files, process parameters and quality records sit on file shares that a domain administrator can read by definition, alongside supplier pricing, tooling costs and contract terms. Theft of that material is quiet and does not expire: whoever takes it gains years of development work, and nothing is missing from the organisation's own systems afterwards to signal that it happened. Employee and customer personal data in HR and ERP systems is reachable with the same credentials, which turns an engineering problem into a notifiable one.
Financially the exposure is dominated by lost output rather than by incident response fees. A line that stops because its controlling systems, or the file shares they depend on, have been encrypted stops for every shift until recovery completes, and in process industries restarting is not instant: material in progress is scrapped, equipment is requalified and delivery commitments slip. Recovery costs rise sharply where the backup infrastructure was reachable with the same credentials, because restoration from offline copies takes days rather than hours. Cyber cover and OEM supplier agreements commonly carry privileged access conditions, so how a single service account password could reach Domain Admin is a question an organisation should be able to answer before it is asked. Manufacturers within the scope of NIS2 in the European Union carry reporting duties and management accountability for an incident of this kind, TISAX assessments are carried out against the VDA ISA catalogue, which includes identity and access management requirements covering privileged accounts, and personal data held in the same shares brings GDPR notification into the picture.
Operationally the lasting damage is the loss of a trustworthy identity system. Where directory credential material has been extracted, every password and every machine account in the domain has to be treated as known to the attacker, so the work becomes a rebuild of the directory's trust foundations rather than a password reset exercise, carried out while production is down. Plant environments add constraints an office network does not have: engineering workstations often run software that cannot be reimaged quickly, historians and control servers hold validated configurations, and safety cases may need review before equipment returns to automated control. The organisation is also left unable to say what was altered rather than only read, which is the first question an OEM customer or a regulator asks about parts produced inside the intrusion window.
How it is found
| Signal | How it is confirmed |
|---|---|
| Privileged accounts that carry a service principal name | We query the directory from a standard user context and list every user-class account with a populated servicePrincipalName, then cross-reference group membership, delegation settings and password age. Computer accounts, group managed service accounts, delegated managed service accounts and krbtgt are set aside, because their keys are machine-generated and nothing cracks them. An account that is both kerberoastable and privileged is the finding, and the unprivileged query context is the proof that it is reachable. Direct group listings are treated as a first pass only, so nested groups, the primary group and foreign security principals are resolved as well. |
| Whether the domain controller issues tickets without authorisation | We request service tickets for selected service principal names from an ordinary account and confirm that the KDC issues them. This establishes that collection requires no privilege at all, independently of how strong any individual password turns out to be, and it also shows which controller recorded the request. |
| The encryption type a ticket request actually returns | We request a ticket offering AES and record the encryption type returned, then repeat offering RC4 only and record whether the KDC still issues it. The observed encryption type is the finding; msDS-SupportedEncryptionTypes, the domain default and the encryption types configured on trusts are reported as supporting configuration. Where the account attribute is unset the domain default decides what is issued, which is why reading attributes alone can both miss live RC4 exposure and give false assurance after a partial AES migration. |
| Whether the service account password actually cracks inside the test window | We crack collected tickets offline on an isolated engagement system, inside an agreed time box, using rule sets together with wordlists built from the organisation's naming conventions. The result is reported with the hardware used and the elapsed GPU time, as recovered inside that budget or not recovered inside it, so it can be mapped to an adversary budget rather than to our schedule. A password that does not fall inside the window bounds nothing about a better resourced attacker, and the configuration finding stands on its own: a privileged, kerberoastable account whose password is set by a person. Any credential recovered is stored encrypted, reported out of band and destroyed on an agreed date, and it is treated as compromised, with immediate rotation recommended whether or not it was used any further in the test. |
| What the credential reaches once recovered | We map the account's direct and nested group membership, permissions held on the domain and OU objects, rights over Group Policy, delegation configuration, local administrator rights granted by policy and any logon restrictions, then verify reachability against representative in-scope hosts. Directory replication rights are checked specifically, because they are what makes one account equivalent to all of them. This is what separates a single application compromise from a domain compromise, and it is what sets the severity. |
| Write access over privileged user objects, which creates a service principal name on demand | We enumerate write-level permission entries over privileged users and groups, including GenericAll, GenericWrite and write permission on the servicePrincipalName attribute, because an attacker holding one of them can make an account roastable that is not roastable today. This is why a clean service principal name inventory is not on its own a statement about future exposure. |
| Accounts that do not require Kerberos pre-authentication | We flag accounts configured without Kerberos pre-authentication, which expose the response to the initial authentication request to the same offline cracking and need only a valid username to collect, catalogued as AS-REP roasting (T1558.004). It falls out of the same inventory pass and is reported alongside the kerberoastable accounts, because the remediation owner is the same. |
How it is fixed
| Control | What makes it hold |
|---|---|
| Contain any password recovered during testing first | A credential recovered in a test is a credential a third party holds in plaintext, so containment comes before any programme of work. Rotate the password on every account where it was recovered and on every account using the same password, inside an agreed short window, and treat those accounts as compromised regardless of how far they were used. Review recent 4769 and 4624 activity for each one for use that the testers cannot account for, then begin the work below in the order given. |
| Give services passwords no person chooses: group managed service accounts | Group managed service accounts and machine accounts use long randomly generated passwords that Active Directory rotates on its own, which makes the ticket they protect computationally infeasible to crack rather than unreachable: the ticket is still issued to anyone who asks for it. Two companion controls are mandatory, because the managed password can be read by any principal listed in msDS-GroupMSAMembership and derived by anyone who compromises the KDS root key. Keep that retrieval list restricted to a named tier-0 group and review it periodically, treat retrieval rights and the KDS root key as tier-0 assets, and audit reads of both, otherwise a loose retrieval permission becomes a faster path than the original attack. Where an application cannot use a managed account, a passphrase of at least 25 genuinely random characters with a named rotation owner gives the same resistance to offline cracking, though the rotation then depends on a person rather than on the directory, and it holds only while that password is not reused anywhere else. None of this addresses over-privilege, which the next item covers. |
| Take service accounts out of privileged groups, and test effective rights rather than group lists | A service account should hold only the rights its application needs on the hosts it runs on, with Domain Admins membership and equivalent delegated rights removed. Removing the group is not the acceptance test, because equivalent power is held through permission entries on the domain and OU objects, through AdminSDHolder, through rights to link or edit Group Policy, through nested and foreign security principal groups, through unconstrained or resource-based constrained delegation configured on the account, and through local administrator rights on a tier-0 host granted by policy. Enumerate all of those and confirm the account cannot reach privilege by any of them. Enforce where the account may authenticate with Authentication Policy Silos and host tiering rather than with the userWorkstations attribute, which does not prevent ticket issuance and is bypassable across several network logon paths. Protected Users is not appropriate for most service accounts, because it blocks NTLM, RC4 and delegation and will break applications that depend on them. A cracked password then buys one application, provided that application's own host is not itself a path to tier 0, as a database server with command execution surface or a host trusted for delegation would be. |
| Require AES, and audit what still depends on RC4 before enforcing | Setting supported encryption types to AES on service accounts and across the domain raises the cost of cracking each ticket by orders of magnitude, because the AES key is derived through thousands of salted iterations where the RC4 key is a single unsalted MD4 pass over the password. It does nothing against a password a person could guess, which falls quickly against AES tickets as well, and nothing against the collection step, so it is sequenced after the password work and never instead of it. Before enforcement, inventory what depends on RC4: applications, the encryption types configured on incoming and outgoing trusts, non-Windows Kerberos clients and appliances that authenticate with Kerberos. An incomplete rollout tends to end in a permanent compatibility exception that reinstates the weakness. Take the acceptance criterion from the encryption type of a ticket actually issued, not from the configured attribute, because an unset attribute leaves the domain default to decide. |
| Keep a live inventory of service principal names, and of who can create one | The accounts that get cracked are the ones nobody owns: duplicate service principal names, names left behind on disabled or decommissioned accounts, and accounts whose password has not changed in years. The same inventory should cover write-level permissions over privileged user objects, which let an attacker create a service principal name where none exists, and accounts configured without Kerberos pre-authentication, which are exposed to the same offline cracking by a different route. Tie the review to application decommissioning and to joiner, mover and leaver processes so the list stays accurate, because a one-off cleanup is out of date as soon as the next application is deployed. |
| Make ticket requests visible: alert on event 4769 and plant a decoy SPN | Kerberos service ticket requests are recorded as event 4769, so the collection step has a detection path, but alerting on request volume alone is impractical: 4769 is among the highest volume events in a domain and needs baselining first. Alert on composite conditions instead, such as one account requesting many distinct service principal names in a short window, or RC4 requests from accounts that should be AES only. Collection has to cover every domain controller, read-only controllers included, because one unmonitored controller makes the pattern invisible. A decoy service account, carrying a service principal name, no service behind it, no privileges and a random password, is the highest signal control available here, and it stays low in false positives once the organisation's own directory assessment tooling, credentialed vulnerability scanners and scheduled authorised tests are deconflicted, since those enumerate and request every name. All of this depends on the events reaching the monitoring platform, which is worth verifying rather than assuming. |
Questions
What is kerberoasting?
Kerberoasting is an Active Directory attack in which an authenticated domain user requests Kerberos service tickets for accounts that run services, then cracks those tickets offline to recover the service account passwords. It needs no administrative rights and no software vulnerability, only a valid domain account and a service password that a person chose. MITRE ATT&CK catalogues it as T1558.003.
Can an attacker kerberoast without admin rights?
Yes. Any authenticated domain account can read service principal name attributes and request service tickets, because the key distribution centre issues a ticket without checking whether the requester is entitled to use that service. Enforcement is designed to happen at the service itself, which the attacker never contacts. One phished or reused employee password is therefore a realistic starting point for domain compromise wherever a privileged service account's password is weak.
Does kerberoasting show up in Windows event logs?
The request itself is logged as event 4769 on the domain controller that issues the ticket, but the cracking runs on the attacker's own hardware, so the domain records a successful ticket request and nothing more. Detection depends on baselining 4769 and alerting on composite conditions, such as one account requesting many distinct service tickets in a short window or RC4 requests from an account that should be AES only, and on collecting those events from every domain controller, read-only controllers included.
How long does it take to crack a kerberoasted service account password?
Encryption type and password composition decide it, not password age or attacker patience. A dictionary word or predictable pattern protected by an RC4 ticket can fall in minutes on commodity GPU hardware, because an RC4 Kerberos key is a single unsalted MD4 pass over the password, while an AES key is derived through thousands of salted iterations, so the same hardware tests orders of magnitude fewer candidates per second. A long randomly generated password does not fall at all. A password that survives a test window is not evidence of safety, because an attacker keeps the ticket indefinitely and can bring more hardware to it.
How do you prevent kerberoasting?
Kerberoasting is prevented by removing what it feeds on, which is a password a person chose on an account worth owning. Give every service a group managed service account, so that Active Directory generates and rotates a password nobody types, and give the exceptions a passphrase of at least 25 random characters with a named rotation owner. Remove service accounts from Domain Admins and from equivalent delegated rights, verified by an effective-rights check rather than a group listing, so that a crack buys one application instead of the directory. Set supported encryption types to AES, which raises the cost of each crack without protecting a guessable password and without stopping ticket collection. Then baseline event 4769 and alert on it, so the collection step is visible. Password length decides whether the crack succeeds, and the account's rights decide what it is worth.
What is the difference between kerberoasting and AS-REP roasting?
Kerberoasting targets accounts that carry a service principal name and cracks a service ticket to recover the service account password, so it needs a valid domain account to request that ticket. AS-REP roasting, catalogued as T1558.004, targets accounts configured without Kerberos pre-authentication and needs only a valid username, cracking the response to the initial authentication request instead. Both end in the same place, which is an offline attack on a password a person chose, and both surface from the same directory inventory.
Do group managed service accounts stop kerberoasting?
Group managed service accounts stop kerberoasting succeeding. One still carries a service principal name and tickets can still be requested for it, but its password is long, randomly generated and rotated by Active Directory, so offline cracking recovers nothing usable. Two pieces of work remain: find the applications that cannot use a managed account and give those a long random passphrase, and keep the list of principals allowed to retrieve the managed password restricted to a named tier-0 group, because that retrieval right is equivalent to holding the password, as is control of the KDS root key.