Home on Prepakis Georgios | Kernelstub | Security Researcher

A Full Infrastructure Takeover on GSIS.GR

Mon, 16 Feb 2026 00:00:00 +0000

Table of Contents

Phase 1: Massive Reconnaissance with SkuntScan
Phase 2: The Exposed Configuration That Broke Everything
Phase 3: FTP and the Forgotten Server
Phase 4: Oracle webCenter Leaks and LDAP Access
Phase 5: Hardcoded JWT Private Key
Phase 6: Server-Statme as a Network Mapping Tool
Phase 7: IIS Short Names and ASP.NET Backend
Phase 8: Domibme 4.2.4 – Finding the Zero-Day
Phase 9: From XXE to SSH on boris.gsis.gr
Phase 10: Axis2 Admin Service – Deploying a Backdoor
Phase 11: Privilege Escalation to Root
Phase 12: Internal Network Pivot – The 10.193.18.0/24 Discovery
Phase 13: STAGING-AUTHENTIX-AUTH and the Database Goldmine
Phase 14: Switches, Firewalls, and Control Surfaces
Phase 15: 15 Million Citizens – What I Found

Phase 1: Massive Reconnaissance with SkuntScan

Every engagement starts with comprehensive reconnaissance. SkuntScan, our in‑house tool, combines passive enumeration with intelligent fingerprinting. It scrapes certificate transparency logs, DNS records, web archives, and then correlates everything with IP space to build a complete map of the target.

Reverse Engineering a 2012 Toyota Yaris: From OBD-II to Exploit Chain

Fri, 06 Feb 2026 00:00:00 +0000

Chapter 1: Introduction and Laboratory Setup

I picked a 2012 Toyota Yaris for this project mostly because of what it isn’t: it’s not a flagship, it’s not loaded with the kind of aftermarket telematics and OTA update infrastructure that makes modern vehicles a moving target for remote attacks, and it’s cheap enough on the used market that I could buy one, break it, and not lose sleep over it. That’s actually the point. Cars like this one make up a huge chunk of the vehicles still on the road today, and the electronics inside them were designed in an era when “attack surface” mostly meant “whoever plugs a scan tool into the OBD-II port at a dealership.” Nobody was thinking about buffer overflows delivered over a CAN frame. That assumption, it turns out, ages badly, and this post walks through exactly how badly.

How I Built an Off-Grid Meshtastic LoRa Radio

Sun, 18 Jan 2026 00:00:00 +0000

I wanted a way to send text messages across kilometers of terrain without a cell tower, without Wi-Fi, and without paying anyone a monthly fee for the privilege. That’s basically the pitch for Meshtastic: cheap LoRa radios that form a self-healing mesh network and pass short messages, GPS positions, and telemetry from node to node. Pair that with solar power and you get something that can sit on a hilltop indefinitely, which is exactly what I set out to build. This post walks through the whole thing: the hardware, the firmware, the antenna theory I had to relearn the hard way, and what I’d change next time.

Comparing tfsec and Checkov for Hardening Infrastracture

Wed, 12 Nov 2025 00:00:00 +0000

Why IaC Hardening Matters

Here’s the thing about infrastructure as code that makes it both wonderful and terrifying: once you write a mistake into a Terraform module, that mistake doesn’t stay put. It gets copied. A junior engineer finds your s3-bucket module in the internal registry, sees it’s already “battle tested,” and reuses it in three more projects without reading past the variable names. If that module happened to leave logging disabled or granted a role "*" on "*", you haven’t made one mistake, you’ve made a template for making that mistake forever.

Decoding Auto Negotiation and Duplex Mismatch at the PHY Layer

Fri, 07 Nov 2025 00:00:00 +0000

Understanding the Physical Layer (PHY)

If you’ve ever chased down a “the network is slow but only sometimes and only in one direction” ticket, there’s a good chance the real culprit was sitting quietly at Layer 1, way below anything a ping or traceroute will show you. That’s the world of the PHY chip, the piece of silicon on every Ethernet interface that actually puts bits onto the wire and pulls them back off again.

From Bits to Breaks A Low Level System Exploitation and Defense

Sat, 25 Oct 2025 00:00:00 +0000

Introduction and Scope

Here’s the core question driving this whole project: how do software and hardware actually interact once you strip away the abstraction layers that normally hide the messy details from you? Compilers, operating systems, and runtimes exist precisely so you can forget about page tables, cache lines, and instruction pipelines while you get work done. Attackers, and the researchers trying to stay ahead of them, don’t get that luxury. Every exploit involving memory corruption, firmware, or a leaky microarchitectural feature lives exactly at that seam between the code you wrote and the silicon actually running it. This research examines that seam systematically, aiming to produce techniques reproducible enough to be useful, rigorous enough to be academically sound, and constrained enough to stay ethically defensible.

Advanced Linux Kernel Exploitation Techniques

Thu, 27 Mar 2025 00:00:00 +0000

Introduction to Linux Kernel Exploitation

Kernel exploitation sits at the top of the difficulty curve in offensive security, and for good reason. Userspace bugs get you code execution as some unprivileged process, but the kernel runs at Ring 0 (or EL1, if you’re on ARM) with unrestricted access to physical memory, every process’s address space, and every privilege check on the system. Pop a bug in the kernel and you’re not just compromising an application, you’re compromising the thing that enforces the rules for every application on the box. That’s why a single kernel LPE (local privilege escalation) bug is often worth more on the exploit market than a browser RCE: it’s the last mile between “I have a foothold” and “I own the machine.”

Advanced Windows Kernel Debugging Techniques

Mon, 10 Mar 2025 00:00:00 +0000

Kernel debugging is a different animal from the user-mode debugging most developers grow up with. You can’t just attach a debugger to a live kernel the way you’d attach to a misbehaving process, because the kernel is the thing that’s supposed to be managing every process on the box, including the debugger’s own. If it halts, everything halts. So Windows solves this the old-fashioned way: two machines. One is the “target,” the system whose kernel you actually want to inspect. The other is the “host,” running WinDbg, connected over a transport that survives the target being frozen mid-instruction: a network link, a serial cable, or USB. When you set a breakpoint and it hits, the entire target machine stops, not just one process, and control passes to your host over that wire. That’s the mental model to keep in the back of your head for everything that follows: you’re not debugging a program, you’re debugging an operating system from the outside, one machine talking to another.

Advanced Cryptography Concepts via Classical to Post-Quantum

Tue, 14 Jan 2025 00:00:00 +0000

Cryptography has a strange history for a field that’s now load-bearing for the entire internet. A lot of the number theory underneath it was developed by mathematicians who were doing pure math for its own sake, with zero interest in secrets or spies. Then, starting in the 1970s, people realized that certain “hard” problems in number theory (the kind that are easy to state but brutal to solve at scale) were exactly what you needed to build systems where two strangers could agree on a secret over a public channel, or where you could prove your identity without ever handing over a password. This post is a walk through that stack, from the classical number-theoretic foundations, through the protocols built on top of them, and finally into the post-quantum schemes that exist because a sufficiently large quantum computer would tear a hole through most of what came before.

Introduction to Quantum Computing

Tue, 14 Jan 2025 00:00:00 +0000

Quantum computing gets talked about like it’s some kind of magic trick: a machine that tries every answer at once and just knows the right one. That’s a fun story, but it’s not really what’s happening, and understanding why it’s not what’s happening is the fastest way to actually get quantum computing instead of just repeating buzzwords about it. So let’s slow down and build this up from the physics, piece by piece, and see how it turns into something you can actually run algorithms on.

Domain Generation Algorithms and Automatic Domain Registration in C2

Fri, 04 Oct 2024 00:00:00 +0000

What Is a Domain Generation Algorithm (DGA)?

If you’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’s the first thing an incident responder goes looking for when they pull apart a sample in a sandbox.

Custom Linux Kernel Hooks with eBPF

Wed, 02 Oct 2024 00:00:00 +0000

Understanding eBPF

What is eBPF?

If you’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 “extended Berkeley Packet Filter,” 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 tcpdump). It was small, fast, and deliberately dumb, which made it safe to run inside the kernel.

Introduction to ARM Architecture

Sat, 21 Sep 2024 00:00:00 +0000

If you’ve spent any time around x86 assembly and then gone to look at ARM, the first thing you probably noticed is how much cleaner it feels. That’s not an accident. ARM was designed from day one around a philosophy called RISC (Reduced Instruction Set Computer), which trades a huge, irregular menu of complex instructions for a small set of simple, fast, predictable ones. Instead of one instruction doing five things at once (the CISC way, which is how x86 grew up), ARM prefers to do those five things as five simple instructions, each of which the CPU can execute in a single, predictable cycle. This sounds like it should be slower, and instruction-for-instruction it sometimes is, but it makes the hardware simpler, cheaper to build, and dramatically more power efficient, which is exactly why ARM ended up running basically every phone, tablet, and now a growing share of laptops and servers on the planet.

Introduction to x64 ASM

Sat, 21 Sep 2024 00:00:00 +0000

1. Introduction to Assembly and x64 Architecture

What is Assembly Language?

Every program you’ve ever run, whether it’s a shell script, a Python interpreter, or a AAA game engine, eventually gets reduced to a stream of raw binary instructions that a CPU can execute directly. Assembly language is the thin, human-readable layer sitting right on top of that binary stream. Each assembly instruction maps almost one-to-one to a single machine instruction, so when you write mov rax, rbx, you’re really just writing a mnemonic for a specific sequence of bits that tells the processor “copy the contents of one register into another.” There’s no compiler doing clever things behind your back, no garbage collector, no runtime. What you write is (almost) exactly what runs.

Introduction to Windows Syscalls

Tue, 17 Sep 2024 00:00:00 +0000

What Are System Calls, Really?

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’s asking the operating system to do that work on its behalf. Your program doesn’t get to poke the disk controller or the network card directly. It can’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.

Linux Syscalls Table (x86-64)

Fri, 13 Sep 2024 00:00:00 +0000

Overview

Every time a program on Linux does something that touches the outside world, reading a file, allocating memory, sending a packet, spawning another process, it eventually has to ask the kernel to do it. User space code can’t just reach into the kernel’s data structures and start editing process tables or filesystem metadata; that would be a security and stability nightmare. Instead, it has to go through a narrow, well-defined door: the system call interface. This post is a reference table for that door on x86-64 Linux, listing every syscall number, its libc-facing name, its man page, and the kernel function that actually handles it once your program’s request lands.

Advanced C Programming Best Practices

Mon, 29 Jul 2024 00:00:00 +0000

C gives you almost nothing for free. There’s no garbage collector cleaning up after you, no runtime checking your array bounds, no exception handler catching your mistakes before they corrupt memory. That’s exactly why C is still the language of choice for operating systems, embedded firmware, and anything that needs to talk directly to hardware, and it’s also exactly why C code has such a long, embarrassing history of security vulnerabilities. The language trusts you completely. Most of “best practices in C” really boils down to one idea: build habits and guardrails that compensate for the safety net the language refuses to provide.

Hooking `getdents64` to Hide Directories in Linux

Wed, 05 Jun 2024 00:00:00 +0000

Why Directory Hiding Even Works

Every time you run ls in a terminal, or a graphical file manager draws a folder icon, something has to ask the kernel “what’s in this directory?” On Linux that question gets answered by the getdents64 syscall (the modern replacement for the older getdents). 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 linux_dirent64 structures, one per file or subdirectory.