> According to our friend Chick3nman, the same RTX 5090 can crack 4.18 billion (with a “b”) of these hashes every second.
It may just be imprecise writing, but this is very misleading. The stat is that 4.18 B hashes can be computed per second, not cracked. Computing a hash means converting a given input into its hash. Cracking a hash means starting from the given hash and determining what the input must have been. To crack a given hash you have to iterate over the input space and compute all their hashes (barring other exploitable weaknesses).
So, sure you can "crack" 4.18 B hashes per second, as long as you don't care that the hashes you are "cracking" are not the one you're interested in.
As a pentester kerberosting used to reveal a service password on about 50% of networks on the 2010s when admins were making the passwords. Today our advice to clients on kerberosting is the same as it was back then, use a password manager to generate a 21 character password for all service accounts and disabled RC4 where possible. 52^21 is quite a large key space and even at 10^10 guesses per second over a year your chances are less than 1 in a billion of a successful crack.
In my experience it's always been legacy hardware or industrial automation where it would cost millions to update the equipment / software. Simply limiting the blast radius of those systems and isolating them on the network into their own security zone is always less expensive and thus the perfectly reasonable solution.
I will make a slight subtle distinction though. Cracking a hash doesn't mean determining what the input must have been. It means finding an input that resolves to the same hash - not necessarily the original input.
Due to the pigeonhole principle they are inevitable. At least if the input space is bigger than the output, which may not be the case for passwords of course.
Still, even if they are shorter, if you do find a hash pre-image you don't actually know for absolute certain that what you found was the original input. Collisions are still possible.
In practical terms this doesn't really matter mostly. It's just good to be very clear about what you actually know when dealing with cryptography.
Given that a collision is technically what they're looking for.
They're just limiting the input to a "reasonable" range to find one faster.
Side note: A quick look through the iOS keyboard shows another 25+ characters that can be reasonably expected to match between operating systems. I need to try using some of them in my passwords. Going from 70^(length) to 100^(Length) is nothing to scoff at.
Good overview of Kerberoasting, still a common attack chain. A couple things though: To obtain access to a service, you actually need to get a service ticket (TGS) from the KDC (Domain Controller) to authenticate to the service, not a TGT. The TGT is the first ticket acquired during authentication to the domain. In addition, the "salt" is not a true salt but a concatenation of the domain and principal name, so even worse. Active Directory (invented at MIT) supports RC4, AES128, and AES256 encryption types, however you can effectively disable RC4 via Group Policy. The reason RC4 is still supported is to support legacy systems. Many organizations use old software that only supports RC4. For example, I've run into many manufacturing and small businesses that have no choice but to use it and can't upgrade the software due to $$$. Anyway, good stuff! Shout out to Tim Medin, who published this back in 2014.
AD was invented by Microsoft, gluing together Kerberos (from MIT) and LDAP (from UMich). If it was from MIT, we wouldn't have had Windows 2000's infamous proprietary PAC.
If we're being pedantic, TGS ("ticket granting server") is the service you get service tickets from. Service tickets are (occasionally) abbreviated ST, as you'd expect. The TGS is a logical part of the KDC, distinguished from the AS which grants TGTs.
It’s been ages since I stood up a Kerberos realm, but… would it be possible to allow RC4 only for specific users? Like encrypt win98server@example.com’s heavily locked down account with RC4, but everyone else gets AES-256?
I was about to suggest employing PingCastle to audit domains for weak default configurations such as these, but apparently, PingCastle still doesn't complain about RC4 enabled Kerberos accounts - only about DES. So now is a good opportunity to check any domains you are responsible for by hand.
Note that since the 2022 update KB5019964, AES is the default for all AD accounts that did not have the administrator explicitly set a different encryption scheme. However, administrators may have done that on your domain in the past, because back in the day, the default encryption scheme was not even RC4, but DES, which is even worse. Some people therefore set everything to RC4 by hand, before AES was introduced as an option.
The allowed encryption types are set via the msDs-supportedEncryptionTypes attribute on each individual AD account. This property is a 32 bit bitmask, where 8 is AES128, 16 is AES256, and any other bits set are garbage encryption schemes. However, if the attribute is set to 0, the account reverts to the default, which ever since the aforementioned patch has been 24 (AES128|AES256).
Anyway, the following Powershell (run with elevated permissions on the domain!) lists you all insecure user accounts:
This may be an important clue for something that happened recently in our environment. We configured a bunch of database service SPNs and immediately all Kerberos auth failed. Rolled it back and talked to our support provider. They said that the expected behavior was to default to AES but that for some reason our environment wasn’t honoring that. We ended up having to manually enable AES support on each service account, which is a minor pain in the ass, and since no one in the IAM team was involved in the original domain setup, no one could explain why this happened or whether there was a manual RC4/DES config lurking out there in the shadows.
I don't think I understand you. The RC4 encryption type is msDs-supportedEncryptionTypes 4 (i.e. 0b0100). DES_CBC_CRC is 1, DES_CBC_MD5 is 2. They do not "correlate".
And regarding the NT hash: the NT hash is named after NTLM, not Kerberos. NTLM is a completely different (and much less secure) authentication mechanism. And the NT hash is not DES at all, it's MD4. You may be confusing it with the LM hash, which is indeed DES, but does not support unicode and is not common anymore.
The LM hash is disabled on domains with an LmCompatibilityLevel of 4 or above. (It's accepted, but clients shouldn't send it, on the default LmCompatibilityLevel of 3, which, by the way, unless your domain has devices from the stone age, you can safely set to 5, disabling LM and NTLMv1.) Although, if you can, you should disable NTLM on the domain altogether, because it's a much more vulnerable protocol than Kerberos.
This article is somewhat incorrect. Kerberoasting abuses Ticket Granting Service tickets (TGSs, which are used to request access to a registered service in Active Directory), not Ticket Granting Tickets (TGTs, which are used to prove identity to a Domain Controller and request TGSs). However, the general attack described is still correct.
TGS are (AES or RC4) encrypted with the NT password hash of the service account they are associated with. If you have a weak service account password, then TGS can be cracked to obtain the service account's password. A lot of times admins will create service accounts that have way more permissions than required (e.g. they make them a DA) which can lead to an immediate privilege escalation. Sometimes they also use regular user accounts for service registration instead of designated service accounts, and user accounts tend to have weaker passwords. To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.
1. Use managed or group managed service accounts instead of manually managed ones where possible. This ensures that account passwords are long, strong, and rotated regularly. If you are going to provision service accounts manually, give them very strong passwords.
2. Apply the principle of least privilege and only assign service accounts the privileges they need. Avoid placing them in high privilege groups.
3. Disable RC4 in your environment if possible via Group Policy.
An actually useful mitigation would be to use service keytabs instead of service passwords. Because with a keytab, the keytab is a file that just contains an AES128/256/RC4 key instead of a password, which makes it sufficiently hard to guess. The service just uses this file to decrypt its service tickets then.
However, keytab usage is rare in the Windows AD world because people don't seem to comprehend what a keytab is and does, and why it is far better than using passwords for services.
Keytab usage is rare because the service you intend to run under that service account does not support keytabs.
There's also the knock-on effect of Kerberos being mostly hidden in Active Directory and creating keytabs requiring CLI tooling -- from way back when AD was a GUI only (mostly) affair for AD admins.
In my experience next to nobody knows about the CLI tooling for Kerberos in Windows. It's a damn shame, too, because Windows interops well w/ standard Kerberos in my opinion.
The only time that I can remember having to use keytabs is with ISC DHCP.... at home.
No 3rd party AD-integrated software, of which there were plenty of non-MSFT stuff, did I ever have to create a keytab for when playing Domain Admin at work.
I was a little irritated that Prof. Green didn't really discuss that Microsoft has made recommendations to mitigate. Thank you for summarizing.
The mitigations are there but it takes time for Microsoft's Customers to move to the new versions. I don't think that's Microsoft's problem. That's just their market. I don't think Prof. Green has an understanding of that side of it.
I guess one could argue that Microsoft should backport the new code to older products and give it to Customers who aren't actively paying for maintenance or subscription licensing. They made the business decision not to.
So my understanding is that Wyden's staff has been bothering the company about this class of vulnerabilities for a while, and the recent recommendations (a blog post explicitly cited in my post) are one output of that.
But I don't really accept this explanation. I always understand that there are legacy deployments and Microsoft needs to support them, but Kerberos-misconfiguration issues are extremely subtle in their implications, and MS should understand that one blog post (or some knowledge base articles) isn't going to get the message across to the hundreds/thousands of AD admins whose networks are currently at risk.
What I think recent versions of the MS software could do: (1) automatically scan configurations for accounts set up this way, (2) be incredibly annoying about changing the configuration (there are a handful of ways to do this that should be workable for many legacy configurations). If admins want to override the annoying and explicit warnings, that would be on them and not MS. As far as I can tell, Microsoft isn't doing this. But if I'm wrong, please let me know.
I absolutely agree that Microsoft could do better, but they are making progress in removing support entirely for broken (from a security perspective) older protocols such as NTLMv1 (which uses DES as well: more here -- https://bit.ly/crackingntlmv1) and SMB1.
The financial incentives drive Microsoft to support every possible (mis)configuration, forever. It's the tireless work of a few folk at Microsoft like Ned Pyle, Steve Syfus, and Mark Morowczynski that have landed the changes so far.
There could absolutely be a "security check" tool deployed by default with Server 2025 or similar that looks for Kerberoastable user accounts (any account with a ServicePrincipalName is technically Kerberoastable, like computer accounts), AS-REP roastable accounts, weak encryption types, etc. That would probably get more traction than changing defaults out of the box for everyone, as that's another way to phrase "breaking customer environments when they upgrade".
As an outsider it seems like MS has been much more proactive at moving away from insecure crypto in other places. For example, there was a while where every Windows release would disable some old insecure part of the SMB/CIFS protocol by default while still allowing it to be enabled for backwards compatibility if necessary.
Are they doing the same for AD? From the article it sounds like it falls back to RC4 automatically out of the box. That is something they should have started migrating away from at least a decade ago - gradually, with options for backwards compatibility to support their customers - but the fact that it is enabled by default in 2025 seems insane.
> To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.
I have a vague understanding of Kerberos, and this is where I’m mystified. Why is the KDC or anything else willing to issue a TGS ticket encryption against a service password before the requesting user authorizes themselves? Or is the issue that authentication and authorization are split and the KDC has no idea whether the requesting user is authorized.
The reason that the KDC doesn't decide if the user should get a ticket is that then the power requirements of the DC would be enormous. It should have to know if a user is supposed to have access to every single service in the environment. It would be a massive database. That massive database would also have to sync to all the other DCs.
To alleviate this, Kerberos let's the server decide if the user has access, and if so, how much
Kerberos doesn't concern itself with authorization, just authentication. It's up to the app to accept or reject a ticket, and that process is completely opaque to kerberos. It _could_ be extended since Kerberos allows pretty much any damn thing you want to happen with vendor extensions, but I'm not sure that's a situation you want AD to be handling given its track record in the rest of the security space.
Is this really a useful mitigation here? If someone has suitable presence to make requests to the TGS, then the time window for cracking and exploiting those tickets (if they are exploitable) is surely always going to be small compared to the rotation window. Hackers don't typically have the patience to sit running hashcat on an old GPU for weeks, they just find some way to get ephemeral access to a bunch of faster GPUs.
Managed and group managed service account passwords are typically 240 characters long and rotate every 30 days. It is highly unlikely that an attacker can crack these.
Fair enough, I guess for some threat actors there is a difference between "uncrackable" and "crackable with more than 30 days effort". But that's a pretty select group of actors.
> This article is somewhat incorrect. Kerberoasting abuses Ticket Granting Service tickets (TGSs...
> TGS are (AES or RC4) encrypted...
What? No. The "TGS" is the "ticket granting service", and it's part of the KDC. A "TGT" is a "ticket granting ticket" -- an object, a blob which is a) a Ticket, b) whose service principal is a TGS principal (meaning of the form krbtgt/TARGET_REALM@ISSUER_REALM).
> TGS-REPs which are colloquially referred to as TGS tickets or TGSs
They are NOT colloquially referred to as such by anyone I know.
A TGS-REP is just a reply from the TGS. A TGS-REP bears a ticket which can be a TGT or not depending on various things.
I have never, ever seen a TGS-REP referred to a you say.
I have heard lots of weird things in the Kerberos space, but not this. E.g., I've see "GSS-API" pronounced as "guhsappi". I've seen people say "give me the Kerberos" (meaning "tell me how to get credentials").
FYI I am a Kerberos implementor/maintainer and have authored several Internet RFCs on Kerberos, and have supported Kerberos deployments at several organizations. Sorry to pull credentials here, but I'm annoyed that you felt the need to correct TFA on something they were not wrong about.
See perhaps "Active Directory Hardening Series - Part 4 – Enforcing AES for Kerberos":
> Identifying devices limited to RC4 is a critical step but has historically been a tricky problem to solve. However, a recently discovered "feature" in 4768 events can help you identity such devices. […] As a result, 4768 events can be used to identify devices that only support RC4.
> While DES has long been considered insecure, CVE-2022-37966 accelerates the departure of RC4 for the encryption of Kerberos tickets. If you have not explicitly assigned an algorithm to accounts, then AES will be used in the future. You can use PowerShell to determine which accounts are vulnerable to weak encryption.
I agree -- Ascension is also complicit in this, and merely paying lip-service to HIPAA. The Senator's letter, on the other hand, paints a one-sided picture of the matter.
Help me out here. I thought I was understanding the process as I went along, but my head is still spinning.
This is what I understood: the corporate network needs to be able to connect ordinary users on some random employee's work computer, to privileged services elsewhere on the (generally insecure) network, securely. The idea is that the server sends the client some kind of encrypted token, the decryption of which — when the system is properly configured — would require some long, random passphrase beyond mortal comprehension. The user's machine stores the passphrase so that secure passphrases can be used by the mere mortal users, and automates the internal connection. But if a user gets compromised from outside the network, an attacker could explicitly request and exfiltrate one of the tokens, and run brute force attacks on it locally to the attacker; and for historical reasons, the system is likely to be poorly configured, such that the necessary passphrase is weak enough to be susceptible to this. Then the attacker uses the decrypted token to escalate access.
My question is: why can't the attacker just direct the compromised machine to connect to the service normally? Or else, where did I lose the plot?
If you have the user's credentials then you can indeed connect to the service as you normally would. The advantages of performing this attack are:
1. You can obtain the service account's password, and the service account may be provisioned with more privileges than the user's account that you compromised. This allows for privilege escalation beyond simply accessing the service. For example, perhaps the service account has administrative access on other machines, or it is used for multiple services, or it is a Domain Admin in which case you can completely compromise the domain.
2. TGS tickets used to request access to a service are cryptographically signed with the password hash of the service account. Services use this to confirm ticket validity. In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users. Instead of accessing the service as a low privilege user, you can now access the service as an Enterprise Admin or another high privilege account which could enable access to more resources or administrative access to the machine. This is called a Silver Ticket attack.
> You can obtain the service account's password, and the service account may be provisioned with more privileges than the user's account that you compromised.
It's wild to me that this could happen just from solving the puzzle that allows the user's account to use the user's privileges (only) on the service... ?
> In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users.
Since it's cryptographic signing, wouldn't this require reversing the hash? Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
> It's wild to me that this could happen just from solving the puzzle that allows the user's account to use the user's privileges (only) on the service... ?
Yes, it is an unfortunate design decision in the Microsoft implementation of the Kerberos protocol.
To interact with Active Directory and perform privileged actions, a service needs an Active Directory account that it can leverage for authenticated actions. This is colloquially referred to as a "service account", but it is not a special account type, it is just a regular Active Directory user or computer account designated for exclusive use by a service. Sometimes administrators will save time by registering a service under their own Domain Admin user account instead of creating a designated account for a service. This effectively makes their user account the service account. In other cases, extensive privileges may be required by a service (e.g. for network access control services, asset discovery services, vulnerability scanners, etc) and administrators find it easier to just create a Domain Admin (high privilege) account for that service than to do fine grained permissioning. This creates a dangerous situation where if an attacker can kerberoast the account associated with the service, they can immediately take possession of a high privilege account that can be used anywhere within the Active Directory environment.
> Since it's cryptographic signing, wouldn't this require reversing the hash?
Yes, you would need to brute-force it.
> Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
Theoretically yes, any valid inverse of the hash would work, but to my knowledge there aren't any hash collisions for the NT hash algorithm. Practically speaking, this means that only the user's password would yield the correct hash.
Thanks, I think I get it now. Everything to do with cryptography always seems to struggle to stick in my head, though, even when I understand the math in principle.
You're missing the forest for the trees. A regular user account should never have a service principal name (SPN), for the simple reason that it can be attacked in the way described. That is why service accounts have really long complex passwords.
Kerberoasting nearly always occurs due to an installation process that assigns an SPN to an account that is performing an installation, or inappropriately selected by the installer. That is the first problem. The second problem is there isn't anyone auditing this stuff because they are incompetent.
If you reported an issue of an account that had an SPN but should not, nearly everyone would either not know what you are talking about, or disagree that it is a security problem without any knowledge or basis.
> That is why service accounts have really long complex passwords.
The sad thing is, they don't always have long complex passwords. They SHOULD, but they don't. Many orgs are scared of changing service account passwords due to the possibility of an outage.
I don't often see a day to day user with an SPN. I do see plenty of SPNs tied to service accounts where the service account password is crackable/Kerberoastable.
Microsoft is also guilty of reading the market and keeping up compatibility to make their products remain relevant. Prof. Green makes sweeping statements about how Microsoft should break compatibility to remove these vulnerabilities, but he doesn't have the market pressures that Microsoft does.
Could Microsoft work harder on this? Sure. Do they have to worry about keeping their Customers happy? Absolutely.
The corporate IT market moves at a glacial pace. Hopefully the rise of IT security issues having actual business consequences will change that, but that's not Microsoft's problem. That's the ecosystem they live in.
Were bad protocol / design decisions made in the past? For sure. Microsoft has been working on this (see Managed Service Accounts and Group Managed Service Accounts). It takes time for corporate customers to adopt these new versions.
Corporate IT won't forklift out old systems without business justification. Maybe the pressure from the insurance industry will help. Pressure from the ransomware industry is a certainly helping, too.
Corporate IT just forklifted out tons and tons of workstations and laptops for the windows 10 to 11 migration.
Active Directory is just not developed anymore, its basically abandonware that everyone still uses. The new hot stuff is the Azure AD/Entra ID bastardization of Web Auth plus AD that they try to upsell people to.
> Kerberos changes for Algorithms used for Ticket Granting Tickets: The Kerberos Distribution Center will no longer issue Ticket Granting Tickets using RC4 encryption, such as RC4-HMAC(NT).
Kerberoasting specifically targets service tickets, not TGTs. I wonder if the change really only applies to TGTs or if they simply neglected to mention service tickets.
> Corporate IT just forklifted out tons and tons of workstations and laptops for the windows 10 to 11 migration.
That's just client computer replacement, though. That's a known quantity and is on most IT orgs. roadmaps. We've been replacing computers regularly since we got PCs.
Moving to new AD functional levels, even when the actual risk is minimal, is something I've seen IT orgs. drag their feet on out of fear.
It's still common in IT departments to enter the domain administrator password to join a computer to a domain or install software on a client machine. This seems insane to me, you can just fake the windows gui in a Fullscreen application and keylog the password - even using a web browser. I think AD is a relic of the 90s that should be retired
Kerberoasting keeps popping up in real-world incidents. Do you think enterprises underestimate the human factor in securing service accounts more than the technical exploits?
In Kerberos, the answer is effectively no. To generate the NT hash, the password is hashed using a single round of MD4. This is what is used to encrypt (and sign) tickets.
The attack is, guess a password, hash it, and attempt to decrypt.
With AES Kerberos keys there is a salt... but not a good one. It is just the domain (realm) and the username.
This makes me so mad. 5he excuses from Microsoft are quite pathetic
Their ubiquitous systems have been notoriously insecure for decades.
They are one of the highest revenue firms on the planet.
It is going to take strict liability for software developers before we all pull up our socks and put an end to this nonsense. When it is a marketing advantage to produce insecure software, what else can fix our industry?
This makes me so mad. 5he excuses from Microsoft are quite pathetic
Their ubiquitous systems have been notoriously insecure for decades.
They are one of the highest revenue firms on the planet.
It is going to take strict liability for software developers before we all pull up oursocks and put an end to this nonsense. When it is a marketing advantage to produce insecure software, what else can fix our industry?
> According to our friend Chick3nman, the same RTX 5090 can crack 4.18 billion (with a “b”) of these hashes every second.
It may just be imprecise writing, but this is very misleading. The stat is that 4.18 B hashes can be computed per second, not cracked. Computing a hash means converting a given input into its hash. Cracking a hash means starting from the given hash and determining what the input must have been. To crack a given hash you have to iterate over the input space and compute all their hashes (barring other exploitable weaknesses).
So, sure you can "crack" 4.18 B hashes per second, as long as you don't care that the hashes you are "cracking" are not the one you're interested in.
As a pentester kerberosting used to reveal a service password on about 50% of networks on the 2010s when admins were making the passwords. Today our advice to clients on kerberosting is the same as it was back then, use a password manager to generate a 21 character password for all service accounts and disabled RC4 where possible. 52^21 is quite a large key space and even at 10^10 guesses per second over a year your chances are less than 1 in a billion of a successful crack.
Cheap Cloud storage has never returned rainbow tables to viability, right? I stopped checking sometime after I got out of the space.
salting defeats the rainbow table, kerberos uses PBKDF2 that defeats the rainbows
> disabled RC4 where possible
I'm curious. Under what circumstances would it be _not_ possible to disable RC4?
Is this in case there is a Windows 98 machine running somewhere in the network?
In my experience it's always been legacy hardware or industrial automation where it would cost millions to update the equipment / software. Simply limiting the blast radius of those systems and isolating them on the network into their own security zone is always less expensive and thus the perfectly reasonable solution.
Good point, it's computing not cracking.
I will make a slight subtle distinction though. Cracking a hash doesn't mean determining what the input must have been. It means finding an input that resolves to the same hash - not necessarily the original input.
Not sure why this is downvoted, as hash collisions can happen, even if unlikely.
Due to the pigeonhole principle they are inevitable. At least if the input space is bigger than the output, which may not be the case for passwords of course.
Still, even if they are shorter, if you do find a hash pre-image you don't actually know for absolute certain that what you found was the original input. Collisions are still possible.
In practical terms this doesn't really matter mostly. It's just good to be very clear about what you actually know when dealing with cryptography.
Given that a collision is technically what they're looking for.
They're just limiting the input to a "reasonable" range to find one faster.
Side note: A quick look through the iOS keyboard shows another 25+ characters that can be reasonably expected to match between operating systems. I need to try using some of them in my passwords. Going from 70^(length) to 100^(Length) is nothing to scoff at.
Good overview of Kerberoasting, still a common attack chain. A couple things though: To obtain access to a service, you actually need to get a service ticket (TGS) from the KDC (Domain Controller) to authenticate to the service, not a TGT. The TGT is the first ticket acquired during authentication to the domain. In addition, the "salt" is not a true salt but a concatenation of the domain and principal name, so even worse. Active Directory (invented at MIT) supports RC4, AES128, and AES256 encryption types, however you can effectively disable RC4 via Group Policy. The reason RC4 is still supported is to support legacy systems. Many organizations use old software that only supports RC4. For example, I've run into many manufacturing and small businesses that have no choice but to use it and can't upgrade the software due to $$$. Anyway, good stuff! Shout out to Tim Medin, who published this back in 2014.
> Active Directory (invented at MIT)
AD was invented by Microsoft, gluing together Kerberos (from MIT) and LDAP (from UMich). If it was from MIT, we wouldn't have had Windows 2000's infamous proprietary PAC.
History of Active Directory (derived from MS Exchange), see https://hardcoresoftware.learningbyshipping.com/p/bonus-the-...
> you actually need to get a service ticket (TGS)
If we're being pedantic, TGS ("ticket granting server") is the service you get service tickets from. Service tickets are (occasionally) abbreviated ST, as you'd expect. The TGS is a logical part of the KDC, distinguished from the AS which grants TGTs.
Kerbernerd revealed.
It’s been ages since I stood up a Kerberos realm, but… would it be possible to allow RC4 only for specific users? Like encrypt win98server@example.com’s heavily locked down account with RC4, but everyone else gets AES-256?
Yes you can enable specific encryption types for users. It's not super common, but it can be done.
Just to add to this, the salt (domain [realm] and username) is only used to generate the AES keys, not the RC4. The RC4 key is simply the NT hash.
And thanks for the shout out!
I was about to suggest employing PingCastle to audit domains for weak default configurations such as these, but apparently, PingCastle still doesn't complain about RC4 enabled Kerberos accounts - only about DES. So now is a good opportunity to check any domains you are responsible for by hand.
Note that since the 2022 update KB5019964, AES is the default for all AD accounts that did not have the administrator explicitly set a different encryption scheme. However, administrators may have done that on your domain in the past, because back in the day, the default encryption scheme was not even RC4, but DES, which is even worse. Some people therefore set everything to RC4 by hand, before AES was introduced as an option.
The allowed encryption types are set via the msDs-supportedEncryptionTypes attribute on each individual AD account. This property is a 32 bit bitmask, where 8 is AES128, 16 is AES256, and any other bits set are garbage encryption schemes. However, if the attribute is set to 0, the account reverts to the default, which ever since the aforementioned patch has been 24 (AES128|AES256).
Anyway, the following Powershell (run with elevated permissions on the domain!) lists you all insecure user accounts:
Remember that computer accounts have passwords too:This may be an important clue for something that happened recently in our environment. We configured a bunch of database service SPNs and immediately all Kerberos auth failed. Rolled it back and talked to our support provider. They said that the expected behavior was to default to AES but that for some reason our environment wasn’t honoring that. We ended up having to manually enable AES support on each service account, which is a minor pain in the ass, and since no one in the IAM team was involved in the original domain setup, no one could explain why this happened or whether there was a manual RC4/DES config lurking out there in the shadows.
The RC4 encryption type correlates to the DES hash (more commonly the "NT" hash), so PingCastle has the right warning.
I don't think I understand you. The RC4 encryption type is msDs-supportedEncryptionTypes 4 (i.e. 0b0100). DES_CBC_CRC is 1, DES_CBC_MD5 is 2. They do not "correlate".
And regarding the NT hash: the NT hash is named after NTLM, not Kerberos. NTLM is a completely different (and much less secure) authentication mechanism. And the NT hash is not DES at all, it's MD4. You may be confusing it with the LM hash, which is indeed DES, but does not support unicode and is not common anymore.
The LM hash is disabled on domains with an LmCompatibilityLevel of 4 or above. (It's accepted, but clients shouldn't send it, on the default LmCompatibilityLevel of 3, which, by the way, unless your domain has devices from the stone age, you can safely set to 5, disabling LM and NTLMv1.) Although, if you can, you should disable NTLM on the domain altogether, because it's a much more vulnerable protocol than Kerberos.
This article is somewhat incorrect. Kerberoasting abuses Ticket Granting Service tickets (TGSs, which are used to request access to a registered service in Active Directory), not Ticket Granting Tickets (TGTs, which are used to prove identity to a Domain Controller and request TGSs). However, the general attack described is still correct.
TGS are (AES or RC4) encrypted with the NT password hash of the service account they are associated with. If you have a weak service account password, then TGS can be cracked to obtain the service account's password. A lot of times admins will create service accounts that have way more permissions than required (e.g. they make them a DA) which can lead to an immediate privilege escalation. Sometimes they also use regular user accounts for service registration instead of designated service accounts, and user accounts tend to have weaker passwords. To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.
Even if the service account is lower privilege, this can enable a silver ticket attack. https://www.crowdstrike.com/en-us/cybersecurity-101/cyberatt...
There are multiple mitigations for this:
1. Use managed or group managed service accounts instead of manually managed ones where possible. This ensures that account passwords are long, strong, and rotated regularly. If you are going to provision service accounts manually, give them very strong passwords.
2. Apply the principle of least privilege and only assign service accounts the privileges they need. Avoid placing them in high privilege groups.
3. Disable RC4 in your environment if possible via Group Policy.
4. Monitor for RC4 ticket requests. AES-encrypted tickets are the default these days. https://adsecurity.org/?p=3458
5. Create a honeypot service account: https://adsecurity.org/?p=3513
There is a somewhat similar attack against TGTs called ASREPRoasting: https://book.hacktricks.wiki/en/windows-hardening/active-dir...
An actually useful mitigation would be to use service keytabs instead of service passwords. Because with a keytab, the keytab is a file that just contains an AES128/256/RC4 key instead of a password, which makes it sufficiently hard to guess. The service just uses this file to decrypt its service tickets then.
However, keytab usage is rare in the Windows AD world because people don't seem to comprehend what a keytab is and does, and why it is far better than using passwords for services.
Keytab usage is rare because the service you intend to run under that service account does not support keytabs.
There's also the knock-on effect of Kerberos being mostly hidden in Active Directory and creating keytabs requiring CLI tooling -- from way back when AD was a GUI only (mostly) affair for AD admins.
In my experience next to nobody knows about the CLI tooling for Kerberos in Windows. It's a damn shame, too, because Windows interops well w/ standard Kerberos in my opinion.
The only time that I can remember having to use keytabs is with ISC DHCP.... at home.
No 3rd party AD-integrated software, of which there were plenty of non-MSFT stuff, did I ever have to create a keytab for when playing Domain Admin at work.
I used them with MobileIron, that was it.
Group Managed Service Account is a better option than keytab if you're assuming Windows Server/Active Directory.
I was a little irritated that Prof. Green didn't really discuss that Microsoft has made recommendations to mitigate. Thank you for summarizing.
The mitigations are there but it takes time for Microsoft's Customers to move to the new versions. I don't think that's Microsoft's problem. That's just their market. I don't think Prof. Green has an understanding of that side of it.
I guess one could argue that Microsoft should backport the new code to older products and give it to Customers who aren't actively paying for maintenance or subscription licensing. They made the business decision not to.
So my understanding is that Wyden's staff has been bothering the company about this class of vulnerabilities for a while, and the recent recommendations (a blog post explicitly cited in my post) are one output of that.
But I don't really accept this explanation. I always understand that there are legacy deployments and Microsoft needs to support them, but Kerberos-misconfiguration issues are extremely subtle in their implications, and MS should understand that one blog post (or some knowledge base articles) isn't going to get the message across to the hundreds/thousands of AD admins whose networks are currently at risk.
What I think recent versions of the MS software could do: (1) automatically scan configurations for accounts set up this way, (2) be incredibly annoying about changing the configuration (there are a handful of ways to do this that should be workable for many legacy configurations). If admins want to override the annoying and explicit warnings, that would be on them and not MS. As far as I can tell, Microsoft isn't doing this. But if I'm wrong, please let me know.
I absolutely agree that Microsoft could do better, but they are making progress in removing support entirely for broken (from a security perspective) older protocols such as NTLMv1 (which uses DES as well: more here -- https://bit.ly/crackingntlmv1) and SMB1.
The financial incentives drive Microsoft to support every possible (mis)configuration, forever. It's the tireless work of a few folk at Microsoft like Ned Pyle, Steve Syfus, and Mark Morowczynski that have landed the changes so far.
There could absolutely be a "security check" tool deployed by default with Server 2025 or similar that looks for Kerberoastable user accounts (any account with a ServicePrincipalName is technically Kerberoastable, like computer accounts), AS-REP roastable accounts, weak encryption types, etc. That would probably get more traction than changing defaults out of the box for everyone, as that's another way to phrase "breaking customer environments when they upgrade".
As an outsider it seems like MS has been much more proactive at moving away from insecure crypto in other places. For example, there was a while where every Windows release would disable some old insecure part of the SMB/CIFS protocol by default while still allowing it to be enabled for backwards compatibility if necessary.
Are they doing the same for AD? From the article it sounds like it falls back to RC4 automatically out of the box. That is something they should have started migrating away from at least a decade ago - gradually, with options for backwards compatibility to support their customers - but the fact that it is enabled by default in 2025 seems insane.
> To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.
I have a vague understanding of Kerberos, and this is where I’m mystified. Why is the KDC or anything else willing to issue a TGS ticket encryption against a service password before the requesting user authorizes themselves? Or is the issue that authentication and authorization are split and the KDC has no idea whether the requesting user is authorized.
The reason that the KDC doesn't decide if the user should get a ticket is that then the power requirements of the DC would be enormous. It should have to know if a user is supposed to have access to every single service in the environment. It would be a massive database. That massive database would also have to sync to all the other DCs. To alleviate this, Kerberos let's the server decide if the user has access, and if so, how much
Kerberos doesn't concern itself with authorization, just authentication. It's up to the app to accept or reject a ticket, and that process is completely opaque to kerberos. It _could_ be extended since Kerberos allows pretty much any damn thing you want to happen with vendor extensions, but I'm not sure that's a situation you want AD to be handling given its track record in the rest of the security space.
> rotated regularly
Is this really a useful mitigation here? If someone has suitable presence to make requests to the TGS, then the time window for cracking and exploiting those tickets (if they are exploitable) is surely always going to be small compared to the rotation window. Hackers don't typically have the patience to sit running hashcat on an old GPU for weeks, they just find some way to get ephemeral access to a bunch of faster GPUs.
Managed and group managed service account passwords are typically 240 characters long and rotate every 30 days. It is highly unlikely that an attacker can crack these.
Fair enough, I guess for some threat actors there is a difference between "uncrackable" and "crackable with more than 30 days effort". But that's a pretty select group of actors.
> This article is somewhat incorrect. Kerberoasting abuses Ticket Granting Service tickets (TGSs...
> TGS are (AES or RC4) encrypted...
What? No. The "TGS" is the "ticket granting service", and it's part of the KDC. A "TGT" is a "ticket granting ticket" -- an object, a blob which is a) a Ticket, b) whose service principal is a TGS principal (meaning of the form krbtgt/TARGET_REALM@ISSUER_REALM).
If in doubt see RFC 4120.
Fine, Kerberoasting abuses TGS-REPs which are colloquially referred to as TGS tickets or TGSs*. You know what I meant.
> TGS-REPs which are colloquially referred to as TGS tickets or TGSs
They are NOT colloquially referred to as such by anyone I know.
A TGS-REP is just a reply from the TGS. A TGS-REP bears a ticket which can be a TGT or not depending on various things.
I have never, ever seen a TGS-REP referred to a you say.
I have heard lots of weird things in the Kerberos space, but not this. E.g., I've see "GSS-API" pronounced as "guhsappi". I've seen people say "give me the Kerberos" (meaning "tell me how to get credentials").
FYI I am a Kerberos implementor/maintainer and have authored several Internet RFCs on Kerberos, and have supported Kerberos deployments at several organizations. Sorry to pull credentials here, but I'm annoyed that you felt the need to correct TFA on something they were not wrong about.
See perhaps "Active Directory Hardening Series - Part 4 – Enforcing AES for Kerberos":
> Identifying devices limited to RC4 is a critical step but has historically been a tricky problem to solve. However, a recently discovered "feature" in 4768 events can help you identity such devices. […] As a result, 4768 events can be used to identify devices that only support RC4.
* https://techcommunity.microsoft.com/blog/coreinfrastructurea...
Also:
> While DES has long been considered insecure, CVE-2022-37966 accelerates the departure of RC4 for the encryption of Kerberos tickets. If you have not explicitly assigned an algorithm to accounts, then AES will be used in the future. You can use PowerShell to determine which accounts are vulnerable to weak encryption.
* https://blog.sonnes.cloud/find-active-directory-accounts-con...
There are certainly disadvantages to legacy support being 'too good'.
I realize I might have been late to the party. As other comments have said, its not as easy as blaming Microsoft, though this is a popular take.
I agree -- Ascension is also complicit in this, and merely paying lip-service to HIPAA. The Senator's letter, on the other hand, paints a one-sided picture of the matter.
Help me out here. I thought I was understanding the process as I went along, but my head is still spinning.
This is what I understood: the corporate network needs to be able to connect ordinary users on some random employee's work computer, to privileged services elsewhere on the (generally insecure) network, securely. The idea is that the server sends the client some kind of encrypted token, the decryption of which — when the system is properly configured — would require some long, random passphrase beyond mortal comprehension. The user's machine stores the passphrase so that secure passphrases can be used by the mere mortal users, and automates the internal connection. But if a user gets compromised from outside the network, an attacker could explicitly request and exfiltrate one of the tokens, and run brute force attacks on it locally to the attacker; and for historical reasons, the system is likely to be poorly configured, such that the necessary passphrase is weak enough to be susceptible to this. Then the attacker uses the decrypted token to escalate access.
My question is: why can't the attacker just direct the compromised machine to connect to the service normally? Or else, where did I lose the plot?
If you have the user's credentials then you can indeed connect to the service as you normally would. The advantages of performing this attack are:
1. You can obtain the service account's password, and the service account may be provisioned with more privileges than the user's account that you compromised. This allows for privilege escalation beyond simply accessing the service. For example, perhaps the service account has administrative access on other machines, or it is used for multiple services, or it is a Domain Admin in which case you can completely compromise the domain.
2. TGS tickets used to request access to a service are cryptographically signed with the password hash of the service account. Services use this to confirm ticket validity. In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users. Instead of accessing the service as a low privilege user, you can now access the service as an Enterprise Admin or another high privilege account which could enable access to more resources or administrative access to the machine. This is called a Silver Ticket attack.
> You can obtain the service account's password, and the service account may be provisioned with more privileges than the user's account that you compromised.
It's wild to me that this could happen just from solving the puzzle that allows the user's account to use the user's privileges (only) on the service... ?
> In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users.
Since it's cryptographic signing, wouldn't this require reversing the hash? Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
> It's wild to me that this could happen just from solving the puzzle that allows the user's account to use the user's privileges (only) on the service... ?
Yes, it is an unfortunate design decision in the Microsoft implementation of the Kerberos protocol.
To interact with Active Directory and perform privileged actions, a service needs an Active Directory account that it can leverage for authenticated actions. This is colloquially referred to as a "service account", but it is not a special account type, it is just a regular Active Directory user or computer account designated for exclusive use by a service. Sometimes administrators will save time by registering a service under their own Domain Admin user account instead of creating a designated account for a service. This effectively makes their user account the service account. In other cases, extensive privileges may be required by a service (e.g. for network access control services, asset discovery services, vulnerability scanners, etc) and administrators find it easier to just create a Domain Admin (high privilege) account for that service than to do fine grained permissioning. This creates a dangerous situation where if an attacker can kerberoast the account associated with the service, they can immediately take possession of a high privilege account that can be used anywhere within the Active Directory environment.
> Since it's cryptographic signing, wouldn't this require reversing the hash?
Yes, you would need to brute-force it.
> Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
Theoretically yes, any valid inverse of the hash would work, but to my knowledge there aren't any hash collisions for the NT hash algorithm. Practically speaking, this means that only the user's password would yield the correct hash.
Thanks, I think I get it now. Everything to do with cryptography always seems to struggle to stick in my head, though, even when I understand the math in principle.
You're missing the forest for the trees. A regular user account should never have a service principal name (SPN), for the simple reason that it can be attacked in the way described. That is why service accounts have really long complex passwords.
Kerberoasting nearly always occurs due to an installation process that assigns an SPN to an account that is performing an installation, or inappropriately selected by the installer. That is the first problem. The second problem is there isn't anyone auditing this stuff because they are incompetent.
If you reported an issue of an account that had an SPN but should not, nearly everyone would either not know what you are talking about, or disagree that it is a security problem without any knowledge or basis.
> That is why service accounts have really long complex passwords.
The sad thing is, they don't always have long complex passwords. They SHOULD, but they don't. Many orgs are scared of changing service account passwords due to the possibility of an outage.
I don't often see a day to day user with an SPN. I do see plenty of SPNs tied to service accounts where the service account password is crackable/Kerberoastable.
From the MS blog post:
>Users with AD credentials can request tickets to any service account in AD.
I assume it means you can derive the service password to leapfrog up the chain to wherever you want to go.
Microsoft is guilty of giving incompetent administrators enough rope to hang themselves.
Microsoft is also guilty of reading the market and keeping up compatibility to make their products remain relevant. Prof. Green makes sweeping statements about how Microsoft should break compatibility to remove these vulnerabilities, but he doesn't have the market pressures that Microsoft does.
Could Microsoft work harder on this? Sure. Do they have to worry about keeping their Customers happy? Absolutely.
The corporate IT market moves at a glacial pace. Hopefully the rise of IT security issues having actual business consequences will change that, but that's not Microsoft's problem. That's the ecosystem they live in.
Were bad protocol / design decisions made in the past? For sure. Microsoft has been working on this (see Managed Service Accounts and Group Managed Service Accounts). It takes time for corporate customers to adopt these new versions.
Corporate IT won't forklift out old systems without business justification. Maybe the pressure from the insurance industry will help. Pressure from the ransomware industry is a certainly helping, too.
Corporate IT just forklifted out tons and tons of workstations and laptops for the windows 10 to 11 migration.
Active Directory is just not developed anymore, its basically abandonware that everyone still uses. The new hot stuff is the Azure AD/Entra ID bastardization of Web Auth plus AD that they try to upsell people to.
Active Directory got some major major major updates in Server 2025.
https://learn.microsoft.com/en-us/windows-server/get-started...
Including the relevant:
> Kerberos changes for Algorithms used for Ticket Granting Tickets: The Kerberos Distribution Center will no longer issue Ticket Granting Tickets using RC4 encryption, such as RC4-HMAC(NT).
Kerberoasting specifically targets service tickets, not TGTs. I wonder if the change really only applies to TGTs or if they simply neglected to mention service tickets.
> Corporate IT just forklifted out tons and tons of workstations and laptops for the windows 10 to 11 migration.
That's just client computer replacement, though. That's a known quantity and is on most IT orgs. roadmaps. We've been replacing computers regularly since we got PCs.
Moving to new AD functional levels, even when the actual risk is minimal, is something I've seen IT orgs. drag their feet on out of fear.
> new AD functional levels
Fear of change is real in more areas than this.
I can't wait to decom our last 2012 R2 DCs and upgrade to something from this decade "soon".
It's still common in IT departments to enter the domain administrator password to join a computer to a domain or install software on a client machine. This seems insane to me, you can just fake the windows gui in a Fullscreen application and keylog the password - even using a web browser. I think AD is a relic of the 90s that should be retired
Kerberoasting keeps popping up in real-world incidents. Do you think enterprises underestimate the human factor in securing service accounts more than the technical exploits?
Padme: AD uses salts in its protocol, right?
In Kerberos, the answer is effectively no. To generate the NT hash, the password is hashed using a single round of MD4. This is what is used to encrypt (and sign) tickets.
The attack is, guess a password, hash it, and attempt to decrypt.
With AES Kerberos keys there is a salt... but not a good one. It is just the domain (realm) and the username.
See also https://blog.compass-security.com/2025/09/taming-the-three-h... for an in-depth video series on Kerberos.
Or the evergreen(?) https://web.mit.edu/kerberos/www/dialogue.html
This makes me so mad. 5he excuses from Microsoft are quite pathetic
Their ubiquitous systems have been notoriously insecure for decades.
They are one of the highest revenue firms on the planet.
It is going to take strict liability for software developers before we all pull up our socks and put an end to this nonsense. When it is a marketing advantage to produce insecure software, what else can fix our industry?
I despair
This makes me so mad. 5he excuses from Microsoft are quite pathetic
Their ubiquitous systems have been notoriously insecure for decades.
They are one of the highest revenue firms on the planet.
It is going to take strict liability for software developers before we all pull up oursocks and put an end to this nonsense. When it is a marketing advantage to produce insecure software, what else can fix our industry?
I despair
A well written, easy to understand article on cryptography that isn’t using unnecessary jargon.
Did he not get the memo that this is not allowed?