From a bare IP to root: watching our agent own a real machine

A defensive scanner tells you a door is unlocked. An offensive one walks through it, then through the three doors behind it, and hands you the keys. So here's the offensive side of Pwnkemon — Pwnkemon Red — pointed at a real target: Enigma, a Linux machine on Hack The Box, attacked from nothing but its IP address.

No prior knowledge. No pre-loaded exploit chain. The agent got a network address and one instruction: get root. It finished with a root shell and both flags in 18 steps, and every one of those steps is on the record. This post is that record, in order.

The setup

Target: a freshly-spawned Enigma instance, reached over an OpenVPN tunnel from an isolated, single-use container. The agent drove the same offensive primitive set every Pwnkemon Red engagement gets:

• nmap — port + service discovery
• nfs_operate, smb_client, mail_read — enumerate and read from file, share, and mail services
• web_action / http — authenticated web-app interaction and custom probes
• metasploit_run + a persistent handler — fire exploits and catch shells
• hash_crack — offline password cracking (John + wordlists)
• su_login, exec_in_session, privesc_suggest — pivot between users and hunt privilege-escalation paths

The agent chooses which primitive to run, and what to do with the result, at every step. Nothing about the chain below was scripted. That is the entire point of an agent.

Recon → a leaked credential

The port sweep came back with a telling shape: SSH, a web server, a full mail stack (POP3 / IMAP), rpcbind, and NFS on 2049. An exposed network file share on a corporate-themed box is a data-leak waiting to happen, so the agent went there first.

The NFS server exported a directory called /srv/nfs/onboarding, world-readable, containing a single PDF: New Employee System Access. Inside was exactly what the name promised — a welcome document for a new hire, complete with his webmail URL, username, and starter password.

A scanner would flag “NFS export readable” and stop. The agent read the document, extracted the credential, and formed a hypothesis: an organisation that emails starter passwords in the clear is an organisation that reuses them.

Credential reuse → an internal app

Rather than log in as the one user it had, the agent sprayed that password against the mail service for a different employee — someone in a role likelier to receive systems-access handovers. The mailbox opened. Sitting in it was an IT reply granting that user admin access to an internal support portal, with the URL and admin credentials written out in full.

That is the move that separates an agent from a scanner. No tool template says “try this user's password on that user's mailbox.” It came from the agent recognising a pattern — credential reuse — and acting on it.

Admin access → remote code execution

The internal portal was an install of OpenSTAManager, an open-source management application. The agent logged in with the recovered admin credentials, fingerprinted the version, and identified its module-upload feature as a code-execution path: an administrator can upload a “module” package, and the application unpacks and serves its contents.

The agent enabled the update setting the feature depends on, uploaded a crafted module carrying a small payload, and confirmed execution with a single request. The response came back running as the web server's service account. It now had a foothold on the machine, not just in the app.

It upgraded that foothold to a proper interactive session: launched a reverse shell from the web context, caught it on a listener, and — when the first callback missed its window — re-armed the listener and caught the retry. Small thing, but it's the difference between a demo that works once and an agent that handles a flaky callback the way an operator would.

Foothold → user

On the box, the agent pulled the application's database configuration, dumped the user table, and recovered a password hash for a real system user. It cracked the hash offline in seconds against a standard wordlist.

The obvious next move — SSH in as that user — failed: the server accepts keys only, not passwords. A lot of automated tooling stops here. The agent didn't: it noted that local authentication (su) still accepts a password even when SSH refuses one, switched to the user with su from its existing shell, and read the user flag. User owned.

User → root

Privilege escalation is where most of the reasoning happened. The agent enumerated the usual paths — sudo rights, SUID binaries, capabilities, cron, writable files — and systematically ruled them out. A fully-patched host with no soft spots in the standard checklist.

What it did find was a root-owned automation service listening only on localhost, reachable now that the agent was a local user. The service runs a set of predefined administrative “actions” as root — one of them a database backup that builds a shell command from user-supplied parameters. One of those parameters is dropped into the command inside quotes without sanitisation.

The agent recognised the classic shape of a command-injection via quote breakout: supply a value that closes the quote, runs an arbitrary command, and comments out the remainder of the line. It triggered the action with a payload that copied the root flag to a readable location and confirmed the effective user — uid=0(root). Root owned.

Both flags submitted. Machine fully compromised, from a bare IP to root, autonomously.

What this demonstrates

Three things, in order of importance:

1. The chain is the product. Every link here — read a file, reuse a password, exploit an app, crack a hash, pivot a user, escalate to root — is a step a human operator would take. The agent did them in the right order, on its own, deciding each move from what the last one returned. A vulnerability scanner produces a list. An agent produces a path.

2. It reasons past the dead ends. The two moments that mattered most — trying a leaked password on a second user, and switching to su when SSH refused passwords — are exactly the points where scripted tooling halts. Neither is in any tool's output. Both came from the agent understanding why the previous step happened and what it implied.

3. It shows its work. Every engagement produces a full, ordered, human-readable trail of what the agent thought and did at each step — the same record this post is built from. You don't get a black-box “compromised: yes.” You get the attack path, so you know exactly which link to break.

The point

Enigma is a known, deliberately-vulnerable target, authorised for security testing — that's why we can write it up. But nothing in the chain above was Enigma-specific automation. The same agent, the same primitives, and the same reason-from-evidence loop point at any authorised engagement. Recon what's exposed, form a hypothesis, act, adapt.

That's what agentic pentesting means: not a bigger scanner, but an operator that works the way an operator works — and hands you the path it took to get in.

Pwnkemon Red runs against scoped, authorised engagements only. See pricing for plans, or the docs for how engagements are scoped and approved.