Vulnversity.

Short answer: Vulnversity teaches a compact but important chain: an exposed web service leads to an upload route; the route accepts a file the server can later interpret; a low-privilege process becomes a local permission-review vantage point; and one non-standard setuid boundary deserves much more scrutiny than its filename suggests. The transferable lesson is to test upload acceptance, storage and execution as separate controls, then treat every elevated binary as a question about who controls its inputs.

Authorised-use notice: this companion is for the public TryHackMe Vulnversity room and its assigned lab host only. It omits the room address, account data, flags, callback payloads, alternate-extension strings, exact privileged executable and privilege-shell recipe. The examples are safe observations or audits, not a recipe for testing systems you do not own or have written permission to assess.

The room is useful because nothing in the chain is exotic. A web upload form looks ordinary. A browser can make it look as if a file type is blocked. Linux setuid bits are common. The failure appears when several ordinary choices are trusted as if they were one security control.

Spoiler-aware roadmap

Phase 0: set the boundary before touching the lab

Start a fresh Vulnversity instance or the TryHackMe AttackBox, and record only the room-assigned host in a local variable. The address is temporary and should not appear in notes you publish. The goal is to make every request attributable to the training environment.

export LAB_HOST='<assigned-tryhackme-host>'
printf 'Authorised target: %s\n' "$LAB_HOST"

That small habit matters outside a CTF too. Good assessment notes keep scope, evidence and conclusions together. It makes it easier to notice when a browser proxy, wordlist or terminal tab is pointing somewhere unexpected.

Phase 1: build a service model before choosing a web path

TryHackMe asks learners to begin with network and service enumeration. Nmap's service-version mode is useful here because the question is not “what can I attack?” but “which protocol and application behaviour deserve a closer look?” Its reference guide documents both service detection and host-discovery controls.

nmap -sV -Pn "$LAB_HOST"

-sV asks Nmap to identify services. -Pn is only useful when the assigned lab host does not answer discovery probes. Keep the scan narrow, and do not turn a single-host learning exercise into a broad network sweep.

# Representative, sanitised output. Not a captured room result.
PORT      STATE SERVICE  VERSION
<web-port>/tcp open  http     Apache httpd
<other-port>/tcp open  proxy    Squid http proxy

The web service is the important clue. A separate proxy or administrative-looking service may be a useful inventory detail, but it does not outrank an application feature the room explicitly wants you to study. Write down the port, protocol and server banner, then move to the application itself.

Transferable concept: service discovery is a way to reduce guesswork. MITRE maps this activity to T1046, Network Service Discovery; defenders can use the same model to decide which externally reachable services deserve logging, patching and ownership.

Phase 2: discover content with a bounded hypothesis

Application navigation is a statement of intended use, not an inventory. In the assigned lab, use directory discovery to test the modest hypothesis that an unlinked route exists. Gobuster's directory mode is designed to enumerate directories and files on web servers.

gobuster dir \
  -u "http://${LAB_HOST}:<web-port>" \
  -w '<approved-lab-wordlist>' \
  -t '<low-concurrency>'

Use a room-appropriate wordlist and low concurrency. The finding you want is a candidate route, not a noisy terminal transcript. Open a positive result in the browser and ask a narrow question: does the page accept a user-supplied file, and what does the interface claim about that file?

Phase 3: split “upload works” into four security decisions

The room's teaching point is often reduced to “bypass the upload filter.” That phrase hides the part worth remembering. A safe upload flow has at least four independent decisions: what the client suggests, what the server accepts, where the application stores a file and whether a server component may interpret that file as code.

Client hints are not enforcement

A browser form can restrict the file picker or display a warning. That improves the normal user experience, but it does not decide what an HTTP client sends. The server must make its own decision after receiving a request.

Server validation needs more than one signal

The OWASP File Upload Cheat Sheet recommends an allowlist for the business-required extensions, server-side type checks, generated filenames, size limits and storage outside the webroot where possible. A content-type header is a claim supplied by the client. A filename is also client-controlled input. Neither should be treated as a complete security decision.

Storage location changes the blast radius

An uploaded object can be harmless data in one location and dangerous code in another. Storing it outside the application tree removes the direct path from retrieval to interpretation. If public retrieval is required, use a controlled handler and a generated server-side name instead of reusing the original name.

Execution must be explicitly absent

OWASP's unrestricted-upload guidance is direct: an upload directory should not have execute permission, and script handlers should be removed there. This is the control that turns a successful upload into a static-object problem rather than an application-code problem.

Lab decision: use only the room's own permitted test procedure to observe its acceptance and retrieval behaviour. Do not copy the resulting technique to a non-lab service. The useful conclusion is not a magic filename. It is an evidence record showing which of the four decisions failed.

Phase 4: verify the low-privilege context without collecting secrets

Once the authorised room permits an access check, the immediate task is to understand the process context. Do not rush to collect flags, home-directory files or credentials. Start with identity and location.

# Run only inside the assigned room after its permitted access step.
id
pwd

id answers who the process is. pwd gives context for relative paths and application layout. Record those facts privately for the lab, then ask what the current account can execute, read or influence. The answer determines whether a privilege-escalation idea is plausible.

MITRE describes a web shell as a server-side script that can provide access or command execution on the host. That risk is tracked as T1505.003. In a real environment, that is the moment to contain the account, preserve server and upload logs, rotate relevant credentials and inspect the webroot. In this room, it is a reason to proceed carefully and stay inside the lab.

Phase 5: audit setuid entries as trust boundaries

Setuid is not automatically a vulnerability. It exists because some programs need an action that the caller's normal account cannot perform. The risk appears when an elevated program accepts a user-controlled configuration, path, plugin, environment value or file reference without enforcing a safe boundary.

# Read-only audit in the assigned lab. Redirect errors to avoid noise.
find / -type f -perm -4000 -ls 2>/dev/null

The GNU find manual explains that -perm -4000 matches paths where the requested permission bit is set. The output is an inventory, not an answer. Most entries may be expected operating-system utilities.

In Vulnversity, one non-standard administration-oriented entry stands out. Treat it as a hypothesis and review it with five questions:

1. Is the setuid bit necessary for this program's intended job?
2. Who owns the binary, and can an unprivileged account modify the binary or any file it loads?
3. Can a caller choose a configuration, working directory, unit, plugin, editor or command-like input?
4. Does that choice affect a process running with the file owner's effective identity?
5. Would a restricted allowlist or a root-owned fixed configuration remove the dangerous control?

This is the room's escalation lesson. The goal is to recognise the privilege boundary and understand why it is unsafe, not to memorise a one-line route to a flag. MITRE's T1548.001 describes how setuid and setgid applications can run in a different privilege context and recommends minimising such programs.

Why the chain works

The chain combines two trust mistakes. First, the web application confuses a user-selected file with safe static content. Second, the operating system gives a broad administration tool an elevated execution context. The first mistake supplies a low-privilege vantage point; the second can turn influence over a privileged action into an escalation opportunity.

Neither weakness needs an impressive exploit title. That is why this room remains useful. Most security failures begin as a small ownership error: a client is trusted to validate itself, an upload directory is treated like a document store while a web server still interprets it, or an elevated program is assumed to be safe because an administrator installed it.

Defender's review card

Watch for unexpected uploads, new or changed files beneath application-serving paths, web-server processes spawning unusual children, and changes that add setuid bits. These are useful investigation leads, not standalone proof of compromise. Correlate them with deployment activity and the application account that performed the action.

Memory aid and next practice

Accept, store, serve, execute. Those are four separate verbs. A secure system makes a deliberate decision at each one. For privilege review, remember owner, input, effect: who owns the elevated program, what can the caller influence, and which privileged effect follows?

After completing the room, try explaining the path without mentioning a filename, payload or final answer. If you can describe the evidence that justified each decision and the control that would have stopped it, you learned more than a walkthrough.

Frequently asked questions

What is the upload trust model?

An upload is four decisions, not one: client input, server validation, storage and execution. Compromising any step changes what happens when a file lands.

Why treat setuid as an administration boundary?

A setuid binary runs with the file owner's privilege. A helper or interpreter reachable through it becomes a privilege decision point that deserves the same review as a login path.

What does the companion keep spoiler-free?

Room passwords, flags and exact payloads. The reasoning loop, commands with placeholders and defensive fixes stay publishable and transferable.

Primary references

• TryHackMe: Vulnversity
• OWASP File Upload Cheat Sheet
• OWASP: Unrestricted File Upload
• Nmap Reference Guide and Gobuster documentation
• GNU find(1) and MITRE ATT&CK T1548.001