Postman HTB
Postman Postman is a Linux-based Hack The Box machine that focuses on: Redis exploitation SSH key injection credential reuse Webmin exploitation Linux privilege escalation The machine starts with an exposed Redis instance that allows unauthenticated access. By abusing Redis file write functionality, SSH authorized keys can be injected to gain an initial foothold as the redis user. Further enumeration reveals an encrypted SSH private key belonging to another user. After cracking the passphrase, access to the Matt user account is obtained. Finally, credential reuse on the exposed Webmin service leads to authenticated Remote Code Execution through a known vulnerability in Webmin 1.910, resulting in full root compromise. The box demonstrates how multiple small misconfigurations: exposed services, insecure Redis configuration, weak credential management, and outdated software can combine into a complete system compromise. Attack Summary Performed full TCP enumeration using Nmap. Identified exposed services including Redis and Webmin. Connected to Redis without authentication. Abused Redis configuration commands to write an SSH public key into authorized_keys. Gained SSH access as the redis user. Enumerated sensitive files on the system. Discovered an encrypted SSH private key backup belonging to Matt. Cracked the SSH key passphrase using John the Ripper. Reused the cracked password to switch to the Matt user. Logged into the Webmin administration panel using Matt’s credentials. Identified Webmin version 1.910 as vulnerable to authenticated RCE. Executed a public exploit for CVE-2019-12840. Received a reverse shell as the root user. Retrieved the root flag successfully. Enumeration Nmap Scanning As usual, the first step was to perform a full TCP port scan with service and version detection enabled in order to identify exposed services and gather initial information about the target. Nmap Scan Analysis From the Nmap scan, four interesting services were identified: | Port | Service | Description | |---|---|---| | 22 | SSH | OpenSSH service running on Ubuntu | | 80 | HTTP | Apache web server | | 6379 | Redis | Redis key-value database service | | 10000 | Webmin | MiniServ / Webmin administration panel | A few important observations from the scan: The target appears to be running Ubuntu Linux Port 6379 exposed a Redis service directly to the network Port 10000 revealed a Webmin administration interface The web server on port 80 hosted a personal website Both Redis and Webmin are interesting services because: Redis misconfigurations can sometimes allow unauthorized access or SSH key injection Webmin has historically suffered from multiple vulnerabilities and often becomes a privilege escalation target The next step was to manually enumerate the web services running on ports 80 and 10000. Enumerating Port 80 and 10000 The HTTP services were opened in the browser for manual inspection. Port 80 Website Opening port 80 displayed a simple static personal webpage: image The webpage title revealed the domain name: To ensure proper hostname resolution during further enumeration, the domain was added to the local /etc/hosts file. Port 10000 — Webmin Opening port 10000 revealed a Webmin login portal: image The service was identified as: Webmin running on MiniServ 1.910 Webmin is a web-based Linux administration panel commonly used for: user management service management package administration server configuration However, the panel required valid credentials for access, which were not yet available. Next Step — Redis Enumeration At this point: the website on port 80 appeared static Webmin required authentication The most interesting service exposed externally was Redis on port 6379. Enumerating Redis Service The next step was to investigate the Redis service running on port 6379. Redis is an in-memory key-value database that is commonly misconfigured in CTFs and real-world environments. If authentication is disabled and dangerous configuration commands are enabled, it can often lead to remote code execution or unauthorized file writes. Connecting to Redis A connection was established using redis-cli: The connection succeeded without requiring authentication, confirming that the Redis instance was exposed publicly with no password protection. Checking Redis Version The Redis server information was retrieved using: The important information gathered from the output: | Setting | Value | |---|---| | Redis Version | 4.0.9 | | Config File | /etc/redis/redis.conf | | Operating System | Ubuntu Linux | --- Testing Write Permissions To determine whether arbitrary data could be written into Redis memory, a test key was created: The successful response confirmed that write operations were allowed. This is important because Redis allows administrators to: change the database save directory change the database filename force Redis to write data to disk If abused correctly, this behavior can be used to write files onto the target system. Redis SSH Key Injection Technique Since arbitrary writes were possible, the plan was to abuse Redis to write an SSH public key into: This technique works because: Redis periodically saves its database contents to disk Redis allows changing the save directory and filename SSH ignores invalid lines inside authorized_keys our public key can survive the extra Redis junk data By writing a valid SSH public key into the authorized_keys file, SSH access can be gained as the user running Redis. Generating an SSH Key Pair An RSA SSH key pair was generated locally: The key was generated without a passphrase to simplify authentication later. --- Preparing the Public Key The public key needed to be stored inside Redis memory before writing it to disk. However, Redis does not write perfectly clean files. It adds extra metadata and binary content around the stored values. To make the SSH daemon parse the key correctly, newline characters were added before and after the public key. The public key was copied into a text file like this: The added newline characters help ensure that: SSH ignores surrounding junk data the public key appears on a clean line authorized_keys remains parseable Writing the SSH Key into Redis Memory The public key was then stored as a Redis key: At this point, the SSH key existed only inside Redis memory. The next step was to force Redis to save this data into the Redis user's SSH configuration directory. Changing the Redis Working Directory The Redis database save directory was changed to the Redis user’s .ssh directory: Next, the database filename was changed to: using: This effectively instructed Redis to save the database contents directly into: Saving the Database to Disk The database was written to disk using: At this point: Redis wrote the database contents the SSH public key was embedded inside the file the Redis user's authorized_keys file now contained the attacker's public key The Redis session was then exited: SSH Login as Redis User Using the generated private key, SSH access was attempted as the redis user: The login succeeded successfully, providing an initial shell as the redis user. Enumerating the System The next step was to search for interesting files owned by Matt user . Running: The file: immediately looked suspicious. --- Encrypted SSH Private Key Reading the file revealed an encrypted RSA private key: The key was password protected, meaning the passphrase needed to be cracked before it could be used. Cracking the SSH Key Passphrase The encrypted key was copied locally and saved as: The SSH key hash was extracted using ssh2john: The hash was then cracked using John the Ripper: The passphrase was successfully cracked: Switching to Matt User The cracked passphrase was reused as the password for the Matt user: At this stage, access to the Matt user account had been achieved successfully. User Flag Privilege Escalation Earlier during enumeration, a Webmin service was discovered running on port 10000. Since valid credentials for the Matt user had already been obtained, the next step was to test whether these credentials could also be reused for the Webmin administrative panel. Logging into Webmin Opening the Webmin portal: displayed the login page: image Using the recovered credentials: the login succeeded successfully. image After logging in, the Webmin version was identified as: Searching for Public Exploits Since Webmin has historically suffered from multiple remote code execution vulnerabilities, the next step was to search for publicly available exploits targeting version 1.910. Using searchsploit: The reverse shell payload instructed the target machine to connect back to the attacker's listener on port 1234. Receiving the Root Shell Checking the Netcat listener: The exploit succeeded successfully and returned a root shell. At this point, full administrative access to the target machine had been achieved. Root Flag Final Thoughts Postman was an excellent machine for understanding how dangerous exposed infrastructure services can become when basic security practices are ignored. The box highlighted several important real-world lessons: Redis should never be exposed publicly without authentication Sensitive services like Webmin should be patched regularly Password reuse across services is extremely risky Backup files containing private keys can become critical attack vectors One of the most interesting aspects of this machine was the Redis SSH key injection technique, which demonstrated how file write capabilities can directly lead to system access without exploiting memory corruption or traditional Remote Code Execution vulnerabilities. The privilege escalation stage also showcased how quickly an outdated administrative interface can become a full root compromise once valid credentials are obtained. Overall, Postman provided valuable practice for: service enumeration, Redis exploitation, SSH abuse, credential attacks, and Linux privilege escalation. See you in the next blog. Until then, keep enumerating and stay curious. by Madhav ```