My First TryHackMe Room: A Beginner Walkthrough (Methodology, Not Spoilers)
A learning-in-public write-up of the methodology I used on my first TryHackMe beginner Linux room — recon, enumeration, and the mindset that finally clicked.
Disclaimer: This is sample placeholder content written to demonstrate the blog. The "room" name below is illustrative — it is not a walkthrough of a specific, named TryHackMe room I claim to have solved. The methodology described is a generic beginner workflow. Replace this post with your own real write-ups.
Note: This is sample placeholder content created to demonstrate the blog. Replace it with your own writing.
I finally sat down and worked through my first proper beginner TryHackMe room last weekend. I'd been circling around the idea for months — buying the subscription, telling myself I'd start "next week" — and the thing that finally unblocked me was treating it like a homework assignment instead of a test. This post is not a flag reveal. It's the methodology I learned, written down so I can re-read it later.
The Setup
I'm not going to pretend I'm cool about this. I installed the OpenVPN config file exactly as the platform instructs, connected, and then triple-checked the connection because I didn't trust it:
# Drop the downloaded .ovpn into a folder and connect.
sudo openvpn --config ryan_student.ovpn
# In another terminal, verify the tunnel came up.
ip a show tun0
# Confirm the target is reachable through the tunnel.
ping -c 3 10.10.10.10 # illustrative target IP
A sanity check I now do every time: I ping the target before I nmap it. If the ping fails, the VPN didn't come up, and there's no point scanning. Five minutes saved, every time.
Phase 1 — Reconnaissance
The single biggest shift in my thinking was internalizing that "recon" is not a single step, it's a posture. Before you touch the target, you write down what you're trying to learn. My list looks like this:
- What services are up?
- What versions?
- What's exposed that wasn't documented?
- What does the surface area tell me about how this box is meant to be approached?
The first command is always the same:
# Quick initial scan: top 1000 TCP ports, default scripts, version detection.
nmap -sV -sC -oN nmap_initial.txt 10.10.10.10
I save the output to a file because I will absolutely forget what was on port 8080 by the time I've pivoted to port 22. Some flags I've learned to read carefully:
| Flag | What it does | When I reach for it |
|---|---|---|
-sV |
Probe for service versions | Almost always — versions drive enumeration |
-sC |
Run default NSE scripts | Initial scan, to surface low-hanging fruit |
-O |
OS detection | When I have a guess and want to confirm |
-p- |
Scan all 65,535 TCP ports | When the top-1000 scan came up empty |
-oN |
Normal output to a file | Every time. Notes are the deliverable. |
--min-rate |
Throttle / unthrottle packet rate | Speed up wide scans on a stable link |
-sV— probe for service versions. This is where the gold is.-sC— default NSE scripts. Slower, but they often surface low-hanging fruit (anonymous FTP, http titles, SMB shares).-oN— normal output to a file. Future-you will thank present-you.
If the initial scan finds ports but doesn't find much detail, I'll do a more thorough pass:
# All TCP ports, then feed back to version detection on what's open.
nmap -p- --min-rate 1000 -oN nmap_allports.txt 10.10.10.10
nmap -sV -sC -p <open ports, comma-separated> -oN nmap_deep.txt 10.10.10.10
Phase 2 — Enumeration
This is the phase I used to rush, and it's the phase I now spend the most time on. Enumeration is where you map the surface area in detail. The mistake I kept making was jumping to exploitation as soon as I saw a web server. Now I make myself answer three questions before doing anything:
- What software, exactly? (Version string, framework, CMS.)
- What endpoints, directories, or files exist that aren't on the front page?
- Is there a known vulnerability for this version?
For a web server on port 80, a basic directory brute-force looks like:
# Directory enumeration with gobuster. Small wordlist to start.
gobuster dir -u http://10.10.10.10/ -w /usr/share/wordlists/dirb/common.txt -o gobuster.txt
# If you find something interesting, look for files too.
gobuster dir -u http://10.10.10.10/ -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,bak -o gobuster_files.txt
If the box exposes SMB, enum4linux is a friendly starting point:
enum4linux -a 10.10.10.10 | tee enum4linux.txt
The non-sexy part of enumeration is taking notes. I keep a markdown file per box with sections for ports, versions, directories, credentials tried, and dead ends. When I come back to a box the next day, the notes are what get me back to speed in five minutes instead of an hour.
Phase 3 — Exploitation (the careful part)
This is where ethics actually matters, even on a sandboxed lab. Three rules I've set for myself:
- I only run exploits I can explain in one sentence. If I can't say why this payload works, I stop and read.
- I prefer public PoCs from reputable sources (Exploit-DB, GitHub repos from named researchers) over random copy-paste from a forum.
- I read the PoC code before running it. Always.
For a beginner Linux room, the exploitation step usually isn't a memory-corruption exploit. It's more often one of:
- A known CVE against an outdated service version found during enumeration.
- A weak or default credential on an exposed admin panel.
- A file upload that the application fails to validate properly.
- A command injection vector in a feature that shells out to the OS.
"Beginner" boxes are beginner for a reason. The lesson is the methodology, not the exploit. The same recon → enumerate → exploit loop scales all the way up; only the depth changes.
Phase 4 — Privilege Escalation
Once you have a foothold as a low-privilege user, the question becomes: how do I become root? On Linux, my checklist is:
- Run
idandwhoami. Note the groups you're in. -
sudo -l— what can this user run as root without a password? - Look for SUID binaries:
find / -perm -4000 -type f 2>/dev/null - Check for writable scripts called by cron or systemd timers.
- Look at environment variables, PATH, anything unusual in
~/.bashrc.
GTFOBins is the reference I check after finding a suspicious SUID binary or a sudo -l entry. The point is not to memorize; the point is to know what to look for and where to look it up.
On Windows, the equivalent reference is LOLBAS, and the tool I'd reach for after a foothold is something like winpeas to automate the discovery phase.
What Actually Clicked
A few things I wish someone had told me more forcefully before I started:
- Fifteen minutes of enumeration beats two hours of guessing. The box is telling you what it's vulnerable to. Listen.
- Take notes. Future-you is the audience. Every command, every output, every "huh, that's weird."
- Don't be precious about hints. Beginner rooms are for learning, not for proving you can brute force the answer with zero help.
- Read the exploit before you run it. Even if you don't fully understand it. Especially if you don't fully understand it.
- The methodology is the takeaway, not the flag. Flags expire; the loop doesn't.
What's Next
My plan for the next month is to work through two or three more beginner rooms using exactly this loop, with the goal of getting faster at the boring parts (recon, note-taking) so I can spend more time on the interesting parts (vulnerability analysis). Once that feels comfortable, I'll move on to intermediate rooms and start looking at HackTheBox and PortSwigger Web Security Academy for variety.
If you're also just starting out: the single best thing you can do is write down what you tried. The first time you do, you'll realize how much of your "memory" was actually a series of lucky guesses, and that's the moment the real learning starts.