Writeups & Research

An administrator-created backup folder ran a scheduled task every 5 minutes against a binary that any writer could replace — turning a routine backup job into a repeating code-execution trigger.

An open Squid proxy was the only way to reach an internal WAMPServer install. From there, a MySQL INTO OUTFILE query wrote a webshell straight into the web root, leading to a SYSTEM shell via FullPowers and PrintSpoofer.

The global Startup folder, which runs a shortcut for every user who logs in, was writable by a standard account. A malicious shortcut dropped there ran under the next administrator's session.

A service account held SeImpersonatePrivilege — a token privilege that, on its own, is enough to reach SYSTEM. Covers three separate tools for exploiting it: PrintSpoofer, RoguePotato, and GodPotato.

A GUI application was running under a privileged account on the same desktop session. Its file dialog box provided a fully functional path to spawn a command prompt under that same privileged context.

A program registered in the Windows AutoRun registry key was writable by a low-privileged user. Replacing it and waiting for a privileged user to log in was enough to get their shell.

An insecure backup of the SAM and SYSTEM registry hives allowed offline extraction of every local account's NTLM hash. One of those hashes was usable for authentication directly, without ever needing the plaintext password.

A scheduled task ran a cleanup script as SYSTEM every minute. The script file itself was writable by a standard user, turning a routine maintenance task into a privilege escalation path.

Two unrelated but equally direct Windows misconfigurations: credentials cached by the Windows Credential Manager, and an installer policy that runs every MSI package as SYSTEM.

A Windows service's registry key allowed modification by any interactive user. Changing one registry value was enough to reconfigure the service and execute code as SYSTEM.

A LocalSystem service's binary file was writable by the Everyone group. Overwriting it directly, with no registry or service-configuration changes at all, was enough to get a SYSTEM shell.

No writable folder, no unquoted path, no file to hijack — just a service whose own permissions let a standard user reconfigure and restart it. That was enough to mint a brand-new local administrator.

A Windows service was configured to run from a path containing spaces, with no quotes around it. That one omission was enough to hijack the service and land a SYSTEM shell.

No exploit, no chaining, no CVE — just the word 'elastic' typed twice. That's all it took to get full superuser access to a live Elasticsearch cluster holding tens of thousands of business records.

A website that renders and screenshots any URL you give it never restricted the URL scheme. Swapping https:// for file:// let me pull the target's /etc/passwd straight into the captured image.

The SUID bit set on /usr/bin/find turned a routine enumeration pass into an instant root shell, no exploit development required.

A sudo rule scoped to make install on a specific project directory looked safe, until I realized I could edit the Makefile itself and override the install target with a root shell.

A misconfigured file ownership left /etc/passwd writable by a regular user, so I appended a brand-new UID 0 account and simply switched into it.

A custom monitoring wrapper gated by a hardcoded authorization key looked secure at a glance — until I found the key sitting in plaintext and used it to spawn a root shell through sudo.

A wildcard in a sudoers entry for Composer let me sidestep its working-directory restriction entirely — one exec command later, I had a root shell.

A cleanup script under /var/www ran on a schedule as root — and was still owned and writable by the same www-data account that owned the compromised web app sitting next to it.

A NOPASSWD sudo rule let me run a niche web app's own server as root. A path-traversal bug in that app's file-serving code turned into arbitrary root-owned file read — and a stolen SSH key.

A root cron job quietly archived uploads with a password pulled from /root/secret — and passed it on the command line, where any local user watching /proc could read it in plaintext.

A single NOPASSWD sudo rule for `systemctl status` looks harmless until you remember that systemctl pipes long output through less — and less will happily drop you into a root shell.

LinPEAS flagged a pair of writable Openfire log paths, but the real prize was buried in the embedded database's SQL script — a plaintext SMTP password that turned out to unlock root too.

A root-owned cron job silently swapped hidden files into /bin whenever a matching binary already existed there. Combined with a NOPASSWD sudo rule on that same binary, it became a clean root shell.

A cron job running as root pointed at a shell script with excessive write permissions. Overwriting it with a reverse shell payload and waiting was all it took.

A NOPASSWD sudo rule on /usr/bin/env looks harmless until you remember that env's entire job is to launch other programs — with whatever environment and privileges it's given.

A client-side JavaScript bundle quietly shipped an OAuth client secret. Four curl commands later, an anonymous visitor held a valid Bearer token with full read, write, and delete rights over a live financial services API.

An SMTP service bound to localhost turned out to be more than just a listening port — the local mail spool it fed was readable, and root had left credentials sitting inside it.

A sudoers rule let me run a Ruby script as root with no password. The problem was I could edit that script — so I made it run whatever I wanted.

A reused username-as-password combo got me a local shell. One sudo -l later, I found a sudoers entry granting unrestricted command execution — game over.

A sudo rule scoped to one specific script sounds safe, until you realize you can write to the application code that script launches. Here's how I turned a Flask password-change tool into a root shell.

An RPC service bound to localhost isn't safe just because it's unreachable from outside — pivot into the loopback interface and a pickle deserialization bug hands you root.

You can't see other users' processes without root — unless you use a tool that doesn't ask the kernel for permission first. Here's how pspy64 exposed a root cron job I could hijack for a reverse shell.

A sudo rule on Debian's package manager looks harmless until you remember apt-get shells out to a pager. One overlooked entry in sudo -l, one GTFOBins trick, full root.

A SUID bit on a debugging tool most people never think to lock down. Here's how a stray strace binary turned a www-data shell into full root in two commands.

A low-privilege user in the disk group doesn't need file permissions at all — it can read the raw block device. Here's how I used debugfs to pull /etc/shadow straight off an LVM volume and cracked my way to root.

A LinPEAS scan flagged python3.10 carrying the cap_setuid capability — enough on its own to call setuid(0) and drop straight into a root shell.

A NOPASSWD sudo rule on the service command looked harmless until GTFOBins showed how a relative path can escape it straight into a root shell.

Automated enumeration with LinPEAS turned up a plaintext password sitting in a web application's config file — and that password happened to work for root too.

A sudo rule that let me run tar with a wildcard turned into arbitrary command execution as root, thanks to tar's checkpoint feature and a couple of carefully named files.

A stray directory of SSH keys inside a user's home folder turned out to contain root's private key — the only obstacle was SSH trying every other key first.

A NOPASSWD sudo rule for gcore let me dump the memory of a root-owned process and pull a plaintext password straight out of the core file.

A file upload form that ran every image through ExifTool became a root shell, once I disguised a malicious DjVu file as a harmless .jpg.

sudo -l said I had no rights on this box at all. A single -h flag with the right hostname string said otherwise, and handed me root.

A NOPASSWD sudo rule for needrestart looked harmless until I traced how it inspects running interpreters — a crafted shared object turned that scan into a root shell.

No SUID binaries in sight, but a capability check told a different story: Python had cap_setuid, and that was more than enough to become root.

Two different lab boxes, one recurring mistake: the same password protecting a low-privilege account also unlocked root. Here's the enumeration habit that catches it every time.

A routine SUID sweep on a lab box turned up something I don't see often: the SUID bit set directly on /bin/bash. One flag later, I had a root shell.

A profile endpoint that fetched user data by ID from the request parameter — with no ownership check — allowed any authenticated user to read any other user's private information.

A webhook testing feature that fetched user-supplied URLs with no validation allowed an attacker to proxy requests through the server — reaching internal services, cloud metadata endpoints, and sensitive infrastructure.

A custom CDN middleware implementation with a flawed caching strategy allowed any unauthenticated user to poison the cache and retrieve sensitive account data belonging to other users.

A login form built with raw string concatenation instead of parameterized queries allowed complete authentication bypass and full database extraction — one of the most exploited vulnerabilities in real-world penetration testing.

A PHP file inclusion pattern with zero input validation allowed an attacker to read arbitrary files from the server filesystem — including sensitive configuration files and system credentials.

During a lab exercise I landed a shell as www-data. A quick SUID enumeration revealed php7.4 with the SUID bit set. Here's how I went from a low-privilege web shell to full root access.

What started as a weird error message in a file download API turned into reading /etc/passwd off a production server. Here's the full story.

During a network pentest I found port 9100 open on an internal host. Turned out to be an HP LaserJet MFP. Here's how I enumerated it using raw PJL commands and what it exposed.

A custom deep merge utility passed user-controlled input directly into object property assignment — allowing an attacker to pollute JavaScript's Object prototype and escalate to remote code execution.

An Import/Export feature accepting XML files led to a Java deserialization vulnerability. By crafting a malicious XML payload using ProcessBuilder, I achieved remote code execution as NT AUTHORITY\SYSTEM.

A product search endpoint that accepted XML input had no entity processing restrictions. By injecting a malicious external entity, I read internal server files on both Linux and Windows targets.

An administrative console exposed a TCL script execution interface with no input sanitization. What was designed for internal diagnostics became a direct path to remote code execution as NT AUTHORITY\SYSTEM.

No login bypass, no injection — just a static JavaScript file, sitting in plain sight, quietly shipping a username and password to anyone who opened DevTools.