How does Windows Credential Patching work?

[Lagg3l]

First off, thanks for your hard work on this project, it has been a pleasure to work with! I would like to contribute to the cause, but since I am a university student, I'd prefer a conventional donation over a subscription (Students be broke) - Please let me know about corresponding options.

Specs: [Screamer M.2 R04 - PCILeech-FPGA gateware ver. 4.7 & Windows 10 Pro control computer using PCILeech 4.8]

I am currently playing around with credential patching on a Windows 10 Professional target PC (20H2 - 19042.928). IOMMU (Intel VT-d) is disabled in BIOS and Windows Kernel DMA Protection Off. Credential Patching works fine:

PS C:...\PCILeech> ./pcileech patch -sig unlock_win10x64 -all

Current Action: Patching Access Mode: Normal Progress: 33528 / 33528 (100%) Speed: 48 MB/s Address: 0x000000082F800000 Pages read: 8337056 / 8583168 (97%) Pages failed: 246112 (2%) Patch: Successful. Location: 0x132e9e435

Now i am wondering how exactly this patch works, i have been reading the CLI inline help page as well as the corresponding signature file. Out of curiosity, i dumped corresponding registry hives using mimikatz after patching the target and logging onto the session and noticed the NTLM hash of the user was still the ''old'' one (corresponding to the password set for the target).

So my guess is that my initial take was wrong, assuming PCILeech would simply overwrite the NTLM hash in the SAM in memory with the hash of an empty string - So that when MSV1_0 (Windows Auth. Package) compares the empty user-entered password upon logon with the one retrieved from the SAM, it would match and an access token would be issued.

Or does it manipulate the authentication process itself, similar to this publication on Windows Vista: 2008 Publication on Vista physical attacks

I am looking forward to your response. Kind Regards, Lagg3l

[ufrisk]

It's super nice to see you're looking into DMA; please let me know if you should run into some other issues as well.

In Windows 10 I patch the function NtlmShared.dll!MsvpValidatePassword. I change a jz instruction to a jnz. This inverts the result of the password check. If you provide the correct password you won't be logged on... This patch does not affect the rest of the system really.

In earlier versions (Win7 and such) I NOP out an instruction in this function. That also caused the password to change for the user in some occurrences; but that's not the case with Win10.

And Thank You for considering to sponsor my project. Currently I only do the Github Sponsors. It's super nice since Github is matching any sponsored amount towards my project. A $10 sponsorship is $20 to my project for most parts (except for very newly created accounts when it's a ordinary sponsorship). Seeing you have a new account you could change your "billing cycle" to yearly and make the sponsorship and then cancel it. That way you would stay as a sponsor for a whole year. Huge thanks for sponsoring 💖

[Lagg3l]

Thank you so much, that helps a lot! On a not-so-related side note, how would I go about finding out the reason why my (successful) memory dumps using the same setup run into ~2% page failures at the end of the dumping process? (Has to be some kind of memory region that is not accessible, since the behavior is exactly reproducible across multiple dumps on multiple OS'es):

PS C:...\PCILeech> ./pcileech dump -out "C:\MyDumps\TestDump" -v -vv -device fpga

DEVICE: FPGA: ScreamerM2 PCIe gen2 x1 [300,25,500] [v4.7,0100] [ASYNC,NORM]

[...]

LcMemMap_AddRange: 0000000000000000-000000000009ffff -> 0000000000000000 LcMemMap_AddRange: 0000000000100000-000000082f7fffff -> 0000000000100000 LeechCore v2.5.2: Open Device: fpga Memory Dump: Initializing ... Done. Memory Map: START END #PAGES 0000000100000000 - 000000082f7fffff 0072f800 0000000000000000 - 000000000009ffff 000000a0 0000000000100000 - 00000000c3efffff 000c3e00

Current Action: Dumping Memory Access Mode: Normal Progress: 33528 / 33528 (100%) Speed: 47 MB/s Address: 0x0000000100000000 Pages read: 8337056 / 8583168 (97%) Pages failed: 246112 (2%) Memory Dump: Successful.

My guess was some kind of Processor Reserved Memory Region (Intel i5 9500 - Intel SGX & Management Engine is turned off in BIOS).

In regards to the sponsorship - I will do that ASAP, because Lambdaconcept is earning mad money thanks to your work, which is kinda unfair tbh.

[ufrisk]

Huge thanks for the generous 1 year sponsorship 💖

The failed memory region is related to memory mapped I/O - memory that belongs to PCIe devices and such and not RAM. Its size may differ around different systems but this is perfectly normal.

[Lagg3l]

Thanks again, closing the issue - I am fully satisfied :)

[ufrisk]

Awesome :) and best wishes with your DMA research. Please let me know if you should run into something or have any questions in the future.