Caster - Parallax

Genre: Defensive
Label: caster0x00.com
Release Date: 21 October 2025
Language: English
Length: 10476 Words
Reading Time: 39 Minutes

Performed by: Caster
Written by: Mahama Bazarov
Cover Man: Mahama Bazarov (Sony ILCE-7M3, f/5.6, 1/3 sec)

Intro

Kerberos - is a network authentication protocol used in various network infrastructures, including Active Directory networks. It is based on symmetric key cryptography and a centralized trust model, where the key element is the Key Distribution Center (KDC)
The KDC is responsible for issuing tickets that confirm the user's authenticity and allow them to access network services without re-entering their credentials.

Kerberos operation consists of two main parts:

• Authentication Service (AS) - issues an initial ticket to the client, which confirms its identity;
• Ticket Granting Service (TGS) - issues service tickets for access to specific resources in the infrastructure.

Typically, the client first requests an AS-REQ (Authentication Service Request), receives an AS-REP (Authentication Service Reply) with a TGT ticket, and then uses this ticket to request a TGS-REQ and receive a TGS-REP from the KDC.
The authentication process is entirely based on the exchange of ASN.1 messages, and Kerberos uses TCP/88 and UDP/88.

The purpose of the research

The purpose of this paper is to demonstrate how attacks on Kerberos can be detected at the network traffic level using IDS signatures (Suricata)
However, most Kerberos research focuses on offline analysis or Windows event logs, but it is the network level that allows attacks to be detected in real time, even before domain credentials are compromised.

This research proves that Kerberos attacks can be detected purely from network telemetry without relying on host logs.

Kerberos is under attack

The entire Active Directory infrastructure depends directly on Kerberos. Every login, every request to SMB, LDAP, or HTTP services within the domain is Kerberos traffic.
This is why Kerberos is one of the main targets for attackers: compromising tickets or credentials within the protocol allows access to domain services without knowing the passwords.

Common attacks targeting Kerberos:

Kerberos Users Enumeration

This is a method of searching for valid accounts in an Active Directory domain by sending mass AS-REQ requests to the KDC in order to obtain distinguishable behavior for existing and non-existing names. Here, the attacker's task is to collect a list of valid logins before launching a further attack.

It is important to understand:

• KDC responds differently depending on the status of the account and its settings;
• KDC responses (or no responses) let you tell real accounts from fake ones and find target service principal names (SPNs) for Kerberoasting.

Example

To enumerate users, an attacker can use kerbrute:

caster@kali:/mnt/hgfs/ID$ ./kerbrute userenum --dc core.myownsummer.org -d myownsummer.org possibleusernames.txt            

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

Version: dev (9cfb81e) - 10/19/25 - Ronnie Flathers @ropnop

2025/10/19 16:43:23 >  Using KDC(s):
2025/10/19 16:43:23 >  	core.myownsummer.org:88

2025/10/19 16:43:24 >  [+] VALID USERNAME:	 sspeed@myownsummer.org
2025/10/19 16:43:24 >  [+] VALID USERNAME:	 kestre@myownsummer.org
2025/10/19 16:43:24 >  [+] VALID USERNAME:	 svettel@myownsummer.org
2025/10/19 16:43:24 >  [+] VALID USERNAME:	 rkubica@myownsummer.org
2025/10/19 16:43:25 >  Done! Tested 102 usernames (4 valid) in 1.128 seconds

To enumerate users, kerbrute sends AS-REQ without a pre-authentication:

• If the KDC responds with a PRINCIPAL UNKNOWN error, it means that the account does not exist;
• If the KDC requires pre-authentication PREAUTH_REQUIRED, it means that the name exists.

This method does not cause login errors or account lockouts.
However, when Kerberos auditing is enabled on the domain controller, a Windows Event ID 4768 event is generated.

When kerbrute performs user bruteforce attacks, it sends a minimalistic AS-REQ without a pre-authentication block.
Now let's see how this attack looks in traffic:

a1 03 02 01 05     // ASN.1: [1] INTEGER 5  → pvno = 5 (Kerberos Version)
a2 03 02 01 0a     // ASN.1: [2] INTEGER 10 → msg-type = 10 (AS-REQ)
6b 72 62 74 67 74  // ASCII: "krbtgt"     → service name (TGT)

These values only appear in Kerberos AS-REQs, especially those directed at krbtgt:

• a1 03 02 01 05 and a2 03 02 01 0a are byte sequences in all AS-REQs. They can be used as a primary signature sign;
• 6b 72 62 74 67 74 is the ASCII string krbtgt, which is common to all TGT requests, making it perfect for use in fast_pattern.

Behavior in traffic

Enumeration and bruteforce tools work very quickly, generating tens or hundreds of AS-REQs per second. For this reason, signatures should be based not only on byte fingerprints, but also on source behavior - which is why signatures should use parameters such as threshold.

Signature

Signature for detecting enumeration will look as follows:

alert udp any any -> any 88 (
  msg:"[UDP] High Rate of Kerberos AS-REQ, Possible Enumeration";
  content:"|a1 03 02 01 05 a2 03 02 01 0a|";
  content:"|6b 72 62 74 67 74|";
  fast_pattern;
  threshold:type limit, track by_src, count 5, seconds 10;
  sid:100000;
  rev:1;
)

alert tcp any any -> any 88 (
  msg:"[TCP] High Rate of Kerberos AS-REQ, Possible Enumeration";
  content:"|a1 03 02 01 05 a2 03 02 01 0a|";
  content:"|6b 72 62 74 67 74|";
  fast_pattern;
  threshold:type limit, track by_src, count 5, seconds 10;
  sid:100001;
  rev:1;
)

Both signatures are provided for TCP and UDP. Kerberos uses TCP when transferring large amounts of data.

In these signatures:

alert - indicates that an alert will be generated when the rule is triggered;
udp - indicates that the rule applies to UDP traffic;
any any -> any 88 - the rule will apply to any source IP address and port and any target IP address on port 88, which is the default port for Kerberos;
msg:"[UDP] High Rate of Kerberos AS-REQ, Possible Enumeration" - a message when a rule is triggered. Indicates a high frequency of AS-REQ requests, which may indicate user enumeration or a bruteforce attack;
content:"|a1 03 02 01 05 a2 03 02 01 0a|" - byte sequence indicating that this is a AS-REQ packet:
content:"|6b 72 62 74 67 74|"; fast_pattern; - specifies the byte sequence krbtgt:

• 6b 72 62 74 67 74 - TGT request flag;
• fast_pattern - tells the Suricata engine to search for this pattern first to speed up the search;

threshold:type limit, track by_src, count 5, seconds 10; - a behavioral filter that makes the rule threshold-based: if more than 5 packets matching the signature come from one src, an alert is generated. This implements detection of mass bruteforce attacks or enumeration in traffic;
threshold - indicates the thresholds for triggering the rule;
type limit - limit on the number of triggers;
track by_src - track by source (number of requests from each source);
count 5 - triggers if the number of requests exceeds 5;
seconds 10 - time period for tracking requests (10 seconds);
sid:100000 - unique signature identifier;
rev:1 - signature version indicating its revision.

caster@kali:/mnt/hgfs/ID$ sudo suricata -c /etc/suricata/suricata.yaml -r userenum.pcap       
[sudo] password for caster: 
i: suricata: This is Suricata version 8.0.1 RELEASE running in USER mode
i: mpm-hs: Rule group caching - loaded: 1 newly cached: 0 total cacheable: 1
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 248 packets, 38811 bytes
caster@kali:/mnt/hgfs/ID$ cat fast.log | grep "High Rate"
10/19/2025-13:57:24.942940  [**] [1:100000:1] [UDP] High Rate of Kerberos AS-REQ, Possible Enumeration [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:34248 -> 192.168.1.245:88
10/19/2025-13:57:25.222626  [**] [1:100000:1] [UDP] High Rate of Kerberos AS-REQ, Possible Enumeration [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:39192 -> 192.168.1.245:88
10/19/2025-13:57:24.943074  [**] [1:100000:1] [UDP] High Rate of Kerberos AS-REQ, Possible Enumeration [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:45583 -> 192.168.1.245:88
10/19/2025-13:57:24.943052  [**] [1:100000:1] [UDP] High Rate of Kerberos AS-REQ, Possible Enumeration [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:58726 -> 192.168.1.245:88
10/19/2025-13:57:24.942986  [**] [1:100000:1] [UDP] High Rate of Kerberos AS-REQ, Possible Enumeration [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:45385 -> 192.168.1.245:88

In large Kerberos packets, some ASN.1 tags may cross segment boundaries; reassembly must be enabled in Suricata for full detection.

This is precisely how user enumeration on the network can be detected.

The directions used in these signatures, alert udp|tcp any any -> any 88, are for demonstration purposes only.
Do not blindly copy signatures. Before integrating them into an IDS, signatures should be tested, preferably in a non-production environment.

Kerberos Bruteforce

In this case, the attacker's goal is to brute-force passwords for already known accounts.
Such attacks also use Kerberos AS-REQ, but with one key difference: PA-DATA is added to the request, which contains an encrypted timestamp. Thus, Kerberos bruteforce attacks can be detected by the presence of PA-DATA in AS-REQ and the high frequency of such requests from a single source.

It is important to understand:

• The attacker sends a large number of AS-REQ messages with PA-DATA, attempting to authenticate through the KDC for each user;
• Each incorrect password triggers a KRB5KDC_ERR_PREAUTH_FAILED event, which allows intensive brute force attempts to be detected;
• This behavior is easy to differentiate from legitimate logins: the frequency of AS-REQ with PA-DATA from a single IP or host is significantly higher than normal.

Example

The same kerbrute can be used to perform a brute force attack, but with the bruteuser mode:

caster@kali:/mnt/hgfs/ID$ ./kerbrute bruteuser --dc core.myownsummer.org -d myownsummer.org passwords kestre 

    __             __               __     
   / /_____  _____/ /_  _______  __/ /____ 
  / //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
 / ,< /  __/ /  / /_/ / /  / /_/ / /_/  __/
/_/|_|\___/_/  /_.___/_/   \__,_/\__/\___/                                        

Version: dev (9cfb81e) - 10/19/25 - Ronnie Flathers @ropnop

2025/10/19 18:40:43 >  Using KDC(s):
2025/10/19 18:40:43 >  	core.myownsummer.org:88

2025/10/19 18:40:43 >  [+] VALID LOGIN:	 kestre@myownsummer.org:Password123
2025/10/19 18:40:44 >  Done! Tested 22 logins (1 successes) in 0.953 seconds

Each incorrect attempt will trigger a KRB5KDC_ERR_PREAUTH_FAILED event, which allows you to detect intensive brute force attempts. However, when Kerberos auditing is enabled on the domain controller, Event ID 4768 and 4771

Analysis of the AS-REQ during bruteforce

When kerbrute performs a brute-force attack, it adds a PA-DATA block containing a timestamp (PA-ENC-TIMESTAMP) to the AS-REQ. This makes the packet visually different from enumeration requests.

a1 03 02 01 05  // [1] INTEGER 5  → pvno = 5
a2 03 02 01 0a  // [2] INTEGER 10 → msg-type = 10 (AS-REQ)
a1 03 02 01 02  // [1] INTEGER 2  → padata-type = 2 (PA-ENC-TIMESTAMP)
6b 72 62 74 67 74 // "krbtgt"

Unlike the user enumeration process, where PA-DATA is absent, here |a1 03 02 01 02| confirms the presence of PA-DATA:

Behavior in traffic

Brute force attacks usually operate at very high speeds—tens or hundreds of AS-REQ with PA-DATA per second. Legitimate clients, on the other hand, generate single requests, and only when logging in.
Therefore, the signature must take into account not only the byte fingerprint (AS-REQ + PA-DATA), but also the frequency of such requests. For this reason, the signature must be based not only on the byte fingerprint, but also on the behavior of the source. Therefore, threshold parameters must be used in signatures.

Signatures

Signature for detecting Kerberos bruteforce attack will look as follows:

alert udp any any -> any 88 (
  msg:"[UDP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack";
  content:"|a1 03 02 01 05 a2 03 02 01 0a|";
  content:"|a1 03 02 01 02|";
  content:"|6b 72 62 74 67 74|";
  fast_pattern;
  threshold:type limit, track by_src, count 5, seconds 10;
  sid:100003;
  rev:1;
)

alert tcp any any -> any 88 (
  msg:"[TCP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack";
  content:"|a1 03 02 01 05 a2 03 02 01 0a|";
  content:"|a1 03 02 01 02|";
  content:"|6b 72 62 74 67 74|";
  fast_pattern;
  threshold:type limit, track by_src, count 5, seconds 10;
  sid:100004;
  rev:1;
)

In these signatures:

alert - generates an alert when triggered;
udp / tcp - defines the protocol;
any any -> any 88 - analyzes all traffic to port 88 (Kerberos KDC);
msg:"High Rate of Kerberos AS-REQ with PA-DATA" - message indicating a high frequency of AS-REQ with pre-auth, which is typical for bruteforce or password-spray attacks;
content:"|a1 03 02 01 05 a2 03 02 01 0a|" - byte sequence for AS-REQ;
content:"|a1 03 02 01 02|" - presence of PA-DATA block;
content:"|6b 72 62 74 67 74|"; fast_pattern; - presence of the krbtgt string (ASCII);
threshold:type limit, track by_src, count 5, seconds 10; - behavioral filter for recording spikes in requests from a single IP;
sid:100003 and sid:100004 - unique rule identifiers;
rev:1 - signature version (revision).

Now to verify that this signature works:

caster@kali:/mnt/hgfs/ID$ sudo suricata -c /etc/suricata/suricata.yaml -r bruteforce.pcap
[sudo] password for caster: 
i: suricata: This is Suricata version 8.0.1 RELEASE running in USER mode
i: mpm-hs: Rule group caching - loaded: 1 newly cached: 0 total cacheable: 1
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 507 packets, 104977 bytes
caster@kali:/mnt/hgfs/ID$ cat fast.log | grep "Bruteforce"
10/19/2025-15:04:49.878182  [**] [1:100003:1] [UDP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:50208 -> 192.168.1.245:88
10/19/2025-15:04:49.878364  [**] [1:100003:1] [UDP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:42617 -> 192.168.1.245:88
10/19/2025-15:04:49.878260  [**] [1:100003:1] [UDP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:60017 -> 192.168.1.245:88
10/19/2025-15:04:49.878687  [**] [1:100003:1] [UDP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:57455 -> 192.168.1.245:88
10/19/2025-15:04:49.878437  [**] [1:100003:1] [UDP] High Rate of Kerberos AS-REQ with PA-DATA, Possible Bruteforce or Spray Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.1.250:34783 -> 192.168.1.245:88

This allows reliable detection of brute-force/password-spray attacks on Kerberos at the network layer.

As in the previous chapter, signatures are intended for demonstration purposes. Before implementation in a production environment, they must be tested and calibrated against baseline traffic.

Kerberoasting

Kerberoasting is an attack technique that extracts service tickets (TGS) for accounts with SPN and then brute forces their passwords. Key fact: ticket.enc-part in TGS-REP is encrypted with the key of the target account (usually a service user account). Attackers usually save this and perform brute force attacks offline.
The goal of Kerberoasting is to obtain the password of an AD service account by offline brute forcing its TGS.

Prerequisites and conditions

• A domain account (Domain User) is required;
• Accounts with the servicePrincipalName attribute must be present in AD;
• If the service account uses a weak or long-unchanged password, it can be guessed offline after receiving a ticket;
• If the KDC issues a ticket in a format that allows for easy export (often RC4-HMAC or AES), the attacker can download the material and brute force it locally;
• Lack of strict rotation and sufficient strength of service user account passwords.

Attack Flow

• Searching Kerberoastable users via LDAP: searching for objects with servicePrincipalName=* among user objects and selecting “viable” ones by the userAccountControl bit mask. Paged Results and the subtree scope are often used;
• TGS-REQ: The client sends a TGS-REQ with PA-TGS-REQ (inside - AP-REQ with TGT on krbtgt). The req-body lists the desired enctypes. The KDC responds with TGS-REP; the ticket.enc-part.etype field records the actual ticket encryption type;
• Offline Bruteforce: extraction of $krb5tgs$23/ $17 /$18 and password brute force.

Example

First, the attacker searches for “Kerberoastable” accounts, i.e., objects that have the servicePrincipalName attribute:

caster@kali:/mnt/hgfs/ID$ impacket-GetUserSPNs myownsummer.org/svettel:'Password123' -dc-ip 192.168.1.245 
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

ServicePrincipalName       Name     MemberOf  PasswordLastSet             LastLogon  Delegation 
-------------------------  -------  --------  --------------------------  ---------  ----------
HTTP/core.myownsummer.org  svc_web            2025-10-19 19:21:15.160738  <never>  

After finding such accounts, the attacker requests their TGS tickets:

caster@kali:/mnt/hgfs/ID$ impacket-GetUserSPNs myownsummer.org/svettel:'Password123' -dc-ip 192.168.1.245 -request                                  
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

ServicePrincipalName       Name     MemberOf  PasswordLastSet             LastLogon  Delegation 
-------------------------  -------  --------  --------------------------  ---------  ----------
HTTP/core.myownsummer.org  svc_web            2025-10-19 19:21:15.160738  <never>               



[-] CCache file is not found. Skipping...
$krb5tgs$23$*svc_web$MYOWNSUMMER.ORG$myownsummer.org/svc_web*$59e498cc5f805218444f3deaa8a2a012$7d3824d543b8e2ee075f75256915c434176f2fd71e16ae90183ceb35dad3a34fc2523e0ebb555405361f0e4bc9bdf3f9a895ca8291050d21bb710715137a0f8a4b4dcd5824777aeeb2f1dccfe6dcb1e73df830855d98d6168e2ac5c99204f768295708e6793622789adc7a006fe00909f98c02f8f58f1d2e4749358fa51d88237bc40c3f9d97a7ad76876fa987d5d295588abba6753a21d1267ea8c092b5e6c415d0256c4ec9384d0945b42855f8ed3756f064433a4a8842227895d6a872cb46f48ffdacff2c397d5a7df7cca8c99ecc510cbd4c1eee7c87098cbcdbc1496af1ef42210713360dd0d248188a3b7b5ddb17f860661916df173953e11f61e17e73698f60d9a51586bb2adfe1b5ed8d90c9f146f5ea3e52297c49fc11cbf4dcff529a0b52ce9a0b2e0a7f3fe96d3bbd779d324eefc38c15a2f822363650b1c379f7a1eda8d13193c982efb1c3de182fcae20537729aa0c2cffa4246a3dbde688229e292396fb0c885209bbf6cffc12067b2db55f8d76261487bfc676647f01e4e64cb2f7d7e4e41d9261f90b4adbc956c2831cfb70386a3a974f9b0560782762a41a4f91c45cd796cd417b60c1685fbabe4c3bfab9fe5a7d3154fba1220859231dad956d62367c2708dde5ff16fb6398ec2ff0161f9276eca2f1f24e5c08f8fa0848310631e9f01ba288b9fba528d0ec480b900ecb18fb0933e1698f4cd73282402ef327740f270ffbb97b9d4235e56d122451658626a7f5d30a22af72428d1698c5d79fc2f3c55f614ac1686297339bdff33537b982fa4b28b4d813ec0cef97ec99ffbcbd4a0867dcae3abd8d96dce2dad781d5dc226e4809f9df656c369ffd66d9cfeb12ad5ca8f625ca47d2307ff39e1b9fde9adc2894c7d8bf3cb1cc4227856545ba22ffd2a2f3aa9872953e4736974d51f50766ae8b11f0f6f653ea7d7ddff96fa1ae2c2263db76ed8fe060825879605b8fd997c27939a0f2b946dee392beba731d7853ba3b79f9e278de4d9660cd1c560cf892f4e9738beb0b50eaf04238abe912952b8dfe82cad2d50ca6f3968f17b88fd4eb908d82aeddf9b1158c1ad67b15c0e2d5d0b5d8b369bb998a93caec40e63009c7b447e9a6443150425ed575e9e9dd43795b9bb83b8042dea3be4f72f49833a8e2e463c785c35ab043fe99eb13496471b82509001fd1d08a5eae5b07d6018a82ec09cce93c03db2d98964486d26c0dbea4753c219290c263735df4e1f86586da6870a5fddb1d266ff58297b67b90951c721aacd3172598a7249d6ab2368bf00964a256063568ac924de10d74270b1c5908152e7cb39d13ac1168c1ef8d8f315f070beec3830c8f12fc9e9398e13c154ac28a75659acfca263626932cfc0e2bf7fd84d4a4a26947527e38716ce8d0cd8e485f3d004ba0c20ce826d7462bb82bd2aba7b4f9af70202d61b7b12ba107bc46c153f55bc92b8bdb0d7b075b1e6f3db0f19a99b1de6c73a37ba8ca727849eef223f96e4

Analysis of LDAP Reconnaissance Traffic

Before obtaining a TGS, the attacker usually performs reconnaissance via LDAP to find which accounts in the domain have servicePrincipalName. These accounts provide TGS for offline cracking.
The network footprint of this reconnaissance differs from normal “user” LDAP queries: it is focused on mass inventory of service accounts.

The attacker uses LDAP search to look for the following:

• Accounts with servicePrincipalName: if an account has an SPN, the KDC will encrypt the ticket with the key of that account when issuing a TGS, which is what is needed for offline brute force attacks. As a result, this manifests itself in the LDAP query as the presence of the servicePrincipalName=* filter (present filter). In a network packet, this is usually visible in the "servicePrincipalName" string in the request payload;
• Restrictions on user objects: SPNs can be assigned to user and computer accounts (service accounts); attackers often prefer user accounts because passwords are rotated less often. These are less frequently rotated and their passwords are potentially configured insecurely;
• UAC filter: It makes no sense to request TGS for disabled accounts, system accounts without passwords, etc. Therefore, attackers often set a bitwise check on userAccountControl in LDAP requests to exclude such cases. This typically appears as an extensibleMatch / bitwise AND on OID 1.2.840.113556.1.4.803 with a specific bit mask (in this capture — 0x32; the exact mask may vary by tool/config), and the filter is inverted (NOT) so that only “active” targets remain;
• Massive selection: The attacker is interested in processing the entire directory, so LDAP queries are sent with scope=subtree (across the entire tree) and with Paged Results control (500–1000 records per page). This is a clear sign of automated reconnaissance. This is evident in the presence of the scope=subtree parameter and control OID 1.2.840.113556.1.4.319 (Paged Results) with the page size specified.

This is a hex dump of an LDAP packet containing the attacker's query to search for Kerberoastable users:

And you need to determine which byte sequences to base your signature on in order to detect LDAP requests, which potentially allows you to identify the start of a Kerberoasting attack.

Signature for searching Kerberoastable users

alert tcp any any -> any 389 (
  msg:"Searching Kerberoastable users via LDAP - Possible Kerberoasting";
  flow:to_server, stateless;
  content:"|a3 18 04 0e 6f 62 6a 65 63 74 43 61 74 65 67 6f 72 79 04 06 70 65 72 73 6f 6e|";
  content:"|87 14 73 65 72 76 69 63 65 50 72 69 6e 63 69 70 61 6c 4e 61 6d 65|";
  content:"|a2 31 a9 2f 81 16 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 2e 34 2e 38 30 33 82 12 75 73 65 72 41 63 63 6f 75 6e 74 43 6f 6e 74 72 6f 6c 83 01 32|";
  fast_pattern;
  sid:100004;
  rev:1;
)

If LDAP traffic is encrypted, the packet content becomes inaccessible for signature-based IDS detection. In such cases, detection is only possible when SSL/TLS inspection or MITM decryption is implemented on the monitoring point.

Now to verify that this signatures works:

caster@kali:/mnt/hgfs/ID$ sudo suricata -c /etc/suricata/suricata.yaml -r ldap.pcap
[sudo] password for caster: 
i: suricata: This is Suricata version 8.0.1 RELEASE running in USER mode
i: mpm-hs: Rule group caching - loaded: 1 newly cached: 0 total cacheable: 1
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 13 packets, 2521 bytes
caster@kali:/mnt/hgfs/ID$ cat fast.log | grep "via LDAP"       
10/19/2025-22:45:17.853601  [**] [1:100004:1] Searching Kerberoastable users via LDAP - Possible Kerberoasting [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.1.250:52176 -> 192.168.1.245:389

Analysis of Kerberoasting traffic

When an attacker performs Kerberoasting, they send a TGS-REQ request to the domain controller to obtain a service ticket (TGS) for a specific account that has a Service Principal Name (SPN). The ticket obtained is saved and used to brute force the password for that account.

Below is the TGS-REQ intercepted during the attack:

a1 03 02 01 05  // pvno = 5
a2 03 02 01 0c  // msg-type = 12 (TGS-REQ)
6b 72 62 74 67 74 // "krbtgt" (in the AP-REQ/Ticket sname)
a0 03 02 01 17  // etype = 23 (RC4-HMAC) in EncryptedData
a0 07 03 05 00 40 81 00 10 // kdc-options = 0x40810010 (canonicalize, forwardable, renewable-ok)
30 23 a0 04 02 02 ff 80    // name-type = -128 (KRB5-NT-MS-PRINCIPAL)

• pvno=5 + msg-type=12 - indicates a standard Kerberos TGS-REQ packet;
• krbtgt inside krb-ap-req (type 14) - shows that this is a chain for obtaining a new ticket based on a valid TGT;
• name-type = MS-PRINCIPAL (-128) - key point: it is not krbtgt that is requested, but SPN;
• etype = 23 (RC4-HMAC) - often a sign of a downgrade used to simplify brute force (RC4 is easy to brute force);
• req-body.kdc-options;0x40810010 - a set of flags called by the client (forwardable, renewable, canonicalize, renewable-ok)

When the KDC responds to a TGS-REQ request, it responds with a TGS-REP. This message contains the ticket itself and the encrypted part ticket.enc-part, which the attacker will brute force.

Below is the TGS-REP packet intercepted during the attack:

a0 03 02 01 05  // [0] INTEGER 5   → pvno = 5  (for KDC-REP this tag is [0])
a1 03 02 01 0d  // [1] INTEGER 13  → msg-type = 13 (TGS-REP)
a0 03 02 01 17  // [0] INTEGER 23  → enc-part.etype = 23 (RC4-HMAC)
a2 82 04 3b 04 82 04 37 ... // [2] (EXPLICIT) OCTET STRING → enc-part.cipher

• pvno = 5 + msg-type = 13 - indicates that this is a TGS-REP, i.e., the KDC's response to a previously made TGS-REQ; in fact, the KDC issued a ticket;
• enc-part.etype = 23 (RC4-HMAC) - shows which algorithm is used to encrypt part of the response; 23 (RC4) is often found in downgrades/old configurations, which makes brute force attacks significantly easier;
• a2 82 04 3b 04 82 04 37 ... - a long encrypted binary block. It is this block that the attacker saves and converts to the $krb5tgs$... format for a brute force attack.

Signatures for Kerberoasting

For accurate Kerberoasting detection, two episodes must be matched: TGS-REQ (service ticket request from the client) and TGS-REP (KDC response with the issued ticket).
A TGS-REQ alone does not necessarily indicate an attack, as it also occurs in legitimate Kerberos operations.
However, if the request contains signs of a targeted SPN request and encryption downgrade (RC4-HMAC), followed by a corresponding TGS-REP, this is a direct indication of Kerberoasting.

Two interrelated signatures combined via flowbit are used for this detection:

• Stage 1 - TGS-REQ: responds to a suspicious service ticket request, sets flowbit, but does not generate an alert (noalert is used for this);
• Stage 2 - TGS-REP: triggers only if such a TGS-REQ request has been previously recorded (set flowbit) and generates an alert. After that, the bit is reset so as not to interfere with other sessions.

Stage 1 - Detection of suspicious TGS-REQ

This rule analyzes outgoing traffic (towards KDC, port 88 (TCP/UDP) and looks for the following signs:

• ASN.1 header for TGS-REQ (msg-type = 12);
• Presence of the krbtgt string inside AP-REQ - this is part of the ticket acquisition chain;
• Flags in kdc-options (0x40810010) - often found in automated tools;
• Encryption request etype = 23 (RC4-HMAC) — a clear sign of downgrade;
• Field name-type = KRB5-NT-MS-PRINCIPAL (-128) — request for a specific SPN, not TGT.

alert udp any any -> any 88 (
  msg:"[UDP] Suspicious Kerberos TGS-REQ — stage 1";
  flow:to_server, stateless;
  content:"|a1 03 02 01 05 a2 03 02 01 0c|";
  fast_pattern;
  content:"|6b 72 62 74 67 74|";
  content:"|a0 07 03 05 00 40 81 00 10|";
  content:"|a0 03 02 01 17|";
  content:"|30 23 a0 04 02 02 ff 80|";
  flowbits:set,kerb.tgsreq.rc4;
  noalert;
  sid:100005;
  rev:1;
)

alert tcp any any -> any 88 (
  msg:"[TCP] Suspicious Kerberos TGS-REQ — stage 1";
  flow:to_server;
  content:"|a1 03 02 01 05 a2 03 02 01 0c|";
  fast_pattern;
  content:"|6b 72 62 74 67 74|";
  content:"|a0 07 03 05 00 40 81 00 10|";
  content:"|a0 03 02 01 17|";
  content:"|30 23 a0 04 02 02 ff 80|";
  flowbits:set,kerb.tgsreq.rc4;
  noalert;
  sid:100006;
  rev:1;
)

Stage 2 - detecting the TGS-REP response

When the domain controller responds to such a request, a TGS-REP message (msg-type = 13) appears on the network. It contains an encrypted part enc-part, which the attacker later downloads and uses for brute force.

This rule analyzes reverse traffic (flow:to_client) and only triggers if the corresponding flowbit has been set previously. After triggering, the bit is reset (unset) to prevent repeated triggering on other flows.

alert udp any 88 -> any any (
  msg:"[UDP] Kerberos TGS-REP after SPN request — Possible Kerberoasting";
  flow:to_client;
  content:"|a0 03 02 01 05 a1 03 02 01 0d|";
  fast_pattern;
  content:"|a0 03 02 01 17|";
  flowbits:isset,kerb.tgsreq.rc4;
  flowbits:unset,kerb.tgsreq.rc4;
  sid:100007;
  rev:1;
)

alert tcp any 88 -> any any (
  msg:"[TCP] Kerberos TGS-REP after SPN request — Possible Kerberoasting";
  flow:to_client;
  content:"|a0 03 02 01 05 a1 03 02 01 0d|";
  fast_pattern;
  content:"|a0 03 02 01 17|";
  flowbits:isset,kerb.tgsreq.rc4;
  flowbits:unset,kerb.tgsreq.rc4;
  sid:100008;
  rev:1;
)

flowbits:isset checks whether there was a suspicious TGS-REQ earlier;
flowbits:unset - resets the bit after an alert so as not to interfere with other sessions.

Now to verify that this signatures works:

caster@kali:/mnt/hgfs/ID$ sudo suricata -c /etc/suricata/suricata.yaml -r kerberoasting.pcap
i: suricata: This is Suricata version 8.0.1 RELEASE running in USER mode
i: mpm-hs: Rule group caching - loaded: 2 newly cached: 0 total cacheable: 2
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 46 packets, 9911 bytes
caster@kali:/mnt/hgfs/ID$ cat fast.log | grep "Possible"
10/19/2025-21:51:43.309323  [**] [1:100008:1] [TCP] Kerberos TGS-REP after SPN request — Possible Kerberoasting [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.1.245:88 -> 192.168.1.250:33998

Final signature logic

Thus, the combination of two signatures forms a contextual detection: Suricata only reacts when a suspicious TGS-REQ is accompanied by a real TGS-REP. This ensures high accuracy and allows Kerberoasting attacks to be detected at the network level in real time.

AS-REP Roasting

The AS-REP Roasting attack is based on the ability to request an AS-REP ticket from the domain controller (KDC) without passing preliminary authentication. This is only possible if the Do not require Kerberos preauthentication option is enabled for the domain account, which is often the case for old service or backup technical accounts.

When preauthentication is disabled, an attacker can send an AS-REQ message to the KDC on behalf of the vulnerable account and receive an AS-REP response containing an encrypted EncPart block. This block is encrypted with a key derived from the user's NT password hash (using RC4-HMAC / etype 23 encryption).
After receiving EncPart, the attacker can download it and brute force the account password.

Prerequisites and conditions

• No domain privileges are required to request AS-REPs; knowing usernames is sufficient. LDAP can help enumerate candidates but isn't mandatory;
• Active Directory must contain accounts with pre-authentication disabled;
• Such accounts are identified by the userAccountControl attribute with the DONT_REQUIRE_PREAUTH flag set;
• The absence of rotation or the use of weak passwords in such accounts makes an attack almost guaranteed.

Attack Flow

• The attacker sends an AS-REQ request to port TCP/88 in the KDC, specifying the name of the target account. The packet omits PA-ENC-TIMESTAMP (padata-type = 2) in PA-DATA (i.e., no pre-authentication timestamp);
• In response to the attacker's AS-REQ, the domain controller returns an AS-REP (msg-type = 11) containing an encrypted EncPart block;
• Offline Bruteforce: extraction of the encrypted block and its brute force.

Example

caster@kali:/mnt/hgfs/ID$ impacket-GetNPUsers myownsummer.org/svettel:'Password123' -dc-ip 192.168.1.245 -format hashcat -outputfile hashes.txt
Impacket v0.13.0.dev0 - Copyright Fortra, LLC and its affiliated companies 

Name    MemberOf  PasswordLastSet             LastLogon                   UAC      
------  --------  --------------------------  --------------------------  --------
kestre            2025-10-19 18:40:39.546392  2025-10-20 14:05:05.893996  0x400200 
sperez            2025-10-20 09:45:55.177220  2025-10-20 14:05:05.893996  0x400200 



$krb5asrep$23$kestre@MYOWNSUMMER.ORG:2eb7d7bd164479ef336217107d51a0a3$b0b8c5ec4e0dd56f541f8a8a99e8d43f6caab1979b6d255ea21bf1e7cc9b988ea51079e700f4ea614fbe2f83436c06b2d476dceeecae9aa9226dab0ffda4c1a1a28c14798b1dd811a4f0f6754ce53d34ffd7699719bc492fd2b41e86ffdc9c00ac4c4e3242c76152861e5d738c0ae8325156856a817c07757535d70e2de2bf203060841644191ec98e208c224682b74b1e4b1087f5c0fc0c07aaeb953237a54eb286ac4882bbf85ad6e8ebea43e476e91174b37ef0b3e961ebeb109e73006572c045b2c58ec55be9dff6f96f8b51e54c9369f56e6335892838c553d359fccb1d48d2c7adbc28d36801833a55f6aef08b0ef1
$krb5asrep$23$sperez@MYOWNSUMMER.ORG:ef9a4b363e74ada43a031dd17f96f165$4bc86ebfba70efdcfa8021d7fa410806be5ad714af7e33fa443feaf34f419d53823932098390566a861220cda5a5bd0135b596fd6cfa3a76e91000daa56f15d108e50d47c60e343554c72a383232594183f62c92ef272d32a3cc53e9cca531f1542e177aa8cc6a441c787d60a8d8926d5b62f09ba37e3bcdb86f16fcb2746e7a1ab7dfc12b51ccb9f47400d4b5cd50962d7d89a13f50e12246430da3394914706b8420a324c53989665e9f90d1b2b301ad9e166f08cca10b642be13e5f17ebabc0b135cd201fd6e0830ce2e2651e69c63272442e8fa72e3fd0bd4b44f396d3847d05956598911d3af40e720f595c2beb513d

a1 03 02 01 05               // [1] INTEGER 5  → pvno = 5 (AS-REQ)
a2 03 02 01 0a               // [2] INTEGER 10 → msg-type = 10 (AS-REQ)
a0 07 03 05 00 50 80 00 00 a1 // kdc-options (FORWARDABLE | PROXIABLE | RENEWABLE)
6b 72 62 74 67 74            // "krbtgt"
a8 05 30 03 02 01 17         // [8] SEQUENCE OF etypes: 23 (RC4-HMAC)

• pvno=5 + msg-type=10 - clearly indicates an AS-REQ packet;
• krbtgt in the request body means that the client is requesting a TGT from the KDC;
• kdc-options = FORWARDABLE | PROXIABLE | RENEWABLE - a characteristic combination of flags when using Impacket;
• req-body.etypes: 23 (RC4-HMAC) - indicates a preference for a less secure option, which simplifies brute force attacks.

Signature

The signature for AS-REP Roasting detection will be as follows:

alert tcp any any -> any 88 (
  msg:"Suspicious AS-REQ Packet, Possible AS-REP Roasting";
  flow:to_server, stateless;
  content:"|a0 07 03 05 00 50 80 00 00 a1|";
  content:"|6b 72 62 74 67 74|";
  fast_pattern;
  content:!"|a1 03 02 01 02|";
  sid:100009;
  rev:1;
)

In this signature:

alert - indicates that an alert will be generated when the rule is triggered;
tcp - indicates that the rule applies to TCP traffic;
any any -> any 88 - the rule will apply to any source IP address and port and any target IP address on port 88, which is the default port for Kerberos;
msg:"Suspicious AS-REQ Packet, Possible AS-REP Roasting" - message that will be output when the signature is triggered. In this case, the message indicates a possible AS-REP Roasting attack;
flow: to_server, stateless;
flow: to_server - specifies that the signature should only trigger on traffic directed to the server;
stateless - indicates that the signature operates without regard to the state of the connection;
content:"|a0 07 03 05 00 50 80 00 00 a1|" - sequence of bytes indicating the AS-REQ req-body kdc-options (typical for Impacket FORWARDABLE | PROXIABLE | RENEWABLE pattern);
content:"|6b 72 62 74 67 74|"; fast_pattern;:
content:"|6b 72 62 74 67 74|" - points to the string krbtgt
fast_pattern - indicates that this string is used for quick matching at the beginning of the packet content check;
content:!"|a1 03 02 01 02|"; :
! means a negative condition, i.e. the rule should work if the specified sequence is not present in the packet;
a1 03 02 01 02 - is a sequence of bytes corresponding to padata-type = 2 (PA-ENC-TIMESTAMP). Its absence indicates an AS-REQ without pre-auth timestamp, which is characteristic of AS-REP Roasting;
sid:100009 - unique signature identifier;
rev:1 - signature version indicating its revision

Verify that this signature works:

caster@kali:/mnt/hgfs/ID$ sudo suricata -c /etc/suricata/suricata.yaml -r as-rep-roasting.pcap
i: suricata: This is Suricata version 8.0.1 RELEASE running in USER mode
i: mpm-hs: Rule group caching - loaded: 1 newly cached: 0 total cacheable: 1
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/1th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 36 packets, 7961 bytes
caster@kali:/mnt/hgfs/ID$ cat fast.log | grep "AS-REP Roasting"
10/20/2025-14:01:21.602279  [**] [1:100009:1] Suspicious AS-REQ Packet, Possible AS-REP Roasting [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.1.250:49042 -> 192.168.1.245:88
10/20/2025-14:01:21.604319  [**] [1:100009:1] Suspicious AS-REQ Packet, Possible AS-REP Roasting [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.1.250:49056 -> 192.168.1.245:88

This way, you can detect an AS-REP Roasting attack in network traffic.

Recommendations

• Require Pre-Authentication: Always enabled for all users. Without it, an attacker can request AS-REP and obtain a hash for offline cracking (AS-REP Roasting);
• Disable RC4 and DES: Outdated encryption algorithms (etype 23, etype 3). Disabling them prevents downgrade Kerberoasting attacks;
• Use Only AES Encryption (AES128/AES256): This increases the complexity of offline attacks and prevents downgrades;
• Rotate Service Account Passwords: Change your service account passwords regularly. Old passwords make Kerberoasting effective because tickets remain valid longer;
• Audit and Monitor Kerberos Events (4768–4771): Allows you to see brute-force, AS-REP, and Kerberoasting attempts. Especially useful for correlation with IDS alerts;
• Isolate Domain Controllers / Limit Port 88: Restricting TCP/UDP port 88 prevents external Kerberos access and scanning.

Outro

I did this research to figure out how to spot Kerberos attacks just by analyzing traffic. I don't think it's a good idea to rely only on an IDS engine; you need to take a comprehensive approach to network detection and protection.