Introduction About Rubeus
Rubeus is a C# toolkit designed to handle Kerberos interactions and breaches. It is well knowledge that Active Directories employ Kerberos, a ticket-based network authentication mechanism. Sadly, human mistake frequently results in AD configurations that do not prioritize security. In addition to creating keys and providing access with false certificates, Rubeus is capable of taking advantage of security holes created by these setup errors. Using Rubeus in different contexts is explained in the article.
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
The KDC (Kerberos Distribution Center) service is a domain controller service in the Active Directory domain that handles all ticket requests to Kerberos. Using the KRBTGT account in the AD domain, AD handles Kerberos tickets.
The above table defines the unique components that are used throughout the process, and the figure below illustrates the key function that KDC plays in creating a secure connection between the server and client.
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
A service instance’s unique identification is the Service Principal Name (SPN). Service Principal Names (SPNs), essential elements of the Kerberos process by which a client authenticates a service, are supported by Windows and Active Directory Domain Services.
- Scanning Webservers with Nikto for vulnerabilities
- Google Dorks and How Hackers Use
- How to Find and Use Public Exploit Code
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
Perhaps the idea for the name, Cerberus, a three-headed hound from Greek mythology, sounds a lot like Kerberos. A three-headed dog named “fluffy” that belonged to and was under the custody of Hagrid, whose full name was Rubeus Hagrid, is also mentioned in Harry Potter. Developed by Will Schroeder and a few other collaborators, Rubeus is a program that assaults Kerberos and can generate raw Kerberos data on UDP port 88. The name of the tool is a creative play on Sci-Fi and mythology. It is based on the Make Me Enterprise Admin and Mimikatz projects. You may get it from this link.
It should be noted that the latest Rubeus binary may be produced from code using Visual Studio, but there is also an easier-to-use distribution available here.
Detection: Its signatures are automatically banned by many anti-virus programs because they employ generic functions and are derived from the Mimikatz (a malware family classified as kekeo by CARO) and set procedures. Furthermore, because Rubeus functions as a dropped executable, a cunning attacker must obfuscate Rubeus in order to conceal its detection as soon as it is dropped onto the disk.
It may be downloaded and then dumped into the victim’s computer to be used.
rubeus.exe
Now that we have set it up, we are ready to demonstrate various options in Rubeus.
Ticket Operations
In an Active Directory context, different tickets are necessary for operation. For instance, the KDC issues Ticket Granting Tickets, which are authentication tokens used to ask TGS for access to particular resources.
We will discuss Rubeus and its ability to manipulate tickets in this part.
Asktgt
rubeus.exe asktgt /user:harshitrajpal /password:Password@1
As seen above, a KRBTGT has been successfully formed and may be utilized to produce TGS in the future. Giving someone an encrypted password will do the same thing. Let us utilize an RC4-encrypted password.
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.localWe have successfully produced a TGS by including the information from the TGT we generated in the previous stage (copying in notepad and eliminating entries to type the ticket on a single line).
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
/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
As you may now observe that after a 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, the same password is used with multiple accounts in real-life enterprise infrastructure. So, brute option can generate multiple TGTs in those accounts having the same password. /noticket can be used in conjunction with this option since no ticket is provided with this functionality. For example,
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.
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: 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
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
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.
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
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,
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.
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.
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.
Also, when the LUID is known, we can purge particular user’s tickets too (elevated mode only)
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.
For a specific service like only 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:
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.
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
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.
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
/aes flag can be used to roast all AES enabled accounts while using KerberosRequestorSecurityToken
Alternate domain credentials to perform Kerberoasting and searching for users to kerberoast can be done using the /creduser and /credpassword
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
/rc4opsec: tgtdeleg trick is used and accounts without AES enabled are roasted.
/simple: hashes are output in the console one per line
/nowrap: with this option Kerberos results will not be line wrapped
/outfile: Can be used to store the hash in an output file
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
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.
/domain and /dc are optional flags that can be used to explicitly define the domain and controller accounts.
/outfile can be used to save this hash in an output file.
If /ldaps is used, LDAP query shall go over secured LDAP (port 636)
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.
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.
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.
As you can see, Mufasa had the same password as harshitrajpal and his password got changed.
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.
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.
Author: JDsingh is an InfoSec researcher and left and right brain thinker.