jperezduerto.info
Hacking techniques
Specific offensive techniques, how they work and where to apply them, each with a proof of concept on GitHub.
-
PHP2Shell: how a session upload progress field turns PHP 8.4 into an unauthenticated RCE
CVE-2026-109618 and CVE-2026-109619 live inside the PHP runtime, not in any application. A plain multipart POST with a PHP_SESSION_UPLOAD_PROGRESS field exercises the vulnerable rfc1867 upload callback, and when an attacker crosses memory_limit mid-request the engine's longjmp bail-out leaves dangling bucket pointers that re-emerge on the next request to the same worker. The leak comes back inside Set-Cookie, a forged HashTable turns pDestructor into a one-shot system(), and no application code is involved. This is the walk-through, step by step, with the pieces most public PoCs get wrong.
-
SMB, fully explained: from anonymous access to NTLM relay, and how to lock it down
SMB is the protocol Windows networks are built on, and the one attackers reach for first. This explains why SMB exists, how Microsoft has carried it for forty years, the exploits that made an exposed port 445 a standing liability, and then walks the attack from an anonymous null session through share and user enumeration, password spraying, authenticated code execution, and finally NTLM relay. The back half is the whole point: exactly how a defender signs, filters, strips, and audits SMB until none of it works.
-
Relaying application-protocol NTLM, and stealing logged-on tokens
Two lateral-movement primitives that defeat the usual mental model. First: NTLM carried by an application protocol (IMAP, SMTP, MSSQL, LDAP, HTTP) can be captured by a rogue server and bridged into a relay, so the relay source is not only SMB coercion. Second: once you hold SYSTEM on a host where a privileged user is logged on, you can impersonate their token without touching LSASS, which is why Credential Guard and LSA protection do not stop it. Both come with the controls that break them.
-
Cross-forest Kerberoasting: how a forest trust lets you roast service accounts in a domain you do not belong to
Kerberoasting is usually taught inside one domain. But a bidirectional forest trust lets an account in your forest request service tickets for accounts in the other forest, so a single foothold can roast privileged service accounts across the trust boundary. This is a teaching walkthrough: it builds the mental model of what a trust actually shares, shows the request step by step, gives you a two-forest lab to reproduce it safely, and ends with the detection and the one fix that closes it.
-
Server Operators to Domain Admin: why a forgotten built-in group is tier-0 on a domain controller
BUILTIN\Server Operators looks like a mild help-desk group, so service accounts get dropped into it for convenience. On a domain controller it is effectively Domain Admin, because it can reconfigure a service to run as SYSTEM and it carries SeBackupPrivilege. This teaching walkthrough builds the intuition for why the group is tier-0, shows both escalation routes step by step, gives you a lab to prove it, and ends with the group hygiene that closes it.
-
Four misconfigurations, no CVE: the over-privileged service-account chain that takes a whole forest
Some of the cleanest domain compromises use no exploit at all. A kerberoastable service account with a weak password, an over-broad ReadGMSAPassword right, a managed account parked in a privileged group, and a backup privilege on a domain controller chain into full forest compromise, and the chain even crosses a forest trust. This teaching walkthrough builds the chain link by link, explains why each one exists, gives you a lab to reproduce it, and makes the defender's point: break any single link and the chain stops.
-
A leaked machineKey turns ASP.NET ViewState into RCE
ViewState is only tamper-proof because of a secret in web.config. If you can read that web.config and it carries a static machineKey, you sign and encrypt your own __VIEWSTATE with ysoserial.net and the server deserializes it, running your command as the IIS app pool on any .aspx page. Here is the chain, the escalation it leads to, and how to shut it.
-
Credentials hiding in plain sight: policy text and the auth surface the form does not guard
Two cheap wins testers skip. A support page that states the password-reset convention is a live credential, not filler. And a login form that rejects a credential you trust is one auth surface, not the verdict: the API, SSH, or SMB on the same app often never checks the flag the form enforced. Read the app, and never retire a credential on one rejection.
-
A Chrome remote-debugging port is somebody's logged-in browser
An unexplained high loopback port on a host with test automation is often Chrome's DevTools remote-debugging port, which has no authentication. Forward it and you can read the session cookies of whatever the automated browser logs into, usually a more privileged app user, and sometimes plaintext from the DOM. Here is the find, the extraction, and why loopback is not a control.
-
Loot lives in backups, connection managers, and keyrings
Most credentials on an engagement are not cracked, they are found where admins already keep them: a leaked backup that shipped the live database, a connection manager that saved the passwords to every host it reaches, and a readable keyring that decrypts a vault with no cracking at all. Run this sweep on every foothold, before hunting for a kernel exploit.
-
Why your path-traversal test silently passed: the curl dot-dot trap
curl collapses ../ in a URL path client-side before the request leaves your machine, so a genuinely vulnerable endpoint answers normally and you record it as safe. The fix is one flag, --path-as-is, and the habit of reading the request you actually sent instead of the one you meant to.
-
The in-house thick client is the privilege escalation: decompile it
A custom in-house .exe on a share or in Program Files is there because it is the path. Decompile its DLLs and you usually find two gifts: a hardcoded developer auth bypass, and a server that deserializes the client's messages with BinaryFormatter, which is RCE by design. The protocol's own upload message becomes code execution as the service, which tends to run as SYSTEM.
-
Why your cross-forest golden ticket authenticates but is not admin: SID filtering and the RC4 TGT_REVOKED trap
You own one forest, there is a bidirectional trust to another, so you forge a golden ticket and inject the target forest's Enterprise Admins SID through SID history. It authenticates, and it is not admin. This is the control working: forest-trust SID filtering strips injected SIDs with a RID below 1000, and every built-in privileged group is below that line. A second trap catches anyone forging with the RC4 key on a patched DC. This teaching walkthrough explains both failures, because a negative result nobody documents is the one that costs you a day.
-
Cracking with hashcat end to end: GPU or not, rules, wordlists, and building your own
The tickets and hashes you capture are useless until you crack them. This is hashcat from first principles: how to run it with or without a GPU, how to pick the attack mode, how rules and the standard wordlists multiply a small list into millions of guesses, and how to build a custom wordlist from the password patterns an organization actually uses.
-
Kerberoasting from Kali: why service accounts leak crackable tickets, and how a weak ACL widens the net
Any domain user can ask a domain controller for a service ticket for any service account, and that ticket is encrypted with the account's password. So you request offline-crackable material for accounts you never authenticated as, with no special rights. This explains why the weakness exists, how to do it from Kali, and how a single over-broad ACL turns accounts that were never kerberoastable into targets.
-
Ligolo-ng, fully explained: a userland VPN for pivoting
Ligolo-ng turns one compromised host into a route onto its internal network by building a layer-3 tunnel to a TUN interface on your attack box. You add a route for the internal subnet and then use every tool unchanged, no proxychains, no per-port SOCKS. This explains how the proxy-and-agent design works, the full setup, reverse listeners and double pivots, the route gotcha that silently breaks it, and how a defender sees it.
-
Registry hive credential dumping: how SAM, SYSTEM and SECURITY interlock
Local Windows account secrets do not live in one place. They are split across three registry hives that are useless apart: SAM holds the encrypted hashes, SYSTEM holds the boot key that decrypts them, and SECURITY holds the LSA secrets including a cleartext autologon password. This explains what each hive contains, the syskey derivation that ties them together, why the parse happens offline and what that means for defenders, shows representative commands to practice on a machine you own, and gives detection and hardening you can lift straight into a SIEM.
-
disable_functions is config, not a wall: own the php.ini
disable_functions and open_basedir live in php.ini, not in the code. If you can influence how a PHP process starts, its environment (PHPRC), its working directory, or a -c flag, you make it load a php.ini you wrote with the restrictions removed, and system/exec come back. Most dangerous against a root daemon that runs PHP on a file you submit.
-
Unpickling is still RCE: where Python pickle still bites
pickle.load on data you can influence is code execution as whoever loads it. The sink has not changed in years, but the places it hides have: a writable Django cache directory, ML artifact pipelines like ClearML, and well-meaning scanner wrappers that parse their own tool's verdict wrong. Here is the mechanism, the three modern sinks, and how to actually stop trusting pickle.
-
ReadGMSAPassword: reading a managed service account's password straight from the directory
Group Managed Service Accounts were meant to end service-account password cracking, and they do: the password is machine-managed, 240 bytes of randomness, rotated automatically. But the directory decides which principals may retrieve it, and an over-broad retrieval list hands the current NT hash to whoever holds it, with no cracking and no lockout. This teaching walkthrough builds the intuition, shows the read step by step, gives you a lab, and ends with the one ACL that closes it.
-
SeBackupPrivilege on a domain controller: extracting NTDS.dit with diskshadow and robocopy /B
SeBackupPrivilege exists so backup software can read any file regardless of its DACL. On a domain controller that means NTDS.dit, which holds every account hash including krbtgt. The file is locked by the running directory service, so you snapshot the volume first, then copy it in backup mode to bypass both the lock and the ACL. This teaching walkthrough builds the intuition for backup mode, gives the diskshadow and robocopy sequence, provides a lab, and ends with the privilege hygiene that closes it.
-
SSH tunneling, fully explained: local, remote, and dynamic SOCKS forwards
SSH does not just carry a shell. It multiplexes arbitrary TCP over the encrypted connection, which makes one SSH login into a route onto a network you cannot otherwise reach. This explains how the three forward types (-L local, -R remote, -D dynamic SOCKS) actually work, when each one is the right tool, how to run them so they stay up, and how a defender stops SSH being used as a pivot. Plus a small CLI helper that manages your tunnels.
-
Your exploit worked, the shell is lying: systemd confinement gotchas
A working exploit that reads as broken is often systemd confinement, not a failed primitive. PrivateTmp hides the file you wrote, NoNewPrivileges kills su and SUID with a valid password. Here is how to tell, how to work around it on an engagement, and why enabling these is some of the cheapest post-exploitation hardening you can ship.
-
Active Directory, the modern attack surface: certificates, delegation, shadow credentials, coercion, and tickets
Classic AD attacks are well covered. This is the surface that actually decides engagements now: AD Certificate Services (the ESC family), delegation and RBCD, shadow credentials, coercion-and-relay, modern ticket forgery, and the newest gMSA and dMSA abuses. Each with its prerequisite, the tool that does it, the detection, and the fix.
-
From application admin to SYSTEM: chaining a script console, in-memory staging, and a held privilege
Three ordinary capabilities, each defensible on its own, compose into full control of a Windows application server: an admin script console that runs as the service account, staging a helper through that console with gzip and base64, and a service account that already holds SeTcbPrivilege. This post explains each piece, how they chain, and how a defender breaks the chain at every link.
-
Authentication coercion: making a Windows host authenticate where you want, and shutting it down
Coercion primitives like PetitPotam and the PrinterBug make a chosen Windows machine, often a domain controller, authenticate to a host you control, as its machine account. That coerced authentication is the fuel for NTLM relay. This covers the common primitives, why they exist, and the layered controls that remove both the coercion surface and its payoff.
-
Coerced NTLM relay to LDAP: from a domain foothold to DCSync (CVE-2025-54918)
When a domain controller does not enforce LDAP signing and channel binding, a coerced machine-account authentication can be relayed to the DC's own LDAP and used to grant a controlled account directory-replication rights, then dumped with DCSync. This explains the conditions, the LOCAL_CALL bypass behind CVE-2025-54918, and the controls that break each step.
-
DCSync: replicating secrets out of Active Directory, and catching it
DCSync abuses the Active Directory replication protocol to pull password hashes, including krbtgt, from a domain controller without running code on it. This explains the replication rights it needs, how it is performed, and, at length, how a defender detects and prevents it.
-
The Liferay Groovy script console: enumeration, file access, and how to lock it down
Liferay ships an admin script console that runs Groovy as the portal service account. Here is what reaching it actually gives an attacker, shown read-only, and how to restrict, contain, and detect its use.
-
Linux container escapes: from inside the container to the host
You have code execution inside a Linux container and you want the host. Confirm you are contained, enumerate the escape surface with built-ins, then take the documented bridge to the host: a mounted docker socket, a privileged container, dangerous capabilities, or a host path mount. For pentesters, with the detection each leaves.
-
Living off the land on Linux: local enumeration for privilege escalation
You have a shell on a Linux box as a low-privilege user. Map it with only what is already installed: a bash port scanner, network and user recon, and the privilege-escalation surface. Written for pentesters, with the detection signal each step leaves.
-
Windows credential access: where secrets live and how they leave
Once you are admin or SYSTEM on a Windows host, the prize is credentials to move laterally. This maps where Windows keeps secrets (SAM, LSASS, LSA, DPAPI, cached logons, and DCSync at the domain) and, with detection as the main event, exactly what pulling each one looks like to a defender.
-
Windows local privilege escalation: user to admin to SYSTEM, the small tricks
You have a shell on a Windows box as a low-privilege user. Enumerate it with built-ins, then take the short hops up: unquoted service paths, weak service permissions, AlwaysInstallElevated, token privileges, stored credentials. For pentesters, with the detection each step leaves.
-
SeTcbPrivilege to SYSTEM, then a new local admin
How a process that already holds SeTcbPrivilege can borrow the SYSTEM logon session, run a service as SYSTEM, and create a local administrator, and where that matters on a real engagement.