Basic Pentesting is often described as an enumeration room. That is true, but incomplete. Its useful lesson is about evidence discipline: a service scan gives you a map; a development note gives you context; an SMB share gives you identities; and a protected SSH key shows why files can be authentication factors. Each stage earns the next one.
TryHackMe identifies the room’s learning goals as service enumeration, brute forcing, hash cracking and Linux enumeration. This companion does not reproduce an answer path. Instead, it shows how to make each decision legible, how to stop when evidence is weak, and how to translate the same trust failures into a useful defensive finding.
The evidence model: do not skip the middle
| Observation | Working hypothesis | Smallest safe test |
|---|---|---|
| HTTP, SMB and SSH are reachable | They may belong to the same user environment. | Record services and inspect the web application without guessing credentials. |
| A development page names people or a weak-password concern | It is identity context, not proof of access. | Compare names with the authorised SMB inventory. |
| A share is readable without a password | Its files may reveal role relationships or exposed material. | List and read only the confirmed guest share. |
| A lab-only account can be verified | The account context may expose local permission mistakes. | Use one constrained validation in the assigned room. |
| An encrypted private key is readable by another user | File permissions have collapsed an authentication boundary. | Document owner, mode and exposure; handle only in the lab. |
Phase 1: build the service record
Start each room instance with an address you do not publish. The first scan is not an attempt to get access. It is a durable record of what the room made reachable at that moment.
export LAB_IP="<tryhackme-assigned-ip>"
nmap -sC -sV --open -oN nmap.initial "$LAB_IP"Why this shape: -sV captures service identity, -sC gathers a modest amount of default-script evidence, --open keeps the result readable, and -oN preserves the output. TryHackMe’s guidance treats a room as an allocated task space; keep the scope clear by using the assigned host only.
# Sanitised example
22/tcp open ssh OpenSSH
80/tcp open http Apache httpd
139/tcp open netbios-ssn Samba
445/tcp open microsoft-ds SambaNothing here says “try passwords.” It says the web application and SMB service could describe the same team. That relationship is the next question.
Phase 2: a web clue changes the question
On the web service, use ordinary browser review and a small content-discovery pass. The room’s hidden development location contains the kind of operational note that teams mistakenly leave visible: names, troubleshooting context and a statement about a password habit.
curl -sS "http://$LAB_IP/" | sed -n '1,80p'
ffuf -u "http://$LAB_IP/FUZZ" -w <authorised-content-wordlist> -fc 404 -t 20Do not turn a note into a credential dump in your notebook. Treat it as an identity lead. The important question becomes: which names are real accounts on services the room already exposed? That is a much smaller and more honest problem than spraying every account on every protocol.
Common wrong turn: finding a person’s name and immediately attempting it on SSH. The note may be stale, fictional, or refer to a different service. Gather corroboration first.
Phase 3: use SMB to build an identity map
SMB is the corroboration point. Ask whether the server permits a guest listing, then interact with only the shares that the server confirms readable. A null session is a security finding in its own right when it exposes staff metadata or sensitive files.
smbclient -N -L "//$LAB_IP"
smbclient -N "//$LAB_IP/<CONFIRMED_GUEST_SHARE>"
# Inside the share: ls, then get only a relevant text file.-N requests no password. The desired output is not a secret; it is a relationship. A staff file can establish a second username, a role distinction, or a connection between the web development note and the server’s local accounts.
# Representative evidence, with identifiers removed
smb: \> ls
staff.txt
staff.txt: two team identities; one noted as handling web workWrite an evidence line, not an answer: “The website note and SMB material agree that an account likely exists.” That keeps the next decision testable and avoids anchoring on a single clue.
Phase 4: validate one claim inside the assigned lab
The room includes a credential-discovery exercise. Perform that part only with TryHackMe’s allocated machine, a platform-provided or locally held lab wordlist, a known candidate account and an intentionally conservative rate. Do not reuse the approach against an internet host, a workplace, or a service that did not explicitly authorise it.
Once the room establishes a working user context, access it with the standard SSH client and collect ordinary local facts before looking for anything unusual.
ssh <LAB_USER>@"$LAB_IP"
id
hostname
pwd
find /home -maxdepth 3 -type f -name 'id_*' -ls 2>/dev/nullThe first three commands answer “who am I, where am I, and what host am I on?” The final command is an audit for private-key filenames and their permissions. It is intentionally not an extraction recipe.
Interpretation: if one user can read another user’s private key, authentication has become shared through the filesystem. The passphrase may still slow an attacker, but it does not repair the ownership error.
Phase 5: private-key protection is an access-control problem
SSH keys combine two controls: possession of the private key and, when configured, knowledge of its passphrase. The Basic Pentesting room illustrates why both matter. A readable encrypted key is still a valuable target because offline guessing can happen without further network requests.
In a real environment, do not copy a colleague’s key to “see whether it works.” Report the exposure with the minimum necessary evidence: path, owner, mode, affected account, and the fact that an unintended user can read it. Then rotate the key and remove the read path.
# Defensive review on a host you administer
find /home -type f -name 'id_*' -perm /go+r -ls 2>/dev/null
stat -c '%A %U:%G %n' /home/<ACCOUNT>/.ssh/id_*OpenSSH recommends protecting private keys from other users. The durable fix is least privilege: correct ownership, a restrictive mode, a protected home directory, and key rotation after any unauthorised readability. A passphrase complements those controls; it does not replace them.
Findings and fixes
| Finding | Impact | Remediation and detection |
|---|---|---|
| Development material exposed over HTTP | Internal names and password-quality hints help an attacker model accounts. | Remove deployment artefacts; add content review to releases; alert on unexpected access to development paths. |
| Guest-readable SMB share leaks staff context | Anonymous access can turn a name into a targeted authentication attempt. | Disable guest access unless required, review ACLs, and monitor anonymous SMB sessions. |
| Weak password accepted by a remote service | A predictable credential can become a foothold. | Use MFA where possible, breached-password screening, rate limits and alerting for repeated failures. |
| Private key readable by an unintended local account | SSH authentication material can be copied and attacked offline. | Restrict file and home-directory permissions, rotate exposed keys, and audit for world/group-readable key material. |
What to remember
Identity is evidence, not access. A name from a web note becomes useful only after another service corroborates it. Access is not proof of safety. A successful lab sign-in should trigger local permission review. A private key is a boundary. If the filesystem makes it readable, its passphrase is carrying more security than it should.
That is the transferable lesson from this room: slow down just enough to state the claim, the evidence and the smallest permitted test. You will solve cleaner labs faster and write findings that a defender can actually fix.
Frequently asked questions
What is the core lesson of this room?
Do not skip the middle of the evidence chain. A username, a note and a readable SSH key each change the hypothesis, and each must be tested inside the lab before you claim access.
Why does SMB matter here?
Anonymous SMB shares can expose identity clues such as usernames and configuration files. They are evidence for a hypothesis, not proof of access by themselves.
Is the SSH key itself the vulnerability?
No. A readable encrypted key is an access-control problem: it shows how key handling, not key presence, determines who can authenticate.