![Main article image](


alt="Article illustration 1"
loading="lazy">

) ## Kerberoasting’s Staying Power in the Modern Enterprise Kerberoasting is the sort of attack defenders wish were legacy by now: well-documented, widely taught, and loudly warned about. Yet it remains brutally effective against organizations running Active Directory (AD)—which is to say, most large enterprises. In 2025, the barrier to entry for Kerberoasting is lower than ever, while the blast radius is unchanged: compromise of high-value service accounts, lateral movement, and often full domain compromise. The mechanics haven’t fundamentally changed; what has changed is the scale, automation, and integration of Kerberoasting into broader post-exploitation frameworks. This isn’t a novel zero-day story. It’s worse. It’s the story of how a 20-year-old design reality, plus weak passwords and lax identity governance, continues to give intruders exactly what they need. --- ## How Kerberoasting Really Works (and Why It’s So Attractive) Kerberoasting exploits a legitimate feature of the Kerberos protocol used by AD. No exploit chain, no kernel bug—just protocol semantics and weak secrets. At a high level: 1. **Initial foothold:** An attacker compromises any standard AD user (phishing, malware, token theft, on-path attacks—take your pick). 2. **Service discovery:** Using that legitimate account, they enumerate accounts with a **Service Principal Name (SPN)**—i.e., Kerberos service accounts. 3. **Ticket request:** For each target SPN, they request a Ticket Granting Service (TGS) ticket from the Key Distribution Center (KDC). This is normal Kerberos behavior and, critically, allowed for any authenticated user. 4. **Offline cracking:** The returned TGS ticket is encrypted with the hash of the service account’s password. The attacker saves those tickets and brute-forces them **offline**, at scale, using GPU rigs or distributed cracking. 5. **Privilege escalation:** Once a weak service account password is cracked, the attacker inherits all rights of that account—which often includes broad lateral access and sometimes domain admin or equivalent. The operational elegance is why Kerberoasting is now table stakes in red-team playbooks and criminal toolkits. Tools like **Rubeus** and **GetUserSPNs.py** make: 
GetUserSPNs.py -dc-ip <domain_controller_ip> <domain>/<user>:<password> -request
feel like any other discovery command. No custom implants required, no noisy exploits, just native protocol usage.

Why You’re Not Seeing It: Stealth by Design

Kerberoasting sits in a blind spot that many enterprises still haven’t closed:

  • Legitimate credentials: The attack starts from a real user account, so behavior-based tools tuned for malware often underreact.
  • Native protocol actions: TGS requests are normal Kerberos traffic. High-volume anomalies can be flagged, but targeted requests for a handful of SPNs blend in.
  • Offline cracking: Once tickets are exfiltrated, all heavy lifting occurs off your network. No EDR telemetry. No process tree. No failed login storm.

Defenders who rely purely on antivirus, basic SIEM rules, or malware-focused EDR are playing this game with half a board.

The Real Problem: Service Accounts Frozen in Time

Service accounts sit at the convergence of all the classic security sins:

  • Stale, never-rotated credentials
  • Human-created passwords instead of system-generated secrets
  • Over-privileged roles, often inherited over years of "temporary" exceptions
  • Weak or outdated encryption types like RC4-HMAC still in use for compatibility

For attackers, SPN-enabled accounts are high-value, low-friction targets. For defenders, they are often undocumented dependencies nobody wants to touch in production.

This gap is precisely where Kerberoasting thrives.

A 2025-Grade Defense: Less Folklore, More Engineering

Defending against Kerberoasting is not about a clever signature or a single vendor tool. It’s about engineering identity correctly.

1. Enforce Strong, Non-Human Passwords for SPN Accounts

Every SPN-enabled account should have:

  • Randomly generated passwords of at least 25+ characters
  • No reuse across services or environments
  • Regular rotation tied to automation—not calendar reminders

Long, random, machine-managed secrets directly attack the offline cracking step: if the hash cannot be cracked in a realistic timeframe, the Kerberoast yields nothing.

2. Use Group Managed Service Accounts (gMSAs)

gMSAs exist for this exact class of problems.

  • Passwords are ~120 characters, complex, and automatically managed by AD.
  • Multiple servers/services can share a gMSA securely.
  • No one needs to "know" the password, killing an entire category of insider mismanagement.

For compatible workloads, migrating legacy service accounts to gMSAs is one of the highest-ROI Kerberoasting mitigations.

3. Eliminate Weak Encryption (Stop Accepting RC4)

Accounts that still support RC4 remain prime Kerberoasting targets because the derived keys are easier to brute-force.

Move service accounts to AES-based encryption (AES128/256) and disable RC4 where operationally feasible. This is not security theater; it materially changes the cost of cracking tickets.

4. Continuous Password Intelligence, Not One-Off Audits

Static policy like "12 characters + complexity" is obsolete when attackers are armed with massive breached password corpora and GPU farms.

Modern defense means:

  • Checking passwords against large compromised password datasets
  • Flagging blank, identical, or never-expiring passwords
  • Identifying stale privileged accounts that no longer map to real services

![Breached passwords](


alt="Article illustration 2"
loading="lazy">

)

Sponsored tooling like Specops Password Auditor (as cited in the source) reflects this direction: enumerate password weaknesses, cross-reference with known-compromised sets, and show exactly where attackers will start. While vendor-specific, the underlying approach is now table stakes for any serious AD shop.

5. Monitor for Abnormal TGS Request Patterns

Even though Kerberoasting abuses normal mechanisms, you can still raise friction:

  • Alert on high volumes of TGS-REQs for SPN accounts from a single user or host.
  • Flag requests for sensitive SPNs (e.g., SQL, LDAP, key line-of-business apps) coming from unusual segments.
  • Correlate TGS activity with other signals: new processes, PowerShell usage, suspicious logons.

This won’t stop a careful, low-and-slow operator alone, but it turns “undetectable by design” into “detectable with intent.”

6. Assume the First Hop Is a Normal User

Kerberoasting starts from a compromised standard user, so hardening only admin accounts is incomplete.

Core practices that shrink the initial foothold window:

  • Enforce long, unique passwords plus multi-factor authentication (MFA) where possible
  • Reduce local admin rights
  • Aggressively filter phishing and harden macro and script execution paths
  • Apply tiered admin models to separate everyday users from privileged contexts

This isn’t cosmetic; preventing the first foothold directly reduces your Kerberoasting exposure.

Turning a Known Weakness into an Architecture Test

![Kerberoasting defenses](


alt="Article illustration 3"
loading="lazy">

)

Kerberoasting persists in 2025 not because it’s clever, but because it’s honest: it shows you exactly where your identity architecture is weakest.

If an attacker can:

  • Enumerate SPNs freely,
  • Request tickets without constraint,
  • Crack them because passwords are short, reused, or RC4-backed,
  • And pivot to critical services from a single compromised user,

then the problem isn’t just Kerberos. It’s how your organization treats identity as configuration, not as infrastructure.

Use Kerberoasting as a forcing function:

  • Inventory every SPN-enabled account.
  • Migrate what you can to gMSAs.
  • Mandate long, random, rotated secrets for everything else.
  • Strip RC4 support. Enforce AES.
  • Continuously screen against breached passwords and weak policy.
  • Instrument your logs so unusual TGS activity is an investigation, not a footnote.

The original source article, “Kerberoasting in 2025: How to protect your service accounts” (BleepingComputer, sponsored by Specops Software), underscores a vendor solution to these challenges. The strategic takeaway for security and infrastructure leaders is broader: Kerberoasting is no longer an edge-case red-team trick. It’s a litmus test of whether your AD environment reflects 2025-level identity security—or 2005.