Cap.

01 · Scope, prerequisites, and objectives

Difficulty: Easy. Prerequisites: basic HTTP requests, an idea of TCP services, and comfort reading a packet capture. Keep the retired instance address, every lab credential, and any flags private. The platform boundary is part of the exercise: do not reuse a request, credential, or scan against another host.

By the end, you should be able to explain why predictable object identifiers need a server-side ownership check; triage a packet capture without spraying credentials; distinguish a valid account from a privilege boundary; and assess file capabilities as carefully as SUID and sudo rules.

02 · The route is a chain of misplaced trust

HTB describes Cap as an HTTP administration service that performs network captures. The defensive model is more interesting than the route: the web layer accepts a record reference without proving the requester owns that record; a capture can preserve a clear-text protocol exchange; an account valid for one service is treated as evidence to inspect a small local privilege model; and an interpreter has CAP_SETUID, allowing arbitrary UID changes.

There is no vendor CVE to attach to this chain. The record-access flaw maps cleanly to CWE-639, authorisation bypass through a user-controlled key. The privilege problem is better described as improper privilege management, CWE-269, than as a made-up software vulnerability.

03 · Build a service inventory, then read the application

Start with the host assigned by the retired HTB environment. -Pn skips host discovery when the lab route does not answer discovery probes; -sV asks open services for version information; -sC runs Nmap's default scripts; and -oA saves normal, XML, and grepable output for later review. Version detection is evidence, not proof that a version is exploitable.

export LAB_HOST="<assigned-retired-htb-host>"
nmap -Pn -sV -sC --reason -oA cap "$LAB_HOST"

Representative output:

PORT   STATE SERVICE  REASON
21/tcp open  ftp      syn-ack
22/tcp open  ssh      syn-ack
80/tcp open  http     syn-ack

Service Info: OS: Unix

The right next action is to use the HTTP service as a person would. Read the dashboard, note how it names a capture, and compare the application's controls with its server-side response. Avoid content fuzzing, password guessing, or scanning a neighbouring address. Nothing in a retired lab extends authorisation beyond that one instance.

04 · A record number is not proof of ownership

The observation is simple: an administrative page exposes a capture record. The hypothesis is narrower: perhaps the record reference is accepted without a session-bound ownership check. Test that claim with the smallest authorised change, one adjacent lab record reference, and stop after you can decide whether the server checks ownership.

# Conceptual request against the assigned lab only
GET /<capture-resource>/<adjacent-record-id> HTTP/1.1
Host: <assigned-retired-htb-host>

A successful response for another user's record confirms an authorisation failure. It does not justify walking the whole identifier space. The evidence needed for a report is the mismatch between the authenticated user and the object owner, a timestamp, the affected route class, and a redacted result. Do not save or publish traffic that is not needed to prove the issue.

05 · Treat a packet capture as sensitive evidence

The recovered capture is an artefact, not a trophy. Open it offline and first identify its protocol mix. Wireshark documents packet-capture formats and display filters; RFC 959 defines FTP, a protocol whose control channel does not provide modern transport encryption by itself.

# Read a local, redacted copy of the authorised lab capture
capinfos <authorised-capture>.pcap
tshark -r <authorised-capture>.pcap -Y ftp -T fields \
  -e frame.number -e ip.src -e ip.dst -e ftp.request.command

Representative output:

frame  source        destination   command
  42   [redacted]    [redacted]    USER
  44   [redacted]    [redacted]    PASS

Credential values intentionally omitted.

The interpretive step matters. A visible FTP control exchange supports a hypothesis that credentials were exposed in transit. It does not tell you whether those values work elsewhere. If the next sanctioned service rejects them, record the mismatch once and return to the evidence. Do not try variations, reuse values on other targets, or disclose them.

Troubleshooting: if the file has no FTP traffic, inspect protocol hierarchy and the time range before assuming you missed a password. If the capture will not parse, verify you downloaded an actual capture response rather than an HTML error page. If a filter returns no packets, remove the filter and confirm the file has frames. These checks preserve the evidence instead of creating noise.

06 · A valid service session is a new boundary

In the retired lab, the official synopsis says the capture contains plain-text credentials that lead to foothold. Keep the value private and validate it once against the service the lab indicates. The goal is a precise local model, not an interactive collection exercise.

ssh <lab-user>@"$LAB_HOST"
id
pwd
sudo -l

Representative output:

uid=1000(<lab-user>) gid=1000(<lab-user>) groups=1000(<lab-user>)
User <lab-user> may run the following commands:
    (none)

A denied sudo route is useful information. It says privilege has not been delegated through sudo. Move to explicit checks that explain the host's privilege surface, then stop as soon as a high-confidence control failure appears.

07 · Linux capabilities can make an interpreter privileged

Traditional Unix permissions make root a broad exception. Linux capabilities split parts of that authority into smaller privileges. The Linux manual states that CAP_SETUID permits arbitrary manipulation of process UIDs. A file capability attached to a general-purpose interpreter is dangerous because the interpreter can run code that uses its effective privilege.

getcap -r /usr/bin /usr/local/bin 2>/dev/null
# Inspect only binaries reported by getcap before attempting any action.

Representative output:

/usr/bin/<interpreter> = cap_setuid+ep

getcap displays capabilities attached to files. In the lab, confirm the binary's capability and understand the interpreter's UID-changing API before taking the smallest possible authorised proof. A generic illustration is an interpreter process requesting UID 0, followed by a harmless identity check. Do that only inside the assigned Cap instance and do not publish the exact command, a shell transcript, or the final proof string.

Memory aid: object, packet, principal, privilege. At each noun, ask who owns it, who can read it, what it reveals, and which authority it carries. That small sequence finds both failures in this machine.

08 · Fixes, logs, and a technique map

A practical detection path joins web authorisation logs with capture-store audit logs, then checks host telemetry. On Linux, audit rules or an endpoint agent should record execution of a capability-bearing binary and changes to extended attributes. For the web application, a 200 response matters less than whether the actor was entitled to that object.

The relevant ATT&CK relationship is limited: valid credentials in the lab may resemble T1078 Valid Accounts, while an overpowered local binary belongs near T1548 Abuse Elevation Control Mechanism. These labels organise defender thinking; they do not replace an evidence-backed finding.

09 · Practice checklist

• For each user-controlled identifier, prove the server verifies object ownership.
• For each capture or export, identify the protocol and retention risk before examining payloads.
• For each recovered account, validate it once in its assigned context and then model local rights.
• For each Linux host, review sudo, SUID, scheduled tasks, writable paths, and file capabilities together.
• For each proof, keep the smallest redacted record that establishes impact and stop there.