Request a ticket-granting-ticket (TGT) from a hash/key or password
asktgs
Request a service ticket from a passed TGT
renew
Renew (or auto-renew) a TGT or service ticket
brute
Perform a Kerberos-based password brute-forcing attack
asktgt
The asktgt action will build raw AS-REQ (TGT request) traffic for the specified user and encryption key (/rc4, /aes128, /aes256, or /des). A /password flag can also be used instead of a hash - in this case /enctype:X will default to RC4 for the exchange, with des|aes128|aes256 as options. If no /domain is specified, the computer's current domain is extracted, and if no /dc is specified the same is done for the system's current domain controller. If authentication is successful, the resulting AS-REP is parsed and the KRB-CRED (a .kirbi, which includes the user's TGT) is output as a base64 blob. The /ptt flag will "pass-the-ticket" and apply the resulting Kerberos credential to the current logon session. The /luid:0xA.. flag will apply the ticket to the specified logon session ID (elevation needed) instead of the current logon session.
Note that no elevated privileges are needed on the host to request TGTs or apply them to the current logon session, just the correct hash for the target user. Also, another opsec note: only one TGT can be applied at a time to the current logon session, so the previous TGT is wiped when the new ticket is applied when using the /ptt option. A workaround is to use the /createnetonly:C:\X.exe parameter (which hides the process by default unless the /show flag is specified), or request the ticket and apply it to another logon session with ptt /luid:0xA...
By default, several differences exist between AS-REQ's generated by Rubeus and genuine AS-REQ's. To form AS-REQ's more in line with genuine requests, the /opsec flag can be used, this will send an initial AS-REQ without pre-authentication first, if this succeeds, the resulting AS-REP is decrypted and TGT return, otherwise an AS-REQ with pre-authentication is then sent. As this flag is intended to make Rubeus traffic more stealthy, it cannot by default be used with any encryption type other than aes256 and will just throw a warning and exit if another encryption type is used. To allow for other encryption types to be used with the /opsec changes, the /force flag exists.
Requesting a ticket via RC4 hash for dfm.a@testlab.local, applying it to the current logon session:
The asktgs action will build/parse a raw TGS-REQ/TGS-REP service ticket request using the specified TGT /ticket:X supplied. This value can be a base64 encoding of a .kirbi file or the path to a .kirbi file on disk. If a /dc is not specified, the computer's current domain controller is extracted and used as the destination for the request traffic. The /ptt flag will "pass-the-ticket" and apply the resulting service ticket to the current logon session. One or more /service:X SPNs must be specified, comma-separated.
The supported encryption types in the constructed TGS-REQ will be RC4_HMAC, AES128_CTS_HMAC_SHA1, and AES256_CTS_HMAC_SHA1. In this case, the highest mutually supported encryption will be used by the KDC to build the returned service ticket. If you want to force DES, RC4, or AES128/256 keys, use /enctype:[RC4|AES128|AES256|DES].
In order to request a service ticket for an account using an enterprise principal (i.e. user@domain.com), the /enterprise flag can be used.
By default, several differences exist between TGS-REQ's generated by Rubeus and genuine TGS-REQ's. To form TGS-REQ's more in line with genuine requests, the /opsec flag can be used, this will also cause an additional TGS-REQ to be sent automatically when a service ticket is requested for an account configured for unconstrained delegation. As this flag is intended to make Rubeus traffic more stealthy, it cannot by default be used with any encryption type other than aes256 and will just throw a warning and exit if another encryption type is used. To allow for other encryption types to be used with the /opsec changes, the /force flag exists.
Requesting a TGT for dfm.a and then using that ticket to request a service ticket for the "LDAP/primary.testlab.local" and "cifs/primary.testlab.local" SPNs:
The renew action will build/parse a raw TGS-REQ/TGS-REP TGT renewal exchange using the specified /ticket:X supplied. This value can be a base64 encoding of a .kirbi file or the path to a .kirbi file on disk. If a /dc is not specified, the computer's current domain controller is extracted and used as the destination for the renewal traffic. The /ptt flag will "pass-the-ticket" and apply the resulting Kerberos credential to the current logon session.
Note that TGTs MUST be renewed before their EndTime, within the RenewTill window.
The /autorenew flag will take an existing /ticket:X .kirbi file/blob, sleep until endTime-30 minutes, auto-renew the ticket and display the refreshed ticket blob. It will continue this renewal process until the allowable renew-till renewal window passes.