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.