Cap: object access and effective privileges
An English summary of the documented HTB Cap lab, its decisions, evidence and limits.
Updated
HTB CAP · LINUX · DOCUMENTED LAB RETROSPECTIVE
The case at a glance
- Problem
- A download exposes traffic from another lab session.
- Decision
- Compare objects, check credential reuse and inspect effective privileges.
- Evidence
- The guide documents distinct captures, FTP authentication, SSH access and Python CAP_SETUID.
- Result
- SSH access as nathan and a change to UID 0, as described in the guide.
- Limit
- HTB retrospective: no original PCAP or independent transcript; no verified remediation.
1. Ask whether the capture belongs to the account
The guide describes /data/1 as an empty personal capture and /data/0 as an earlier capture containing 72 packets. That specific comparison supports an object-level authorization question.
Boundary: it does not establish access to every capture or the current behavior of a live service.
Source: capture comparison (Spanish)2. Correlate the exposed data with a service
The documented traffic contains FTP authentication information. The guide then describes access through SSH. A value observed in one protocol becomes a new hypothesis to check; the protocol alone does not prove reuse elsewhere.
Boundary: the public dossier does not include the original PCAP or an independent session transcript. Secrets are omitted.
3. Explain escalation through an effective capability
The guide shows cap_setuid on /usr/bin/python3.8 and a final UID of 0. That permission explains the identity change more precisely than referring to a generic privilege-escalation exploit.
Proposed remediation: remove unnecessary interpreter capabilities and check the remaining service privileges. The published material does not establish that this fix was applied or retested.
Source: capability and UID check (Spanish)