Winpmem with mimikatz

[v3rlust]

after dumping the whole memory with winpmem xx.raw and then extract lsass.exe using volatility3 we couldn't get access to the lsass using mimikatz error always showing opening memory in mimikatz. any help ?

[vivianezw]

I'm not so sure if somebody should look into lsass.exe, that seems not nice. But let's check that Winpmem has no bugs.

Technically, there are different points in this:

1. lsass is a user process. An important process, but nevertheless a usermode process. Usermode processes get paged out. Was lsass memory resident at all?

2. Probably not the case, but: was credentials guard enabled or core isolation (HVCI) running, (with secure boot on)? A rather unlikely side case, probably it's 1. anway. Mentioned only for completeness.

3. If the memdump is not usable with Volatility 3 at all (not even 'pslists' works) then it could be a Winpmem bug, but even then it's not sure. If Volatility is able to work with the memdump in general -- fine, Winpmem is working. I think that was the case if I read correctly.

Only if Volatility fails reading the memdump at all:

• Winpmem bug
• Volality 3 not working as expected
• Volality 3 not working as expected with new Win10 builds
• Smear. Unlucky acquisition, there was too much smear on the memdump (solution: try again). The acquisition happens at IRQL 0 to not disturb the normal life on the Windows OS. This leads to an inconsistent 'smeary' memdump, and always so. (All normal Memdump tools will have this smear.) In contrast, the Memdump written by the MS bugcheck routine is running at IRQL 31 (and all CPUs on hold) and therefore will generate a perfect memdump, but at the high cost of sacrificing the running OS. Smeary memdumps are the price for not disrupting the OS heavily. Many times the smear is ok, and tools like Volatility also have been written with that in mind.