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.
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.
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.
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.
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.
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.
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".
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.
> 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.
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.
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.
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...