Steel Mountain TryHackMe Writeup | Archive

Windows enumeration on Steel Mountain

Steel Mountain was one of the first Windows machines I completed in TryHackMe’s offensive-security pathway. I used the room to compare framework-assisted exploitation with a manual route built from the same vulnerability and to examine how a public exploit script worked before running it.

The room had two distinct security problems:

Rejetto HTTP File Server 2.3 exposed a remote command-execution vulnerability associated with CVE-2014-6287.
An Advanced SystemCare service used a binary in a directory that the compromised user could modify, while the service itself ran with SYSTEM privileges.

That gave the lab a useful structure. The first weakness established user-level access through an exposed network service. The second required local enumeration and an understanding of Windows service permissions.

Finding the exposed services

I began with a broad service and operating-system scan:

sudo nmap -vv -A <target> -oA nmap/Steel_Mountain

The scan identified a Windows host with two web services:

Microsoft IIS on TCP port 80;
Rejetto HTTP File Server, or HFS, on TCP port 8080.

The IIS page displayed an employee-of-the-month image named BillHarper.png, which supplied a likely username or identity clue. Port 8080 was more directly useful because its page exposed the HFS product and version. Searching that exact service version led to CVE-2014-6287 and public implementations for both Metasploit and standalone use.

The vulnerable behaviour was associated with the way HFS processed specially formed values in its search request. The public exploit encoded commands into a request understood by the server-side template language. That allowed an unauthenticated request to make the service create and run files under the account used by HFS.

First pass with Metasploit

I first completed the initial-access stage with the Metasploit module for Rejetto HFS. This established that the room matched the expected vulnerability and gave me a user-level session.

Using the framework made the route quick to validate, but it hid most of the request flow. The module handled target configuration, command delivery, payload transfer, and session management. I could prove that the exposed HFS instance was vulnerable, but I could not yet explain how the standalone Python exploit converted an HTTP request into a command on the Windows host.

I kept the framework-assisted run as a reference point and repeated the stage manually. Comparing the two routes helped separate the vulnerability from the tooling used to exercise it.

Analysing the standalone exploit

The public Python script contained three main actions:

write a VBScript downloader to C:\Users\Public\script.vbs;
ask cscript.exe to run that script;
run the transferred networking utility with arguments that created an interactive command channel.

The script built those actions as URL-encoded search values. Its variables held the local address and port, the encoded VBScript, and command fragments used to save or execute content. Three functions then submitted the requests in sequence.

The first function constructed a request that used the HFS template operation for saving data. The decoded content was a small VBScript using Microsoft.XMLHTTP to request a file and ADODB.Stream to write the binary response to disk. The technical points I took from that stage were:

the exploit did not upload a binary directly through a normal file form;
it first made the vulnerable service create a script;
the script then used Windows components already present on the host;
URL encoding allowed the commands and script body to travel inside the affected query parameter.

The second function submitted another request to launch the saved VBScript with cscript.exe. The third asked the transferred networking utility to start a command process and connect back to the testing machine.

In pseudocode, the sequence was:

request 1 -> save downloader script
request 2 -> execute downloader script
request 3 -> execute transferred command utility

Breaking the script down this way removed the mystery around the exploit. CVE-2014-6287 provided command execution through HFS request processing; VBScript and built-in Windows components handled the file transfer; the final utility provided an interactive channel. Each stage created different network and endpoint evidence.

Manual validation

After reading the code, I mirrored the public exploit locally and changed only the lab-specific connection values. I hosted the required file, started the corresponding test listener, and executed the script against the intentionally vulnerable HFS service.

The result matched the Metasploit run: command execution under the service user’s context and an interactive user-level shell. The manual route was more useful for understanding what the target did:

HFS received a distinctive request containing an encoded template expression;
the service caused a script to be written into a public user directory;
cscript.exe launched the script;
the Windows HTTP components fetched a binary;
the transferred process created a new outbound connection.

A defender monitoring only the final network connection would miss the earlier HFS request and script activity. Web logs, process creation, file writes, and outbound connections together describe the complete path.

Looking for local privilege escalation

With user access established, I reviewed installed software, service configuration, and permissions. PowerUp and WinPEAS both identified Advanced SystemCare as an area requiring attention.

The relevant service executable was under the IObit Advanced SystemCare installation directory. The compromised user could stop and start the service and could write to the directory containing its binary. The service itself ran with SYSTEM authority.

This condition is often discussed alongside unquoted service paths, but the decisive issue in the room was the ability to replace a binary that a privileged service trusted. If an unprivileged user can modify that file, the service account becomes a route to elevation regardless of how the replacement was produced.

I verified three parts of the condition:

the service ran under a privileged account;
the current user could modify the relevant application directory or binary;
the service could be restarted so Windows would load the changed executable.

Once those conditions were confirmed, replacing the service binary in the lab and restarting the service produced a second session under NT AUTHORITY\SYSTEM.

Framework and manual routes compared

The room let me complete the same broad chain in two ways.

With Metasploit:

the framework selected and configured the HFS exploit;
Meterpreter handled file transfer and session management;
PowerUp highlighted service and permission issues;
a handler managed the elevated connection.

With the manual route:

I read the standalone Python exploit;
I decoded the VBScript and URL-encoded request content;
I followed the save, execute, and connect sequence;
I used separate Windows-enumeration output to identify the service weakness;
I reasoned about the binary, directory permissions, service account, and restart behaviour directly.

The framework route demonstrated efficient use of established tooling. The manual route showed what the framework was automating. Both were useful, but the second produced a clearer account of the affected components and the evidence defenders could collect.

Flag checkpoints

The two flags followed the security boundary in the room:

the user flag became accessible after exploiting HFS and obtaining the initial shell;
the root flag became accessible after the Advanced SystemCare service path produced a SYSTEM-level session.

The migrated WordPress article did not contain the literal flag strings. It recorded the access stages and screenshots, so this archive entry preserves the route and the checkpoints without inventing or publishing answer values.

Detection and remediation

The initial-access route exposed several useful defensive signals:

an internet-facing or broadly reachable HFS 2.3 service;
requests containing encoded template expressions in the search parameter;
HFS spawning scripting or command interpreters;
creation of scripts and executables under C:\Users\Public;
cscript.exe, PowerShell, or another interpreter making unexpected network connections;
an outbound command channel from a web-service process tree.

Remediation begins with removing the vulnerable HFS version from exposure and upgrading or replacing unsupported software. Network controls should restrict administrative and file-service interfaces, while web and endpoint telemetry should identify unusual child processes and file writes.

The privilege-escalation path needs a separate fix. Service executables and their directories should be writable only by trusted administrators and deployment mechanisms. Users who run an application do not normally need modify access to the binaries a SYSTEM service will execute. File-integrity monitoring and service-change auditing can also reveal unexpected replacement or restart activity.

Steel Mountain was a practical early Windows lab because it joined network exploitation to local permission analysis. The most useful part was not obtaining two shells; it was tracing how an HTTP request became a Windows process and how one filesystem permission changed the meaning of a privileged service.