From Heuristics to Histograms: Reinventing Kerberoasting Detections
Jul 23, 2025
This blog explores the basics of a Kerberoasting attack, the limitations of traditional Kerberoasting detection methods, and walks through why our data modeling approach is able to surface the hidden threats traditional defenses miss.
Authors:
Cole Sodja
Security Statistician Contractor
Christopher Calvani | @nulvox
Security Researcher
Phantom Labs™
BeyondTrust
From Heuristics to Histograms: Reinventing Kerberoasting Detections
Cole Sodja
Security Statistician Contractor
Christopher Calvani | @nulvox
Security Researcher
Phantom Labs™
BeyondTrust
How to Uncover Even The Stealthiest Of Kerberoasting Attacks
Link copied
Every Active Directory environment has blind spots, which Kerberoasting expertly exploits. Silent, subtle, and persistent, this threat often goes unnoticed until significant damage occurs. Traditional defenses rely on brittle heuristics, such as one-size-fits-all thresholds that ignore behavioral differences between accounts. These thresholds are typically based on static baselines and generic anomaly-detection models, which often fail to detect attacks due to the highly variable nature of Kerberos traffic. Both of these approaches result in a large number of false positives while outright missing "low-and-slow" attacks.
By combining security research with data science, BeyondTrust developed a model that learns each account's typical ticket-request frequency and flags deviations from that norm. The result is a lightweight detection capability that can uncover even the stealthiest Kerberoasting attacks.
This blog explores the basics of a Kerberoasting attack, the limitations of traditional Kerberoasting detection methods, and walks through why our data modeling approach is able to surface the hidden threats traditional defenses miss.
What is Kerberoasting?
Link copied
Kerberoasting is a post-exploitation technique that targets Windows Active Directory environments. This technique allows an attacker with a compromised low-privileged domain user account to obtain service account credentials. This is achieved by requesting service tickets, specifically Ticket Granting Service tickets, from the Active Directory domain controller. The attacker then attempts to crack these tickets offline to recover the plaintext passwords of the requested service accounts. This attack is highly effective because it doesn’t require administrative privileges and the password cracking process occurs entirely offline.
What is Kerberos Authentication?
Kerberos is a network authentication protocol that uses tickets to securely verify the identity of users and provide access to services. Understanding how this process works is essential to grasp the impact of a Kerberoasting attack.
The following steps outline the Kerberos authentication process:
AS-REQ: A user logs in and requests a Ticket Granting Ticket (TGT).
AS-REP: The Authentication Server verifies the user's credentials and issues a TGT.
TGS-REQ: When the user wishes to access a network service, they request a Ticket Granting Service Ticket (TGS) using their previously received TGT.
TGS-REP: The TGS verifies the request and issues a TGS, which is encrypted using the password hash of the service account associated with the requested service.
KRB-AP-REQ: In order for the user to authenticate against a service using the TGS ticket, they send it to the application server.
KERB-VERIFY-PAC: The application server now takes the received TGS from the user and verifies the user permissions with the Key Distribution Center (KDC).
PAC-VERIFY-REP: The KDC validates the Privilege Attribute Certificate (PAC) and sends a response back to the application server, confirming that the user's PAC is legitimate.
KRB-AP-REP: The application server responds to the user, completing mutual authentication and granting access to the requested service.
Figure 1: Diagram of Kerberos authentication
While steps 6–8 are part of the complete Kerberos flow, they are not required for the user to gain access to the application server. Whether these steps are enforced depends on the application server’s implementation, which is why they are rarely used in practice.
How Does Kerberoasting Work?
Kerberoasting works when an attacker can exploit encrypted service tickets hashed with the service account's password. A Service Principal Name (SPN) is a unique identifier that maps an Active Directory (AD) account to a specific service instance. It is important to note that only user accounts associated with an SPN can be targeted in these types of attacks. If an attacker obtains a service ticket for such an account, they can then attempt a brute-force or dictionary attack to recover the plaintext password of the account. While both users and computers can have SPNs, computer passwords are typically long, randomly generated, and extremely complex, which can make them nearly impossible to crack. When a client requests a service, Kerberos uses the SPN to identify the associated account and issues a ticket encrypted with that account’s password hash.
A Kerberoasting attack commonly follows these steps:
Gain initial access: An attacker first obtains access to the Active Directory domain through a valid user account.
Enumerate Kerberos Service Principal Names: The attacker leverages Lightweight Directory Access Protocol (LDAP) to query the directory for Active Directory accounts that have associated SPNs. These SPNs indicate that the account is tied to a service.
Request service tickets for identified SPNs: The attacker then requests TGS tickets for the SPNs found. Note: Windows does not require elevated privileges to request these tickets.
Extract and save the tickets: The attacker extracts the TGS tickets from packet captures and saves them for offline analysis.
Offline brute-forcing of the tickets: Extracted tickets can be cracked offline using tools such as Hashcat or JohnTheRipper.
The Importance of Kerberos Service Ticket Telemetry
Link copied
What Is Windows Event 4769?
Windows Event ID 4769 is a critical Windows security event log that captures each time a principle requests a TGS ticket within an Active Directory environment. Since Kerberoasting attacks specifically rely on requesting TGS tickets, monitoring this event is crucial for effective detection.
Note: Microsoft released an update to Event ID 4769 that adds several event fields. We focused on the old event schema to account for customers that haven’t applied the latest Security Cumulative Update.
Key Event Attributes:
Service Name: The name of the account that is associated with the SPN being requested. Many tickets will be requested by the KRBTGT service and built-in machine accounts. These accounts typically have extremely long and randomized passwords, making them ineffective targets for attackers.
Target User Name: The name of the account that initiates the TGS ticket request.
Ticket Encryption Type: The encryption type used for the TGS ticket. In many Kerberoasting scenarios, the attacker can downgrade the encryption type to make it easier to crack the ticket offline. Although AES is the default encryption standard for these transactions, RC4 and DES can still be used if not properly configured.
Status: This field shows whether or not the request was completed.
Using Windows Event 4769 to Analyze Request Count Statistics and Example Plots
Our analysis, conducted over three months across multiple enterprise Active Directory environments, revealed distinct patterns. Typically, user accounts requested Kerberos service tickets infrequently, and when they did, involved very few distinct services.
An analysis of 50,000 Active Directory accounts revealed that over 70% showed minimal Kerberos activity, generating service ticket requests less than 1% of the time during that period. Among these low-activity accounts, more than 99.5% accessed five or fewer distinct services per hour during their active periods. See Figure 2 below for a visualization of this behavior as a time series.
Figure 2: Chart showing the different services accessed by a typical Active Directory account every hour over five days, based on Event ID 4769 logs
While the majority of user accounts analyzed exhibited highly infrequent and very low request counts, the BeyondTrust Research and Data Science team identified several accounts that displayed different behaviors, including very frequent requests with greater variance or rarer extremes. Figures 3 and 4 below illustrate several examples of these anomalous patterns.
Figure 3: Chart showing the different services accessed by a high-activity Active Directory account every hour over five days, based on Event ID 4769 logs
Figure 4: Chart showing the different services accessed by an Active Directory account with unusual spikes in Kerberos ticket requests every hour over a 20-day period, based on Event ID 4769 logs
To effectively detect security threats through Kerberos monitoring, security teams must first establish a baseline of normal user behavior patterns. Some user accounts naturally exhibit unpredictable activity; they may remain inactive for long periods before suddenly generating a high volume of authentication requests. This irregular “bursty” behavior is often legitimate and follows statistical patterns where most activity is low-level with occasional spikes.
Methods For Kerberoasting Detection Using Windows Event 4769
Link copied
Common Heuristics-Based Kerberoasting Detection Methods
Typical heuristic-based detection methods rely on static rules, such as:
Volume-based detection: When an attack is performed, the attacker often requests TGS tickets for all service principal names associated with users in the domain. This will show a spike of TGS request activity from an account.
Encryption type analysis: An attacker performing a Kerberoasting attack will often attempt to downgrade the encryption of requested tickets from AES to weaker supported encryption types, such as RC4 or DES. This allows an attacker to crack the hashes and easily obtain the plaintext passwords.
While these static rules can offer some detection capabilities, they come with significant limitations, such as a high false positive rate. Static detection methods also fail to account for legitimate user behavior or evolving anomalies over time. Furthermore, their efficiency can vary across organizations based on the domain configurations and associated services.
Statistical and Machine Learning Kerberoasting Detection Methods
Some other approaches for detecting Kerberoasting include:
Supervised/Semi-supervised machine learning: This approach requires having enough (often at least a couple hundred) defined labels of past Kerberoasting attacks, a set of potential signals (or so-called features), and selecting an algorithm (there are many choices) to learn how to discriminate between labeled data points based on a defined metric.
Unsupervised machine learning: Unlike supervised methods, this approach does not require pre-labeled data. Instead, it focuses on describing patterns within a set of signals, such as identifying groups (or clusters) based on a defined metric, or quantifying deviations (or anomalies) from normal behavior.
Statistical modeling: This method aims to estimate a probability distribution given the available data, which can be labels, signals, or a combination of both.
Given our lack of prior Kerberoasting labels, supervised/semi-supervised learning was not feasible, nor was it aligned with our goal of identifying unusual or unknown behaviors within Event ID 4769 events that could signal such attacks. Thus, looking at the problem as anomaly detection, specifically building an automated and adaptive way of baselining and thresholding counts, became a natural progression from heuristic methods. Following our method analysis, the next critical decision was to determine the optimal modeling approach to accurately represent the statistical properties of our dataset.
While prior literature discusses the precision of certain common unsupervised learning algorithms for Kerberoasting, these types of “off-the-shelf" ML methods proved ineffective in addressing our top four constraints:
Explainability: The ability to interpret the output with respect to a recognized, normalized, and easy to explain and track measure.
Uncertainty: The ability to reflect sample size and confidence in estimates, as opposed to the output being a simple binary indicator.
Scalability: The ability to limit the amount of cloud computing and data storage needed for updating model parameters per run.
Nonstationarity: The capacity to adapt to trends or other data changes over time, and incorporating these shifts into how anomalies are defined.
Ultimately, we focused on statistical models and developed logic to balance precision requirements with the above constraints. The next section summarizes our model.
BeyondTrust’s Statistical Model for Kerberoasting Detection
Link copied
Modeling Real-World Ticket Request Patterns
Our approach to detecting Kerberoasting leverages a robust statistical framework designed to address the complexities of count data. It involves using a discrete probability model capable of addressing several challenges simultaneously, such as zero/one inflation (due to rare activity), multi-modal skewed distributions (resulting from highly variable frequency patterns), and the need to appropriately weight recent observations while discounting historical data that no longer represented current behavior patterns. Additionally, the model efficiently identifies latent clusters to refine probability estimates for infrequently active accounts that nonetheless exhibited heavy-tailed distributions.
Balancing Statistical and Practical Significance
Our methodology incorporates both statistical significance and practical significance thresholds to optimize computational resources and prioritize investigative efforts. We implemented normalized parameters to calibrate detection sensitivity based on the organizational context. For instance, in smaller enterprises, while two Kerberos service ticket requests might be statistically anomalous and four exceedingly rare, a difference of merely two units might not warrant investigative resources. Conversely, in large enterprise environments where some accounts routinely generate hundreds of ticket requests, novel activity exceeding historical patterns by 20 units but representing only a 1.1x relative increase, might fall within acceptable variance parameters and not require escalation.
Efficient Data Extraction and Processing
Scale and performance considerations guided our data extraction approach for model estimation. BeyondTrust Data Scientists carefully calibrated the amount of historical data processed during each run, balancing the need for statistical accuracy with computational efficiency in the production environment.
Dynamic Updates and Censoring for Accuracy
Our model architecture employs a sequential approach to data processing, updating parameters with each new timestamp to address the specified requirements. We implemented count censoring to filter out values below certain thresholds, which serves two important purposes: reducing computational overhead and preventing statistically rare but practically insignificant small counts from disproportionately influencing the results. This censoring mechanism is directly integrated into the probability estimations, ensuring statistical consistency throughout the modeling process.
Handling Nonstationary Behavior with Sliding Windows
Our model incorporates dynamic sliding windows to address the nonstationarity problem we discussed above. This approach balances recent frequency changes with the ability to capture infrequent extreme events that might only occur every few months for certain accounts.
Using Percentiles for Detection Control
We used high percentile statistics (P90, P95, up to P999) as our main control mechanism for the model. These percentiles helped us with three key tasks: grouping similar counts, setting decision thresholds, and interpreting results. For example, when we wanted to limit anomaly alerts to just three per month (assuming 20 operating hours per day), we chose the 99.5th percentile (P995) as our risk measurement, demonstrating why statistical modeling works so well for this problem type.
The Histogram Approach to Classic Distributions
Instead of relying on traditional statistical distributions like the negative binomial—which can yield misleading results (such as unrealistically small p-values)—we chose a simpler histogram method. We determined the histogram bin sizes using those same upper percentile thresholds. This approach led to the creation of what we call a 'sliding-window censored clustering q-statistics histogram', which is essentially a dynamic method for organizing and analyzing our data that adjusts over time.
How the Histogram Clustering Method Works
Link copied
Here’s a simplified explanation of how our histogram method works:
Setting Up Histogram Clusters:
Imagine we have three data time series counts: Z1(t), Z2(t), and Z3(t), each representing an account’s Kerberos service ticket request patterns over time. Our goal is to group these into two clusters. To achieve this, we use a set of rules: data points are considered “similar enough” to belong to the same cluster if they are within a single q-statistic of 0.95, with a 1.3x ratio, and show a 3-unit difference.
Clustering Results:
Z1 forms Cluster 1 because its upper quantiles do not meet similarity criteria with the others (Z2 or Z3).
Figure 5: Z1 time series & Cluster 1
Z2 and Z3 form Cluster 2 because their P95 values are within our defined thresholds—their behavioral patterns are close enough to be considered part of the same group.
Figure 6: Z2 and Z3 form Cluster 2
The Impact of Anomaly Scoring: Detecting Real vs. False Anomalies
Our scoring function is as follows: log10(1+probability(t)*q-ratio(t))*qthresh*rel_rank(t)
With Clustering: No anomalies detected (Z2 and Z3 represent normal organizational behavior within their cluster)
Without Clustering: Both Z2 and Z3 flagged as suspicious (quantile distances of ~1.6x ratio and 4 units difference exceed thresholds)
By grouping similar time series together, our model learns what "normal" looks like for each cluster. This dramatically reduces false alarms, as activity that might appear suspicious in isolation becomes perfectly normal when compared to similar data patterns.
Scoring Function Variable Reference
Link copied
rel_rank(t): Binary flag (1/0) when percentile ranking exceeds q-level threshold
qthresh: Binary flag (1/0) when q-statistics exceed threshold
Results of Our Kerberoasting Research
Link copied
We evaluated our model’s precision and computational efficiency using 50 days of data, performing hourly computations on the Databricks platform. The following results highlight our findings across several key dimensions.
1. Model Performance and Efficiency
After cluster initialization and retrieving Kerberos service ticket request data via Spark SQL, the model consistently processed histogram updates, clustering operations, score calculations, percentile ranking, and result storage in under 30 seconds.
2. Anomaly Detection Outcomes
Throughout the 1,200 hourly evaluation periods, our model identified six candidate anomalies that met our specified criteria: a 99.5th percentile threshold, a minimum q-ratio of 1.5X, and a minimum q-difference of 3 (as illustrated below in Figure 7). The detected anomalies exhibited several notable temporal patterns, including uncorrelated spikes in narrow time windows, increased variance, and significant temporary shifts in activity.
Of the six identified anomalies (including one account flagged in two consecutive hours), three satisfied our additional criterion requiring multiple distinct service name types. Two of these represented penetration tests, while the third corresponded to our simulated Kerberoasting attack.
Investigation of the remaining three anomalies revealed that these events coincided with temporary surges in service ticket requests triggered by large Active Directory changes. These changes briefly exceeded both account-level and enterprise baselines.
Notably, candidate six warranted further examination from an identity management perspective. This investigation revealed an enterprise configuration change that inadvertently caused the account to request tickets for all SQL services simultaneously instead of only the intended subset.
Figure 7: Hourly counts of distinct service names for event 4769 for six distinct users with identified anomalies
4. Adapting to Outliers with Dynamic Down-Weighting
Since our model dynamically updates the sliding window used to compute probabilities per cluster and maintains an enterprise-level updated percent ranking of the anomalies scores over time, it only took up to two consecutive occurrences for the model to appropriately down-weight the scores for a very heavy-tailed account. Most standard anomaly detection methods would have taken much longer (or require a lot more complexity) to handle this type of nonstationarity in extremes.
5. Enhancing Precision Through Contextual Filtering
Our findings highlight the inherent limitations of pure anomaly detection methodologies. Statistical rarity alone doesn’t always indicate a security threat. Effective threat detection requires contextual filtering to focus on scenarios with genuine security implications. In our implementation, we enhanced precision by excluding system accounts, filtering out predictable periodic patterns (e.g. consistent hourly spikes occurring at regular intervals), and specifically targeting user accounts requesting multiple service types with weak encryption characteristics. This targeted approach significantly improved the signal-to-noise ratio of our detection capabilities.
Conclusion: Statistical Modeling Significantly Improves the Accuracy of Kerberoasting Detection
Link copied
Detecting Kerberoasting attacks poses a significant challenge in Active Directory environments because they have the ability to blend in with legitimate Kerberos traffic. BeyondTrust’s research has demonstrated that moving from traditional heuristic approaches to statistical modeling significantly improves detection capabilities while reducing false positives.
Through our collaborative approach, we have successfully combined security domain expertise with advanced statistical techniques. As researchers, we were able to provide the critical context needed to pinpoint meaningful features within relevant events. Concurrently, our statisticians developed a robust model capable of adapting to the evolving behaviors observed across many different environments. By integrating these two disciplines, we were able to develop a detection capability that can identify both known attack patterns and potential variations.
The results speak for themselves. Our model was able to efficiently process large volumes of Kerberos event data and correctly identify simulated attack scenarios while generating extremely few false positives. The model’s ability to adapt to enterprise-specific behaviors and dynamically update its baseline understanding offers a distinct advantage over static, rule-based detection methods.
About the Author
Link copied
Cole Sodja
Security Statistician Contractor
Cole Sodja is a Security Statistician Contractor for BeyondTrust, bringing over 20 years of applied statistics experience across major technology companies, including Amazon, Microsoft, and Securonix. He specializes in time series analysis and what he describes as “probabilistic threat hunting and intelligence”—profiling entities, combining signals and anomalies, and producing rankings to uncover meaningful security incidents. Cole brings deep expertise in forecasting, changepoint detection, and behavioral monitoring to tackle complex business challenges and enhance BeyondTrust's anomaly detection capabilities.
Christopher Calvani | @nulvox
Security Researcher
Christopher Calvani is a Security Researcher on BeyondTrust’s research team, where he blends vulnerability research with detection engineering to help customers stay ahead of emerging threats. A recent graduate of the Rochester Institute of Technology with a Bachelor of Science in Cybersecurity, Christopher previously supported large‑scale infrastructure at Fidelity Investments as a Systems Engineer intern and advanced DevSecOps practices at Stavvy.
Phantom Labs™
BeyondTrust
BeyondTrust Phantom Labs™ believes the best way to fully understand cybersecurity threats is to work closely with our customers and partners, conducting real world research into the attacks that matter most to them. By dissecting emerging attack methods and exploitation techniques of threat actors, as well as conducting novel research, the team’s mission is to help organizations defend against identity threats.