Kerberoasting in our AD, how serious is the risk?
Kerberoasting is an attack that cracks Kerberos tickets offline to get service-account passwords. Works mostly on accounts with weak passwords and SPNs. For SMBs with on-prem AD and old service accounts it is a real risk, for cloud-only Microsoft 365 it is not.
Try this first
- 1List service accounts with SPNs: Get-ADUser -Filter {ServicePrincipalName -ne $null} -Properties ServicePrincipalName, PasswordLastSet. Accounts older than two years and not group-managed are the risks.
- 2Rotate service-account passwords to at least 25 random characters, or better: replace with Group Managed Service Accounts (gMSA) that AD itself manages and auto-rotates.
- 3Enable Defender for Identity (formerly ATA) on the domain controllers. It catches kerberoast attempts directly (it can read TGS-REQ patterns).
- 4Restrict which accounts can read SPN attributes. By default any regular user can perform an SPN lookup, that is what makes kerberoasting possible.
- 5Disable RC4 as a Kerberos encryption where possible, force AES. RC4 tickets crack much faster than AES.
When to bring us in
If you have a hybrid setup with legacy applications using password-based SPNs (old SQL Server, old file shares), plan a migration to gMSA. A few days of work, removes the attack vector.
See also
- I think I clicked a phishing linkNo shame, happens to everyone. The next fifteen minutes matter.
- A colleague's account is acting strangelySending mail in their name, rules hiding folders, unusual sign-ins. Suspicious.
- Lost the MFA app: new phone, no backup codesClassic problem after a phone upgrade. You are not the first to be locked out.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.