Kerberoasting in Healthcare Active Directory (AD): What It Is and How to Defend Against It

Kerberoasting is a focused technique for service account credential theft in Microsoft Active Directory. Attackers request service tickets and crack them offline to recover service account passwords, then pivot to sensitive systems holding protected health information (PHI). Understanding the mechanics and building layered defenses are essential Active Directory security best practices for healthcare.

This guide explains how Kerberoasting works, why healthcare environments are attractive targets, and the practical controls you can implement today—from strong password policies and Group Managed Service Accounts (gMSA) to rigorous security event monitoring in healthcare.

Understanding Kerberoasting Attack Mechanics

Why Kerberoasting works

Kerberos issues service tickets (TGS) for accounts that have Service Principal Names (SPNs). The ticket body is protected using Kerberos ticket encryption derived from the service account’s credentials. If that password is human-chosen or weak, an attacker can attempt offline brute-force password attacks against the captured ticket without generating further noise in the domain.

The attacker’s advantage

• No domain admin rights are required to request tickets for SPN-enabled accounts.
• Offline cracking decouples the attack from your monitoring window and throttling controls.
• Once a password is recovered, privilege escalation techniques let the attacker move laterally or elevate rights, especially if the service account has excessive privileges.

Healthcare-specific risk

Hospitals and clinics run numerous services—EHR platforms, imaging (PACS), lab systems, and integration engines—often with long-lived service accounts. If those accounts have weak or shared credentials, Kerberoasting can quickly expose critical platforms and PHI.

Exploiting Service Tickets in Active Directory

High-level attack flow (defender’s view)

• Enumerate SPNs to identify target service accounts.
• Request TGS tickets for those SPNs; the tickets are encrypted with the service account’s key.
• Export tickets and perform offline password guessing until a credential is recovered.
• Use the recovered credential to access the service, harvest more secrets, or escalate privileges.

Common weaknesses that enable success

• Service accounts with short, human-created passwords or reused secrets across systems.
• Legacy or misconfigured encryption settings that permit weaker algorithms.
• Excessive rights on service accounts (e.g., membership in privileged groups or broad local admin).
• Lack of baselined monitoring for unusual volumes or patterns of service ticket requests.

Your defense should aim to make tickets computationally impractical to crack, minimize the blast radius if one account is compromised, and surface anomalous ticket activity quickly.

Implementing Strong Service Account Password Policies

Make cracking infeasible

• Use long, machine-generated passphrases (e.g., 25–32+ characters) for all non-managed service accounts.
• Ensure uniqueness per account and per application; never reuse credentials across services or environments.
• Block dictionary and patterned passwords using a banned password list and password filter.

Harden Kerberos settings

• Prefer modern Kerberos ticket encryption; where possible, disable legacy ciphers and avoid configurations that allow weaker algorithms.
• Avoid disabling preauthentication on any account; that setting enables a different attack (AS-REP roasting).
• Audit and remove SPNs from highly privileged accounts; no Domain Admin or Tier 0 identity should have an SPN.

Operational safeguards

• Disallow interactive logon for service accounts and restrict “log on as a service” to designated hosts only.
• Document each service account’s owner, purpose, SPNs, encryption options, and rotation schedule.
• Test password changes in staging before production to avoid clinical downtime.

Utilizing Managed Service Accounts in Healthcare AD

Why Group Managed Service Accounts (gMSA) matter

gMSA automatically generates long, complex credentials and rotates them on a schedule, eliminating human-created secrets and dramatically reducing service account credential theft risk. They support multiple hosts—ideal for web farms, EHR components, or clustered services common in hospitals.

Benefits you gain

• Automatic rotation (commonly every 30 days by default) without service restarts in many scenarios.
• Strong, non-reusable passwords that are unknown to administrators and never typed.
• Granular control over which hosts can retrieve the managed password.
• Simplified compliance evidence for Active Directory security best practices.

Adoption guidance

• Prioritize high-value SPNs (databases, integration engines, EHR frontends) for early migration.
• Validate vendor support for gMSA; coordinate with clinical application teams for change windows.
• Enable modern encryption for gMSA accounts and remove legacy ciphers from domain policy after testing.

Limiting Service Account Privileges

Apply least privilege relentlessly

• Use dedicated per-application accounts with only the rights the service requires—no interactive logon, no Remote Desktop, no workstation logon.
• Keep service accounts out of global admin groups; avoid local admin unless strictly necessary and scope it to specific hosts.
• Harden delegation: prefer no delegation; if required, use constrained or resource-based constrained delegation with narrow scopes.
• Adopt a tiered administration model to isolate Domain Controllers, identity systems, and clinical servers.

These controls blunt privilege escalation techniques if an attacker ever cracks a single service credential, containing lateral movement and protecting PHI systems.

Monitoring and Detecting Kerberoasting Attempts

What to watch in your SIEM

• Domain Controller Event ID 4769 patterns: unusually high volumes of TGS requests by a single user or host, requests spanning many SPNs, or requests for rarely used SPNs.
• Service ticket requests that negotiate weaker encryption when stronger options are available.
• TGS requests for high-value services (e.g., SQL, EHR, PACS) from nonstandard sources or at atypical times.

Security event monitoring in healthcare

• Baseline normal ticket activity for clinical systems and on-call windows; alert on deviations.
• Correlate 4769 spikes with authentication events, new processes, or suspicious command-line activity on requestor hosts.
• Deploy honey SPNs with long random passwords; any ticket request for them should trigger high-severity alerts.

Triage and response

• Validate whether requests map to sanctioned maintenance or patch cycles; if not, isolate the source host.
• Rotate affected service credentials immediately (or force gMSA rollover) and hunt for lateral movement indicators.
• Review group memberships, delegations, and local admin rights tied to the exposed account.

Rotating Service Account Credentials Regularly

Rotation strategy

• Use gMSA wherever supported; keep the default frequent rotation (commonly 30 days) or shorten for critical services.
• For legacy accounts, rotate at a fixed interval (e.g., 60–90 days) and immediately after any suspected ticket collection.
• Stagger rotations and maintain a tested rollback plan to protect clinical uptime.

Execution essentials

• Centralize ownership and ticketing for rotations; require application owners to sign off after changes.
• Maintain an inventory of all SPNs and dependencies to prevent orphaned credentials and broken integrations.
• After each rotation, verify Kerberos-only operation and review logs for unexpected encryption downgrades.

Conclusion

Kerberoasting preys on weak service account hygiene. By enforcing long, unique passwords, preferring Group Managed Service Accounts, limiting privileges, and investing in precise monitoring and response, you make tickets prohibitively hard to crack and contain the impact of any single credential exposure. These layered controls align to Active Directory security best practices and protect the systems that keep patient care running.

FAQs

What is Kerberoasting in Active Directory?

Kerberoasting is a technique where an attacker requests Kerberos service tickets (for accounts with SPNs), extracts them, and performs offline cracking to recover the service account password. With that credential, the attacker can access services or escalate privileges, often leading to broader compromise.

How can healthcare organizations detect Kerberoasting attempts?

Monitor Domain Controller Event ID 4769 for spikes, unusual requestors, requests targeting many SPNs, and encryption downgrades when stronger algorithms are available. Correlate with process and authentication telemetry on the source host, and deploy honey SPNs to generate high-fidelity alerts specific to Kerberoasting behavior.

What are the best practices for securing service accounts against Kerberoasting?

Use long, random, unique passwords or, preferably, Group Managed Service Accounts (gMSA) with automatic rotation; enable modern Kerberos ticket encryption and retire legacy ciphers; remove excessive privileges and delegation; prohibit interactive logon; inventory and regularly review SPNs; and baseline SIEM detections tailored to your environment.

How often should service account passwords be rotated to prevent attacks?

Adopt gMSA so passwords rotate automatically on a frequent schedule (commonly every 30 days). For legacy, non-managed service accounts, rotate on a defined cadence—typically 60–90 days—and perform immediate rotations after suspected credential exposure or anomalous ticket activity.