Kerberos protocol attacks are popular in the penetration testing industry. In this article, I will demonstrate techniques for detecting attacks against the Kerberos protocol using Suricata IDS.

Caster - Kerbhammer

Genre: Defensive
Label: exploit.org
Release Date: 19 May 2024

Performed by: Caster
Written by: Magama Bazarov
Cover Man: Magama Bazarov (Sony ILCE-7M3, f/22, 5 sec)

Intro

Kerberos - is a network authentication protocol that provides a mechanism for mutual authentication between client and server before communication between them is established. Kerberos acts as a trusted third-party authentication service using cryptographic keys, which provides protection against the interception, modification, and use of data by attackers on an insecure network. Kerberos is based on symmetric cryptography, and it requires a key distribution center. There are extensions to Kerberos that allow public key cryptography to be used in some stages of authentication.

In this article, I will demonstrate ways to detect anomalous AS-REQ packets as well as AS-REP Roasting.

Abnormal AS-REQ

On the network, an attacker can perform user enumeration using kerbrute, also use it to perform Password Spray attacks, password brute force, etc.

But the problem for the attacker is that kerbrute requires AS-REQ packets to be sent, and this happens at a very fast speed. This can be a jumping off point for signature writing, because for example 10 AS-REQs sent in 30 seconds is an anomalous behavior that network engineers will pay attention to.

Here is an example of a kerbrute exploit in which the attacker searched for existing users in an Active Directory domain.

caster@kali:~/kerberos-research$ ./kerbrute userenum --dc dc01.myownsummer.org -d myownsummer.org usernames.txt

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

Version: v1.0.3 (9dad6e1) - 05/18/24 - Ronnie Flathers @ropnop

2024/05/18 21:10:43 >  Using KDC(s):
2024/05/18 21:10:43 >  	dc01.myownsummer.org:88

2024/05/18 21:10:44 >  [+] VALID USERNAME:	 [email protected]
2024/05/18 21:10:44 >  [+] VALID USERNAME:	 [email protected]
2024/05/18 21:10:44 >  Done! Tested 22 usernames (2 valid) in 0.591 seconds

This number of AS-REQ packets in a few seconds is an anomalous behavior in the network. The following signature can be written on this to track anomalous AS-REQ within the network.

alert udp any any -> any 88 (msg:"Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack"; content:"|a1 03 02 01 05 a2 03 02 01 0a|"; threshold:type limit, track by_src, count 10, seconds 30; sid:100000; rev:1;)

In this signature:

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:"Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack" - a message when a rule is triggered. Indicates a high frequency of KRB-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 KRB-AS-REQ packet;

threshold:type limit, track by_src, count 10, seconds 30:

• 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 10 - triggers if the number of requests exceeds 10;
• seconds 30 - time period for tracking requests (30 seconds);

sid:100000 - unique signature identifier;

rev:1 - signature version indicating its revision.

Verify the operation of this signature:

caster@kali:~/kerberos-research$ sudo suricata -c /etc/suricata/suricata.yaml -r kerbruteusernum.pcap 
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
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, 64 packets, 10435 bytes
caster@kali:~/kerberos-research$ cat fast.log | grep "High Rate of KRB-AS-REQ"
05/18/2024-18:58:20.646801  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:56084 -> 192.168.0.71:88
05/18/2024-18:58:20.647002  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:36325 -> 192.168.0.71:88
05/18/2024-18:58:20.646795  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:33147 -> 192.168.0.71:88
05/18/2024-18:58:20.646923  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:49372 -> 192.168.0.71:88
05/18/2024-18:58:20.647008  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:48117 -> 192.168.0.71:88
05/18/2024-18:58:20.742376  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:38735 -> 192.168.0.71:88
05/18/2024-18:58:20.646928  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:48928 -> 192.168.0.71:88
05/18/2024-18:58:20.647080  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:39473 -> 192.168.0.71:88
05/18/2024-18:58:20.840548  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:34125 -> 192.168.0.71:88
05/18/2024-18:58:20.646247  [**] [1:100001:1] Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack [**] [Classification: (null)] [Priority: 3] {UDP} 192.168.0.171:45964 -> 192.168.0.71:88

This is how you can detect anomalous AS-REQ messages that can be generated by an attacker during user renumbering or bruteforce attacks.

AS-REP Roasting Detection

AS-REP Roasting - is a Kerberos protocol attack method that targets Active Directory accounts that have pre-authentication disabled.

How this attack works

I'll explain this attack briefly. It is conducted in several stages:

• AS-REP Request: The attack begins by sending an authentication request (AS-REQ) on behalf of an account that does not require a Pre-Authentication mechanism. Such accounts are specifically configured without requiring Pre-Authentication to simplify the attack process;
• AS-REP Response: The domain controller responds (AS-REP) and includes an encrypted TGT (Ticket Granting Ticket) that is encrypted using the account password hash;
• Hash Extraction: An attacker intercepts this AS-REP response and extracts encrypted data from it, which can be thought of as a hash of the account password;
• Hash analysis: The obtained hash can be brute-force or rainbow tables attacked to obtain the account password.

AS-REP Roasting Attack (Impacket)

First, I will run an AS-REP Roasting attack using impacket-GetNPUsers to analyze the traffic

caster@kali:~/kerberos-research$ impacket-GetNPUsers -dc-ip 192.168.0.71 myownsummer.org/ -usersfile usernames.txt -format hashcat -outputfile hashes.txt
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation

[email protected]:c494472eb2709a075425bdea0b4518a6$57a21fd2f10f707590048d8bcc23463abffef99ed0705b62bb8c04dabf156ef55153d04d83b960ad106777afda3dc21589b55616f1849c5e691e5a947668ffaf1ad27a35d7d1d4ee6e8b37fc7a764a86f9d5e761d2a0952260683fa847fdfa175dd3940321d14961ca428883be81837c89d358c0344c58d83eac327b5667efcb0443ad5d2c20a398d318897fc9a6522b6d3a57410989e07db5ba1b1a5be52d5e70e84ff0372b39291fc01a7d5b8e7a3fb3a7f34d56c13a5b0b3c2c2605bfcf3741696d7f3239ec20fd4643967f010f6c293ffdb974d3bb7867c6b0cc0541c21c8981f0aac073947e659b8a968612a51fee52
[email protected]:551a7700665fdc828ec80d10f566cf4c$e4ab451eae086256c57c91ebb993bb9c3b255d8ff716bdcdcc589a932c3494e35a8649fe7c6b6049abbddbf2c409ed48d9807f9bf2b70cc46486149637ad577c26df4ee6cc1015a08365812d8355cca593b256adf47eb227f8a1e083b93652635f961617f5d4144c0e25f70e27f5e8f782ebc08bc0934776d1edb30c120405d3ae04a474b7611574b8f724a9c45ae057448dacf4a0f6f7b38fa8ad879158ce12dba086190d6e3cf93ba214d5a8c182217b874aefaa284331f5dbd16a059768643079b1a6fa6a26e39e5f3c4a981cf630819dd04c3b18f6e399a93a22fc19a66b8e66553bdff2c6cfe669a29d35e83cf3dbc9
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)
[-] Kerberos SessionError: KDC_ERR_C_PRINCIPAL_UNKNOWN(Client not found in Kerberos database)

In my case, only two users of the myownsummer.org domain have pre-authentication disabled, which is the point of AS-REP Roasting.

Analysis of the AS-REQ packet. This byte sequence indicates the body of the AS-REQ request

Also worth noting is krbtgt, its hexadecimal value:

This string is a key indicator because krbtgt is the account name of the Kerberos Ticket Granting Ticket (TGT) service. In AS-REP Roasting attacks, the attacker attempts to obtain encrypted data for this account to then attempt to crack passwords.

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

alert tcp any any -> any 88 (msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack"; 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:!"|a2 03 02 01 0c|"; sid:100001; 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 Kerberos Packet, Possible AS-REP Roasting attack" - 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 body of the AS-REQ request;

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:!"|a2 03 02 01 0c|";:

• ! - means a negative condition, i.e. the rule should work if the specified sequence is not present in the packet;
• a2 03 02 01 0c - is a sequence of bytes indicating the presence of pre-authentication. The absence of this sequence indicate the possibility of an AS-REP Roasting attack.

sid:100001 - unique signature identifier;

rev:1 - signature version indicating its revision

Verify that this signature works:

caster@kali:~/kerberos-research$ sudo suricata -c /etc/suricata/suricata.yaml -r asreproasting-impacket.pcap 
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
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, 198 packets, 22824 bytes
caster@kali:~/kerberos-research$ cat fast.log | grep "AS-REP Roasting"        
05/18/2024-22:42:41.928722  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58168 -> 192.168.0.71:88
05/18/2024-22:42:41.954679  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58252 -> 192.168.0.71:88
05/18/2024-22:42:41.923885  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58166 -> 192.168.0.71:88
05/18/2024-22:42:41.940431  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58206 -> 192.168.0.71:88
05/18/2024-22:42:41.945536  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58232 -> 192.168.0.71:88
05/18/2024-22:42:41.958981  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58274 -> 192.168.0.71:88
05/18/2024-22:42:41.932150  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58184 -> 192.168.0.71:88
05/18/2024-22:42:41.982261  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58330 -> 192.168.0.71:88
05/18/2024-22:42:41.935481  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58190 -> 192.168.0.71:88
05/18/2024-22:42:41.947392  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58234 -> 192.168.0.71:88
05/18/2024-22:42:41.960745  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58284 -> 192.168.0.71:88
05/18/2024-22:42:41.938097  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58200 -> 192.168.0.71:88
05/18/2024-22:42:41.965292  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58294 -> 192.168.0.71:88
05/18/2024-22:42:41.967294  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58296 -> 192.168.0.71:88
05/18/2024-22:42:41.949513  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58236 -> 192.168.0.71:88
05/18/2024-22:42:41.980040  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58324 -> 192.168.0.71:88
05/18/2024-22:42:41.952109  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58238 -> 192.168.0.71:88
05/18/2024-22:42:41.943463  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58218 -> 192.168.0.71:88
05/18/2024-22:42:41.963417  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58286 -> 192.168.0.71:88
05/18/2024-22:42:41.956896  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58262 -> 192.168.0.71:88
05/18/2024-22:42:41.969074  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58310 -> 192.168.0.71:88
05/18/2024-22:42:41.971948  [**] [1:1000001:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.171:58316 -> 192.168.0.71:88

Why does the absence of bytes a2 03 02 01 01 01 01 0c indicate no pre-authentication?

Kerberos uses pre-authentication to prevent certain types of attacks. When pre-authentication is enabled, the client must include a timestamp encrypted with the user's key in its AS-REQ request. This timestamp is then verified by the domain controller to confirm the authenticity of the request.

Kerberos uses ASN.1 (Abstract Syntax Notation One) to encode its messages. In the case of pre-authentication, a certain structure is included in the AS-REQ request, which may look like the following:

a2 - Context-specific tag.
03 - Length of the following byte sequence (3 bytes).
02 01 0c - INTEGER value 12 (0x0c) indicating the use of pre-authentication.

a2 03 02 01 0c

If pre-authentication is disabled, this structure will be missing from the AS-REQ request. Therefore, searching for the absence of this byte sequence allows you to identify accounts that have pre-authentication disabled, making them vulnerable to AS-REP Roasting attacks.

Thus, the content:!"|a2 03 02 01 0c|" element in the signature indicates the lack of pre-authentication in the AS-REQ request, which is an indicator of vulnerability to AS-REP Roasting attacks.

AS-REP Roasting Attack (Rubeus)

During AS-REP Roasting attack using Rubeus I noticed that the byte sequence for AS-REQ body is slightly different from the byte sequence for AS-REQ body when I run impacket-GetNPUsers I think it has to do with the peculiarities of the implementation of these tools.

However, I will write a signature for Rubeus as well. Everything is the same as for the rule for detecting AS-REP Roasting using Impacket.

alert tcp any any -> any 88 (msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack (Rubeus)"; flow: to_server, stateless; content:"|a0 07 03 05 00 40 80 00 10 a1|"; content:"|6b 72 62 74 67 74|"; fast_pattern; content:!"|a2 03 02 01 0c|"; sid:100002; rev:1;)

Checking that the signature works:

caster@kali:~/kerberos-research$ sudo suricata -c /etc/suricata/suricata.yaml -r asreproast-rubeus.pcap 
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 8 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/7th 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, 286 packets, 339846 bytes
caster@kali:~/kerberos-research$ cat fast.log | grep "AS-REP Roasting"
05/18/2024-23:46:14.015653  [**] [1:1000002:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack (Rubeus) [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.70:49970 -> 192.168.0.71:88
05/18/2024-23:46:14.062336  [**] [1:1000002:1] Suspicious Kerberos packet, Possible AS-REP Roasting attack (Rubeus) [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.0.70:49971 -> 192.168.0.71:88
caster@kali:~/kerberos-research$ 

All Rules

alert udp any any -> any 88 (msg:"Kerberos High Rate of KRB-AS-REQ, Possible User Enumeration/Bruteforce Attack"; content:"|a1 03 02 01 05 a2 03 02 01 0a|"; threshold:type limit, track by_src, count 10, seconds 30; sid:100000; rev:1;)

alert tcp any any -> any 88 (msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack"; 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:!"|a2 03 02 01 0c|"; sid:100001; rev:1;)

alert tcp any any -> any 88 (msg:"Suspicious Kerberos Packet, Possible AS-REP Roasting attack (Rubeus)"; flow: to_server, stateless; content:"|a0 07 03 05 00 40 80 00 10 a1|"; content:"|6b 72 62 74 67 74|"; fast_pattern; content:!"|a2 03 02 01 0c|"; sid:100002; rev:1;)

Outro

In this research, I demonstrated the capabilities of Suricata signatures to detect attacks on the Kerberos protocol. Kerberos is used in Active Directory networks and is much more secure than NTLM, but Kerberos security should not be overlooked.

Stay updated and engage with us on security discussions by joining our Telegram channel: @exploitorg