Unboxing TryHackMe: A Data Analyst Steps Into the Cybersecurity 101 Path
- Jun 29
- 7 min read
I've been talking about TryHackMe for months. It was on my study plan, on my content calendar, and somewhere in the back of my mind as the thing I would get to once I checked off a few more boxes. Well, I finally opened the platform, and honestly? I'm glad I did.
This post covers Module 1 of the Cybersecurity 101 Learning Path on TryHackMe: three rooms plus a mystery. I'm writing this from my specific vantage point — someone with over 10 years in data analytics, currently in the middle of a cybersecurity career transition — because I think that lens matters. Some of this was familiar. Some of it reframed things I thought I understood. One room reminded me why I find this field genuinely exciting.
Quick context
If you're new here: I'm a Senior Data Analyst pivoting into cybersecurity. I write about what that transition actually looks like — the certs, the labs, the moments where my analytics background clicks with security concepts, and the moments where it doesn't. DataSec Chronicles is where I document all of it.
What's in Module 1?
The Cybersecurity 101 path at TryHackMe is designed for beginners, but "beginner" doesn't mean boring — it means foundational. Module 1 is called Start Your Cybersecurity Path, and it includes four components:
Room 01
Offensive Security Intro
Your first taste of thinking like an attacker — what offensive security means, how ethical hacking works, and a hands-on intro to a web-based machine.
Room 02
Defensive Security Intro
The flip side: how defenders think, what a SOC analyst actually does, and an introduction to threat intel, SIEM, and incident response workflows.
Room 03
Search Skills
OSINT fundamentals, effective searching for security research, and how to find credible sources — including CVE databases, threat intel feeds, and more.
Mystery
The Mystery Chest
A bonus reward for completing Module 1. I wasn't expecting this one — and it ended up being a nice surprise.
Room 1: Offensive Security Intro
I'll be direct: I came into this room slightly skeptical. The concept of "learning to hack" in a beginner module felt like it could go either direction — actually eye-opening, or surface-level and vague. It was the former.
The scenario: a simulated bank called FakeBank. My job was to think like an ethical hacker and find vulnerabilities before a real attacker could. The method? Looking for hidden pages that had been left accessible on the web server — pages the developers may have forgotten about, or assumed nobody would find.
To find them, I typed dirb in the terminal. That single command ran a directory brute-force scan against the site, surfacing URLs that weren't linked anywhere publicly. Two came back. One of them was an open admin page — completely unprotected, sitting there waiting. From that page, I transferred funds between accounts. I had just "hacked the bank."
The vulnerability wasn't some elaborate exploit. It was a forgotten page that was never locked down. That's what made it unsettling — and clarifying.
What stuck with me wasn't the mechanics — it was the mindset shift. Offensive security requires you to think about how things break rather than how they're supposed to work. You're asking: what did someone assume was hidden? What got left open by accident? As someone who spends a lot of time in data quality work — chasing anomalies, asking "why does this number look wrong?" — that question felt familiar in a way I didn't expect.
Data analyst parallel
In analytics, we validate data pipelines by trying to break them — bad inputs, null handling, edge cases. The dirb scan felt like running a data profiling check: systematically probing for things that shouldn't be there. Same instinct, different tool.
Room 2: Defensive Security Intro
This one hit closer to home — and not just because I'm targeting SOC Analyst roles. I also have hands-on experience querying help desk systems. The Defensive Security Intro room introduced five core areas of defensive security: Threat Intelligence, SOC, DFIR (Digital Forensics and Incident Response), Malware Analysis, and SIEM. Then it put me inside the work.
The scenario picked up right where the offensive room left off — FakeBank was back, but this time I was defending it. I was placed inside a SOC monitoring dashboard and told to review the alerts: multiple events, different severity levels, and a live feed of what's hitting the network.
Working through the alerts, I identified the source generating the suspicious traffic. Then came the response: containment. I navigated to the firewall settings and added a rule targeting that IP address. Here's the detail TryHackMe makes very intentional — you have to actively select "Block." Not just add the rule. Apply it. That extra click felt deliberate, like they wanted you to feel the weight of the action. The attack stopped. FakeBank was secured.
I've read about SOC workflows in certification material. Walking through an actual alert triage — identifying the source, containing the threat, blocking the IP — made those concepts land in a completely different way.
What struck me from a data analyst perspective is how fundamentally data-driven defensive security is. You're not guessing; you're reading signals. You're looking at logs, correlating events, and identifying patterns that don't belong. That language maps directly onto the work I've been doing for over a decade.
Defensive Security Area | What It Is | Data Analyst Equivalent |
Threat Intel | Information about known bad actors, tactics, and indicators of compromise | Reference/enrichment data (fraud flags, risk scores) used to contextualize your analysis |
SOC | Security Operations Center — the team monitoring alerts and responding to incidents in real time | A data operations team watching dashboards for anomalies, except the anomalies are attacks |
DFIR | Digital Forensics & Incident Response — investigate what happened, contain it, recover | Root cause analysis — trace the anomaly back through the pipeline and document what broke |
Malware Analysis | Examining malicious code to understand what it does and how it operates | Profiling a bad data feed — understand the structure of the corruption before you remediate |
SIEM | Aggregates and analyzes security event logs across the environment in real time | A BI platform pulling from multiple sources — but the metrics are alerts, not KPIs |
The room is a solid introduction. It does well in making the defensive security landscape feel navigable rather than overwhelming. I left it with a much clearer picture of how the pieces connect, and a sharper sense of what a SOC analyst's day actually looks like.
Room 3: Search Skills
Okay, this one surprised me the most — and I mean that as a genuine compliment.
I went in expecting a light primer on using Google effectively. What I got was a structured walkthrough of five specific tools security professionals actually use for research:
Shodan (TryScanMe) — search engine for internet-connected devices. Not websites; devices. Cameras, servers, industrial systems. The first time you run a search and see what's publicly exposed, it reframes how you think about the internet entirely.
VirusTotal (TryDetectMe) — analyze suspicious files, URLs, and IPs against dozens of antivirus engines simultaneously. If you're investigating a potential indicator of compromise, this is where you check your work.
CVE (Vulnerability Databases) — the Common Vulnerabilities and Exposures database. Standardized records of known security vulnerabilities. Learning to read a CVE entry is like learning to read a data dictionary — it tells you exactly what you're dealing with.
MAN Pages (Technical Documentation) — the manual pages built into Linux systems. Dry, dense, and essential. Every command-line tool has one. Learning to use them means you can always find out exactly what a tool does and how to use it.
GitHub — and here's the one that landed hardest: the room showed that a vulnerability's documentation is sometimes sitting right in a public repository's README. Right there. Readable by anyone. The README isn't just onboarding material — in a security context, it can be a map.
The GitHub piece reframed something for me. I've used READMEs my entire career and never thought about them as intelligence sources. Now I do.
From a data analyst perspective, this room clicked immediately. I spend a lot of time sourcing data — understanding where information comes from, how to verify it, and how to find what you need when the documentation is sparse. Security research has the same discipline. It just has different databases and a higher-stakes reason to be thorough.
The Mystery Chest
I didn't know about the Mystery Chest going in, so when it appeared after completing Module 1 it was a welcome surprise. The reward was a 30% XP boost for the next 90 minutes — which, if you time it right and have your next session ready, is a nice nudge to keep your momentum going.
Gamification in learning platforms gets dismissed sometimes, but I think TryHackMe does it well. The XP system, streaks, and module rewards make progress feel tangible in a way that's easy to overlook when you're grinding through dense certification material. After studying for the ISC2 CC exam for months, having a platform that literally gives you a treasure chest for finishing a module was genuinely fun.
What I'm Taking Away From Module 1
The offensive/defensive framing is clarifying. Most content I'd encountered treated these as separate tracks. Seeing them side by side in Module 1 helped me understand how they relate — defenders need to understand how attackers think, and vice versa.
My data background is more transferable than I realized. The pattern recognition, the anomaly-chasing, the investigative mindset — these aren't adjacent to cybersecurity. They're central to it. Module 1 made that connection concrete for me.
Hands-on learning hits differently. I've read about SIEMs and incident response in certification material. Walking through a simulated environment made those concepts land in a way that flashcards don't.
Search Skills is underrated. I expected to skim it. I ended up taking notes. If you're transitioning from another field, this room will reframe how you think about sourcing information in a security context.
The platform is well-designed for adult learners. No condescension, no assumed background, and just enough gamification to make progress feel good without feeling hollow.
Up Next: Linux Fundamentals
Module 2 moves into the command line. As someone who lives in SQL and BI tools, this is the part of the journey where things get genuinely new for me. I'll be writing about what it's like to step into Linux as a data analyst — the familiar parts, the uncomfortable parts, and everything in between. Follow along.
Final Thoughts
If you've been sitting on the fence about TryHackMe — whether you're a career changer, a data professional curious about security, or just someone who wants hands-on practice alongside cert studying — Module 1 is a low-stakes, high-value place to start. It won't overwhelm you. It will orient you.
For me, it confirmed something I've been feeling for a while: I'm not starting from zero in this field. I'm translating skills I already have into a new domain. That's a different kind of hard — and it's the kind of hard I'm up for.
More to come as I work through Module 2. If you're on TryHackMe, I'm Cirrus925 — drop your username in the comments and let's connect. I'd love to know who else is working through this path.
Enjoying DataSec Chronicles?
Subscribe to follow my cybersecurity transition in real time — from certs to labs to job search strategy.
Comments