15. 12. 2025 Daniel Degasperi Blue Team, Log-SIEM, SEC4U

Hunting Silent Kerberoasting: Detecting RC4 TGS Floods with Elastic

Introduction

Kerberoasting remains one of the most popular techniques for attackers attempting to escalate privileges inside a Windows domain. By requesting service tickets (TGS – Ticket Granting Service) encrypted with weak algorithms an attacker can extract hashes and crack them offline to recover service account passwords.

It should be mentioned that the Kerberos ticket request is an absolutely normal and very frequent action in the Windows environment.
It is therefore obvious that a signature matching approach (evaluate the individual event/request) cannot be used to detect such situations, but rather a bahavior-based detection can be used.

This article presents an advanced Elastic detection rule designed to identify suspicious bursts of RC4-encrypted TGS requests, a strong indicator of Kerberoasting activity.

Why RC4 Still Matters

Even tough Microsoft has encouraged the adoption of stronger cryptography within Active Directory, many legacy environment stil support RC4 for Kerberos tickets, instead of more secure AES128 (0x11) and AES256 (0x12).

Attackers actively search for RC4 enabled SPNs (Service principal names) primarily because these ticket hashes are fast and cheap to decrypt offline. In addition, many service accounts have weak or reused password.

These service accounts can also be very dangerous because they often have high privileges and provide a real chance for lateral movement.

Therefore, early detection of RC4-based Kerberoasting is crucial to prevent attackers from obtaining (potential) powerful service credentials.

Kerberoasting Attack Flow

          [ Attacker Host ]
                  |
                  v
      Enumerates SPNs in the domain
                  |
                  v
         Requests RC4 TGS Tickets
           (Event ID 4769)
                  |
        +----------------------+
        |   Domain Controller  |
        |  Kerberos Service    |
        +----------------------+
                  |
        Returns RC4-Encrypted
         Service Tickets (TGS)
                  |
                  v
        [ Attacker Host ]
   Extracts Ticket Hash Offline
                  |
                  v
        Attempts Password Crack
         (Kerberoasting Phase)

This flow shows why monitoring RC4-encrypted TGS requests is crucial:

an authenticated user requires a Ticket Granting Service (TGS) to access a service (e.g., SQL Server)
the TGS contains the service key encrypted with the service account password
the attacker captures this ticket and exports it offline
the attacker then attempts a brute-force or dictionary attack to decrypt the service account password

Detection Logic

This Elastic query focuses on identifying multiple distinct RC4-encrypted TGS requests within a short time window (5 minutes), performed by the same user and same machine. This pattern is highly indicative of automated SPN enumeration tools such as PowerView, Rubeus or Impacket.

Key behaviors detected:

Event ID 4769 – Kerberos Service Ticket Request
Status 0x0 – successful TGS request
TicketEncryptionType 0x17 – RC4 encryption
Excludes krbtgt and machine accounts
Report if more than 5 different SPNs are requested by the same user and source IP in 5 minutes

Detection Query (Elastic)

from logs-system.security*
| eval time_win = DATE_TRUNC(5 minutes,@timestamp) /* considering 5m */
| mv_expand event.category
| where event.category=="authentication" 
    and winlog.event_id=="4769" 
    /* only success code*/
    and winlog.event_data.Status=="0x0"
    /* RC4 encryption type, this allows to crack the password. */
    and winlog.event_data.TicketEncryptionType=="0x17" 
    /* Ignore requests from service names that end with $ which are associated with genuine kerberos traffic */
    /* Ignore requests for the krbtgt service */
    and not (winlog.event_data.ServiceName like "*krbtgt" or winlog.event_data.ServiceName like "*$") 
    /* Ignore requests from machines */
    and not winlog.event_data.TargetUserName like "*$@*"
| stats 
    unique_sevice = COUNT_DISTINCT(winlog.event_data.ServiceName),
    service_values = VALUES(winlog.event_data.ServiceName)
 by winlog.event_data.TargetUserName, source.ip, time_win
| where unique_sevice > 5

Focus on Kerberos TGS requests
Event 4769 – “A Kerberos service ticket was requested”. This is the core event for monitoring service ticket operations.

Detect weak cryptography (RC4)
RC4 (0x17) is still the most crackable algorithm, the attacker’s first choice.

Exclude legitimate background noise
The rule filters out:
– KRBTGT account related traffic
– Machine accounts (*$)
– Service accounts ending in $
This drastically reduces false positives.

Identify multi-SPN requests
Kerberoasting tools enumerate several SPNs quickly to maximize cracking opportunities.
In our case, more than 5 unique SPNs in 5 minutes is an effective anomaly signal.

Optional Enhancements for Further Noise Reduction

Accuracy could be increased by filtering Forwardable or Renewable Kerberos tickets. It is clear that these tickets are the most attractive to an attacker because of their potential use in lateral movement and privilege escalation.

winlog.event_data.TicketOptions in ("0x40810000","0x40810010", "0x60810010")

From Microsoft documentation:

0x40810010 – Forwardable, Renewable, Canonicalize, Renewable-ok

0x40810000 – Forwardable, Renewable, Canonicalize

0x60810010 – Forwardable, Forwarded, Renewable, Canonicalize, Renewable-ok

This condition can help focus on tickets designed to persist across sessions and renewable tickets with a long duration.

Why This Detection Is Effective

Behavior-based rather than signature-based; several related events instead of one timely event.
Very low false positives.
Detects credential login attempts at an early stage.
Works even in legacy or hybrid AD environments.

Hardening Recommendations Against Kerberoasting

Detection is certainly crucial, but some targeted hardening measures can greatly reduce the success of Kerberoasting attempts.

Use strong passwords for service accounts
Service account passwords are often weak. Use long, random passwords and rotate them regularly. Prefer MSA/gMSA where possible.

Reduce or remove RC4 support
RC4 (0x17) encryption is the attacker’s preferred target.

Identify accounts that still support RC4 encryption.
Switch those accounts to AES128 or AES256 algorithms.
Completely disable RC4 throughout the domain when compatibility allows.

These individual steps dramatically reduce exposure to Kerberoasting.

Minimize Service Account Privileges
Implement the principle of least privilege to minimize the risk of lateral movement if an account is compromised.

Remove unused (stale) SPNs
Even if the service no longer exists, the ticket can still be request, and the account cracked.

Here a complete Microsoft’s guide.