https://blog.kernelstub.dev/tags/rootkits/Recent content in Rootkits on Prepakis Georgios | Kernelstub | Security ResearcherHugoen-USFri, 04 Oct 2024 00:00:00 +0000https://blog.kernelstub.dev/posts/domain-generation-algorithms-and-automatic-domain-registration-in-c2/Fri, 04 Oct 2024 00:00:00 +0000https://blog.kernelstub.dev/posts/domain-generation-algorithms-and-automatic-domain-registration-in-c2/<h2 id="what-is-a-domain-generation-algorithm-dga">What Is a Domain Generation Algorithm (DGA)?</h2> <p>If you&rsquo;re running a botnet, you have a problem: your infected hosts need a way to phone home, but the moment defenders find your command and control (C2) domain, they blocklist it, sinkhole it, or hand it to a takedown request, and your whole fleet goes dark at once. A single hardcoded IP or domain baked into your malware is a single point of failure, and it&rsquo;s the first thing an incident responder goes looking for when they pull apart a sample in a sandbox.</p>https://blog.kernelstub.dev/posts/custom-linux-kernel-hooks-with-ebpf/Wed, 02 Oct 2024 00:00:00 +0000https://blog.kernelstub.dev/posts/custom-linux-kernel-hooks-with-ebpf/<h2 id="understanding-ebpf">Understanding eBPF</h2> <h3 id="what-is-ebpf">What is eBPF?</h3> <p>If you&rsquo;ve ever wanted to peek inside a running Linux kernel without recompiling it, patching it, or crossing your fingers and loading a sketchy out-of-tree module, eBPF is probably the tool you were looking for. The name is short for &ldquo;extended Berkeley Packet Filter,&rdquo; which is a bit of a historical accident: the original BPF, from the late 1980s, was a tiny virtual machine built to do one job, deciding whether a network packet matched a filter (think <code>tcpdump</code>). It was small, fast, and deliberately dumb, which made it safe to run inside the kernel.</p>https://blog.kernelstub.dev/posts/introduction-to-windows-syscalls/Tue, 17 Sep 2024 00:00:00 +0000https://blog.kernelstub.dev/posts/introduction-to-windows-syscalls/<h2 id="what-are-system-calls-really">What Are System Calls, Really?</h2> <p>Every time your program does something that touches the outside world, opening a file, allocating memory, talking to the network, waiting on another thread, it&rsquo;s asking the operating system to do that work on its behalf. Your program doesn&rsquo;t get to poke the disk controller or the network card directly. It can&rsquo;t, by design. The CPU itself enforces this separation through privilege rings: user-mode code (ring 3 on x86/x64) runs with a restricted set of permissions, while the kernel (ring 0) runs with full access to hardware and memory. A system call is the formal, controlled doorway between those two worlds.</p>https://blog.kernelstub.dev/posts/hooking-getdents64-to-hide-directories-in-linux/Wed, 05 Jun 2024 00:00:00 +0000https://blog.kernelstub.dev/posts/hooking-getdents64-to-hide-directories-in-linux/<h2 id="why-directory-hiding-even-works">Why Directory Hiding Even Works</h2> <p>Every time you run <code>ls</code> in a terminal, or a graphical file manager draws a folder icon, something has to ask the kernel &ldquo;what&rsquo;s in this directory?&rdquo; On Linux that question gets answered by the <code>getdents64</code> syscall (the modern replacement for the older <code>getdents</code>). The C library wraps it up neatly, but underneath, every single directory listing you have ever seen on a Linux box came from a userspace program calling into the kernel and getting back a buffer full of <code>linux_dirent64</code> structures, one per file or subdirectory.</p>