The Theory: Kerberoasting Is a Simple Credential Grab
In cybersecurity training, Kerberoasting is often presented as a straightforward attack. An attacker with any valid user account can request a service ticket for a specific service, like a SQL database. This ticket is encrypted with the service account's
password hash. The attacker takes this ticket offline and uses computing power to 'roast' it—or crack the password. It’s a classic post-exploitation technique used to escalate privileges. In theory, you protect against this by using strong, long, and complex passwords for your service accounts. Simple enough, right? The textbook implies a tidy, preventable problem.
The Reality: Production Environments Are a Mess
In a real production environment, the problem isn’t a handful of service accounts; it’s a sprawling, often undocumented jungle of them. Over years, countless applications, scripts, and services get installed, each creating a Service Principal Name (SPN). Many are set up by developers or system admins with weak, easily guessable, or non-expiring passwords just to get something working. This creates a massive, fertile ground for Kerberoasting that is nearly impossible to audit effectively. The attacker isn't just looking for one known service; they're scanning for thousands of potential weak links. The production challenge isn't just password strength; it's the unmanageable scale and complexity of the attack surface.
The Theory: Golden Tickets Are the Ultimate Prize
A 'Golden Ticket' attack is the stuff of cybersecurity nightmares. If an attacker compromises the master key for the entire domain—the KRBTGT account hash—they can forge a ticket that gives them god-mode access to everything. Its counterpart, the 'Silver Ticket', is less ambitious, targeting the password hash of a single service to grant access to just that resource. In theory, defending against this means protecting your Domain Controllers and the KRBTGT account at all costs. The focus is on preventing that initial, catastrophic breach.
The Reality: It’s About Silent, Long-Term Persistence
In production, the real danger of forged tickets isn’t the initial blast but the stealthy, long-term persistence they enable. An attacker with a Silver Ticket for a file share or database can access it for months without ever needing to interact with the main Domain Controller, making the intrusion incredibly difficult to detect. They blend in with normal network traffic. The theoretical model focuses on the 'how' of creating the ticket; the production reality is about an attacker using it to live inside your network undetected, slowly exfiltrating data or moving laterally. Security teams aren't just looking for a loud explosion; they're hunting for a ghost.
The Theory: Disable Weak Encryption, Problem Solved
Security 101 dictates that you should disable outdated and weak encryption protocols. For Kerberos, that means getting rid of algorithms like RC4, which are significantly easier for attackers to crack offline. In fact, Microsoft began enforcing the move away from RC4 to more modern AES encryption in 2026. The textbook answer is clear: flip the switch and enforce strong encryption across the board.
The Reality: Business Needs and Legacy Tech Tie Your Hands
In the real world, turning off RC4 isn't always an option. A multi-million dollar piece of manufacturing equipment or a critical legacy business application might only know how to speak RC4. The business can't afford the downtime to replace it, so IT is forced to accept the risk. The production environment is a museum of technology, with layers of old systems that must remain operational. This creates a constant tension between security best practices and business continuity. The pitfall isn't the existence of a weak protocol; it's the messy, real-world constraints that force you to keep it active, creating a permanent, known vulnerability that you simply have to live with.
