Hi, I’m Ahmad Mahfouz

TL;DR During an investigation into a self-hosted compromised Budibase container, I pulled core dumps from two suspicious processes sharing a parent process tree. Inside, I found two completely separate threat actors operating side by side: Actor 1 (PANOPTICON): A dead-drop Node.js implant running out of /tmp/.syshealthd.js. It pulled commands from ntfy.sh topics and self-hosted Forgejo repository issues, authenticating tasks with daily HMAC-SHA256 keys. It tried to capture internal Redis Bull queues, but failed because the Alpine container had no Python runtime. Actor 2 (Stressify Botnet): A commercial DDoS worker that resolved its active C2 address by parsing a public Telegram account bio. It deployed a 193 MB custom ELF binary (browser2_all) containing headless Chromium, an Xvfb virtual frame buffer, and a BoringSSL HTTP/2 flooder built to bypass Cloudflare Turnstile challenges. Forensic Reality: With minimal tools installed and disk state wiped, traditional filesystem triage came up empty. Process memory dumps (gcore) recovered the full unminified JavaScript source, active C2 infrastructure, and every production credential leaked through container environment variables. I packaged and open-sourced the custom Python scripts built for this analysis in eln1x/node-memory-forensics-toolkit. What Happened Minimal Alpine containers feel safe right up until they aren’t. Strip out the package manager, drop Python, pull curl, kill systemd. None of it matters if the app running inside still holds the keys to your infrastructure. When attackers get remote code execution, they don’t pack up because there’s no bash prompt. They just adapt to the runtime . ...

In large-scale enterprise environments, centralized software deployment automation provides tremendous operational efficiency for both employees and IT departments. However, delegating software installation self-service to unprivileged users introduces subtle security boundary assumptions that attackers can exploit to achieve local privilege escalation (NT AUTHORITY\SYSTEM). When standard enterprise users are permitted to initiate software installations on demand via Software Center, third-party installer packages are often executed within the SYSTEM security context. Because most commercial software installers were originally engineered assuming an interactive local administrator session rather than automated headless deployment, this architectural mismatch creates high-impact security vulnerabilities: DLL search-order hijacking, insecure temporary directory usage, and file-creation race conditions. ...

In complex enterprise networks, Active Directory is typically deployed as a multi-domain forest. An organization begins with a forest root domain (e.g., UNIXAWY.CORP) and branches into child domains for geographic regions, business units, or acquisitions (e.g., operators.unixawy.corp). A common security misconception is that a child domain functions as a security boundary. In an Active Directory forest, the forest is the only true security boundary—the domain is simply an administrative boundary. ...

Unlike stack memory which grows downward from high addresses and is automatically managed via function call frames, Heap memory grows upward from lower addresses and is managed explicitly at runtime via dynamic allocation. Understanding heap layout and allocator metadata is fundamental to analyzing heap exploitation primitives (such as use-after-free, heap overflows, fastbin dupes, and unlink exploitation). Core Allocation Primitives malloc(size): Requests size bytes from the heap and returns a generic pointer. The returned memory is uninitialized. calloc(num, size): Allocates memory for an array and initializes all bytes to zero (mitigates information disclosure bugs). realloc(ptr, size): Resizes an existing heap block, either expanding in-place or allocating a new region, copying existing data, and freeing the old chunk. free(ptr): Releases the allocated chunk back to the heap manager. Kernel Interface: brk/sbrk vs. mmap The userspace memory allocator (e.g., Glibc’s ptmalloc) interacts with the Linux kernel using two primary system calls: ...

While attempting to attach the IDA Pro debugger to a 64-bit target process on Windows (e.g., using the Local Windows Debugger or Windbg backend), you may encounter this error dialog: “The debugger could not attach to the selected process. This can perhaps indicate the process was just terminated, or that you don’t have the necessary privileges.” Even when running ida64.exe as Administrator with full High Mandatory Integrity tokens, Windows access control restrictions, process isolation (PPL/Protected Process Light), or SeDebugPrivilege token handling can prevent IDA’s GUI from attaching directly. ...

When debugging binaries during exploit development or wargames, third-party frameworks like GEF, Pwndbg, or Peda provide helpful dashboard views. However, in restricted testing environments, CTF shells, or isolated embedded targets, you may not have internet access or Python dependencies installed to run external tools. You can configure vanilla GDB to provide an automated register and stack inspection view using native define hook-stop hooks in ~/.gdbinit. Custom ~/.gdbinit Configuration Create or update ~/.gdbinit in your home directory: ...