DEV Community: Soumya Khaskel

TryHackMe - Fresher's guide to rule become top 20% easily.

Soumya Khaskel — Wed, 08 Apr 2026 17:29:18 +0000

Confused Where to Start on TryHackMe? Here Are 30 Free Rooms — Sequenced for CEH Prep

I've been preparing for the CEH exam (sitting May 2026) while working in SOC
operations, and I noticed the same problem coming up constantly in every
cybersecurity Discord and subreddit:

"I just signed up for TryHackMe. Where do I even start?"

Most answers are vague. "Just do rooms." "Follow a path." Nobody maps it out
clearly, tells you which rooms are actually free, or sequences them in a way
that aligns to a specific goal like CEH.

So I did it myself.

What This Guide Is

A curated list of 30 free TryHackMe rooms across 7 progressive phases —
every room mapped to a CEH domain, with a time estimate and direct URL.

It's designed for:

Students actively prepping for CEH v12
CS / MCA / BCA students who want hands-on skills alongside theory
Developers transitioning into cybersecurity (your web dev background = unfair advantage on the web hacking phases)
Anyone who opened TryHackMe and had no idea where to click first

Why TryHackMe for CEH Prep?

The CEH exam tests 20 knowledge domains — footprinting, scanning, exploitation,
web app hacking, cryptography, and more.

Most candidates study theory but arrive at the exam having never:

Run a real Nmap scan against a live target
Intercepted an HTTP request with Burp Suite
Cracked a hash in a terminal
Used Metasploit against an actual vulnerable machine

TryHackMe puts you inside a live vulnerable environment, guided by tasks
that mirror exactly what CEH tests — in the order CEH tests them.

The 7-Phase Roadmap

Phase 1 — Orientation & Setup (~45 min)

Get comfortable with the THM interface before diving in.

#	Room	Time	CEH Domain
01	Tutorial	10 min	Interface basics
02	Starting Out in Cyber Sec	20 min	CEH mindset
03	Introductory Researching	30 min	OSINT basics

Phase 2 — Linux & Networking Core (~6 hr)

Your Linux coursework helps here — but the attack context is completely
different from academic learning. Do all 8 rooms.

#	Room	Time	CEH Domain
04	Linux Fundamentals Part 1	1 hr	System Hacking
05	Linux Fundamentals Part 2	1 hr	System Hacking
06	Linux Fundamentals Part 3	1 hr	System Hacking
07	What is Networking?	45 min	Footprinting
08	Intro to LAN	45 min	Footprinting
09	OSI Model	30 min	Sniffing
10	DNS in Detail	45 min	Footprinting
11	HTTP in Detail	45 min	Web App Hacking

Phase 3 — Reconnaissance & Scanning (~6 hr)

CEH's biggest domains. Nmap alone accounts for 3–5 exam questions.
Do not rush these.

#	Room	Time	CEH Domain
12	Nmap	2 hr	Scanning Networks
13	Nmap Live Host Discovery	1.5 hr	Scanning
14	Passive Reconnaissance	1 hr	Footprinting
15	Active Reconnaissance	1 hr	Footprinting
16	Content Discovery	1.5 hr	Web App Hacking

Phase 4 — Web Application Hacking (~10 hr)

If you have a dev background — React, Node, Django, Laravel, anything —
you'll move faster here than 90% of people. You already understand
request-response cycles, session handling, and how SQL queries get built.
Now you exploit them.

#	Room	Time	CEH Domain
17	How Websites Work	45 min	Web App Hacking
18	OWASP Top 10 — 2021	3–4 hr	Web App Hacking
19	Burp Suite: The Basics	2 hr	Web App Hacking
20	SQL Injection	2 hr	SQL Injection
21	Cross-site Scripting	1.5 hr	Web App Hacking
22	File Inclusion	1.5 hr	Web App Hacking

The OWASP Top 10 room is the crown jewel of this phase. Each task is
a separate OWASP category with a live lab. Don't rush it.

Phase 5 — Exploitation & Post-Exploitation (~9.5 hr)

Metasploit is explicitly tested in CEH. This is not optional.

#	Room	Time	CEH Domain
23	Metasploit: Introduction	1.5 hr	System Hacking
24	Metasploit: Exploitation	2 hr	System Hacking
25	Metasploit: Meterpreter	1.5 hr	System Hacking
26	Hydra	1 hr	Password Cracking
27	John the Ripper	1.5 hr	Cryptography
28	Encryption — Crypto 101	2 hr	Cryptography

Phase 6 — Beginner Practice Machines (~9 hr)

No guidance. Just you and the machine. Spend 30 minutes trying before
you look at any walkthrough — the stuck feeling is where learning
actually happens.

#	Room	Time	Type
29	Pickle Rick	1–2 hr	Web + Linux CTF
30	Basic Pentesting	2 hr	Full pentest cycle
31	Ignite	1.5 hr	CMS exploit + privesc
32	Bounty Hacker	1.5 hr	FTP → SSH → privesc
33	RootMe	2 hr	File upload + SUID

Phase 7 — Intermediate Machines (post-CEH territory)

These expect you to enumerate independently and research on your own.
This is where HTB-level skills start building.

#	Room	Time	Domain
34	Blue	2–3 hr	EternalBlue (MS17-010)
35	Ice	2–3 hr	Icecast exploit → Meterpreter
36	Crack the Hash	2 hr	Multi-format hash cracking
37	Advent of Cyber (Archive)	Ongoing	All CEH domains

Advent of Cyber archives are free year-round. 25 challenges covering
every domain. The best free structured content THM offers.

Realistic Timeline

Phases	Time	Daily Commitment
Phases 1–3	~2 weeks	1 hr/day
Phases 4–5	~2 weeks	1 hr/day
Phases 6–7	~2 weeks	Weekends

Download the PDF Version

I packaged this into a printable PDF with checkboxes beside every room —
tick them off as you complete each one.

[Download PDF → GitHub link here - https://github.com/SoumyaKhaskel/TRY_HACK_ME]

One Last Thing

The most common mistake I see: people complete rooms but don't document
anything. Every room you finish, write two sentences about what you learned.
Paste it into a Notion doc, a private GitHub repo, anywhere. Those notes
become your interview answers six months from now.

If this helped you, share it with someone else who's been staring at the
THM homepage not knowing where to start.

Good luck. The struggle is the lesson.

— Soumya | LinkedIn |
GitHub |
THM Profile

I Built an AI Cybersecurity Agent for $0 — And It Runs 24/7

Soumya Khaskel — Sun, 05 Apr 2026 05:39:40 +0000

I Built an AI Cybersecurity Agent for $0 — And It Runs 24/7

Most people “learn cybersecurity” by reading.

I built something that does it live.

🚀 The Idea

I wanted a system that:

Tracks real-world cyber threats continuously
Filters noise
Alerts me instantly when something critical happens

So I built an AI-powered cybersecurity agent that runs every 30 minutes and sends alerts directly to my phone.

⚙️ What It Does

Fetches cybersecurity news from:
- CISA
- The Hacker News
- Krebs on Security
- BleepingComputer
Processes each article using:
- Groq + Llama 3.1
Generates:
- 2-line plain-English summary
- Severity classification → Critical / High / Medium / Low
Sends:
- 🚨 Telegram alert for Critical threats

🧩 System Architecture

This isn’t a chatbot. It’s a real pipeline:

Fetch → RSS sources
Deduplicate → SHA-256 hashing
AI Tagging → Summary + severity
Store → SQLite
Serve → FastAPI
Display → Dashboard
Alert → Telegram

As shown in the architecture diagram (page 4 of documentation), each stage is isolated and independently replaceable.

🧱 Tech Stack (100% Free)

Backend → FastAPI
AI → Groq (Llama 3.1)
Scheduler → APScheduler
Database → SQLite
Hosting → Railway
Frontend → Vercel
Alerts → Telegram Bot

💡 Total cost: $0

🔥 Key Engineering Decisions

Deduplication

Using SHA-256 URL hashing prevented ~60–70% duplicate processing (huge API savings).

Structured Prompting

Instead of free text, the AI outputs strict JSON → easier parsing and reliability.

Alert Control

alerted=1 flag ensures no duplicate notifications.

📊 What Makes This Valuable

This project is not theoretical.

Every article = real threat intelligence
Every CVE = real vulnerability
Every alert = something worth investigating

As described in the project outcomes (page 13), this acts as a live threat intelligence database + learning system.

🧠 What I Learned

Building real AI pipelines (not demos)
Debugging deployment issues (CORS, Linux case sensitivity, Git conflicts)
Designing scalable data flows
That debugging teaches more than tutorials

🔮 What’s Next

IOC extraction (CVE, IPs, domains)
Personal threat watchlist
Weekly AI threat digest
Inline URL scanner

(Planned improvements outlined on page 15)

🌐 Live Project

Dashboard: https://cybersec-news-agent.vercel.app/
GitHub:https://github.com/SoumyaKhaskel/cybersec-news-agent

🧭 Final Thought

Reading builds knowledge.
Building creates capability.

If you're preparing for CEH or Security+, stop just consuming.

Build something that watches the real world.

Network Optimization Guide (Gaming/Streaming)

Soumya Khaskel — Sat, 28 Mar 2026 06:18:56 +0000

How I Reduced Gaming Latency by 192ms on a Locked ISP Network

🔗 Project Repository

GitHub: https://github.com/SoumyaKhaskel/Network-router-optimization.git

Most gaming setup posts focus on GPU, RAM, or CPU tuning.

This one is about the part people usually ignore: the network path.

I worked on a single NAT home network with an ISP-locked ONT and limited router access, then documented every change with before/after testing. The goal was simple: reduce latency spikes, stabilize the connection, and improve responsiveness for CS2 and Valorant.

What I was dealing with

The setup had a few hard constraints:

ISP-locked main gateway
No custom firmware support on the existing router hardware
No proper port-forwarding control from the admin panel
Windows 11 Home, so no Group Policy editor for QoS
Bufferbloat on the download side under load

That meant the fix had to be practical, measurable, and done mostly from the OS side.

Baseline testing first
Before changing anything, I measured the network.

A few key baseline findings:

Google DNS averaged around 43ms
Cloudflare DNS averaged around 4–5ms
Fast.com showed idle latency of 3ms but loaded latency of 64ms
Waveform bufferbloat testing confirmed download-side bufferbloat
The peak download ping was high enough to fail low-latency gaming thresholds

That gave me a clear starting point. No guessing. Only data.

What I changed:

1) Switched DNS to Cloudflare

The DNS tests made the decision obvious. Cloudflare was much faster than the ISP default, so I configured 1.1.1.1 / 1.0.0.1 directly on the Windows adapter, including IPv6, to avoid fallback to the ISP resolver.

2) Locked the gaming PC to a static IP

DHCP changes were a problem for consistency, so I set a manual static IP on the Windows Ethernet adapter. That made the machine easier to target for QoS and kept the address stable across reboots.

3) Verified MTU

I checked MTU using the DF flag ping method and confirmed MTU 1500. No fragmentation changes were needed.

4) Applied DSCP 46 QoS for game traffic

For real-time UDP traffic, I applied DSCP 46 (Expedited Forwarding) for CS2 and Valorant through Windows registry-based QoS policy entries, since Windows 11 Home does not provide the usual Group Policy path.

5) Tuned the TCP stack

I used TCP Optimizer to improve the Windows TCP stack behavior for latency-sensitive traffic. One setting, TCP Chimney, caused upload latency spikes on my NIC, so I reverted it after testing. That part mattered: I kept only what was actually stable.

What did not work
Not every route was available.

The router hardware did not support the firmware path I wanted
The ISP ONT was locked
Port forwarding was blocked by the admin panel
Router-level DNS changes did not fully apply as expected
That is normal in real-world consumer networking. The important part is documenting the ceiling, not pretending it does not exist.

Results

The improvements were measurable:

Google DNS max spike dropped from 228ms to 36ms
Google DNS average dropped from 45ms to 32ms
Download-side bufferbloat improved from 41ms spike to 34ms
Peak download ping dropped from 82.4ms to 57.49ms

The network was better after optimization, but the remaining bufferbloat was still limited by ISP hardware. That meant the final fix would require a compatible router with SQM support, not just software tuning.

Main takeaway

The biggest lesson was this: If download latency spikes while upload stays clean, the bottleneck is often inside the ISP hardware.
You can still improve performance from the OS side, but there is a hard ceiling when the modem/ONT cannot be controlled.

What I learned
DNS choice can make a real difference depending on location
DSCP 46 is the correct priority class for time-sensitive UDP traffic
MTU should be verified, not assumed
TCP tweaks should always be benchmarked
Static IP at adapter level is often more reliable than router-side reservation in locked environments
Bufferbloat fixes are limited if the ISP hardware cannot be replaced.