Post cover image

September 26, 2026

Cybersecurity Journey — Week 1: The CIA Triad & My First Hands-On Steps

Starting from zero. Every command explained, every step reproducible — follow along even if you’ve never touched a security tool before.

By Neha Khan • AI & Software Engineer

10 min read

Why I'm doing this

I'm a full-stack developer moving into security. I've spent years building systems — now I want to understand how they break and how to defend them. This series documents that journey from literally day one, written so a complete beginner (including past-me) can read it and immediately go try everything themselves.

None

The Concept: The CIA Triad

Every security decision, every attack, every tool comes back to three ideas: Confidentiality, Integrity, and Availability. Let's break down each one with a real scenario — how an attacker targets it, and how defenders prevent it.

1. Confidentiality — only the right people can access the data

Real-world example: A company's customer database (names, emails, passwords) gets leaked online after a breach.

How attackers go after it:

  • Phishing — tricking an employee into entering their login credentials on a fake page
  • SQL Injection — exploiting a vulnerable login form to pull entire database tables directly
  • Weak/reused passwords — using leaked credentials from one breach to log into other accounts (credential stuffing)
  • Unencrypted data in transit — intercepting data sent over plain HTTP instead of HTTPS (man-in-the-middle attack)
  • Misconfigured cloud storage — an S3 bucket or database left publicly accessible by mistake

How defenders prevent it:

  • Encrypt data both at rest (in the database) and in transit (HTTPS/TLS)
  • Use parameterized queries/prepared statements to prevent SQL injection
  • Enforce multi-factor authentication (MFA) so a stolen password alone isn't enough
  • Apply the principle of least privilege — users/services only get access to what they actually need
  • Regularly audit cloud storage and access permissions

2. Integrity — the data hasn't been tampered with

Real-world example: An attacker secretly modifies a software update before it reaches users (a supply-chain attack), inserting malicious code that looks legitimate.

How attackers go after it:

  • Man-in-the-middle attacks — intercepting and altering data as it travels between two parties
  • Supply-chain compromise — injecting malicious code into a trusted software update or dependency
  • SQL injection (again) — this time used to modify records, not just read them (e.g., changing an account balance)
  • Malware/rootkits — silently altering files or system behavior without detection

How defenders prevent it:

  • Use checksums/hashes to verify a file hasn't changed (compare the hash before and after download)
  • Digitally sign software releases so tampering is detectable
  • Use version control and audit logs to track every change to critical data
  • Validate and sanitize all user input server-side

3. Availability — the system is reachable when needed

Real-world example: A flood of fake traffic (a DDoS attack) overwhelms a website's servers, knocking it offline for legitimate users.

How attackers go after it:

  • DDoS (Distributed Denial of Service) — flooding a server with traffic from thousands of compromised devices (a botnet)
  • Ransomware — encrypting a company's systems/files so nothing is accessible until a ransom is paid
  • Resource exhaustion attacks — exploiting a slow/expensive endpoint to overload server resources with minimal effort

How defenders prevent it:

  • Use a CDN and DDoS protection service (e.g., Cloudflare) to absorb and filter malicious traffic
  • Maintain regular, tested backups so ransomware can't hold data hostage
  • Implement rate limiting on APIs and endpoints
  • Design redundant infrastructure (load balancers, failover servers) so no single point of failure takes the whole system down

Keep these three words in your head. Every tool below teaches you something about protecting or attacking one of them.

How this connects to what I already know as a developer

I've built login systems, stored user data, deployed APIs. I never thought hard about how someone would break what I built — I just followed best practices because a tutorial told me to. This week, seeing why those practices exist (hashing passwords, setting security headers) hit differently than just implementing them blindly.

Hands-On: Getting Started on TryHackMe

  1. Create a free account at tryhackme.com
  2. Go to the Pre Security path: tryhackme.com/path/outline/presecurity
  3. Enroll and open the first module
None

The Concept: What is Offensive Security?

Offensive security flips the usual mindset: instead of just building defenses, you think like an attacker to find weaknesses before a real attacker does. This is where terms like "penetration testing," "ethical hacking," and "red teaming" come from — all of it is offensive security done with permission, to make systems safer.

Think of a company as a house. These three terms describe different ways of testing how secure that house is:

  • Penetration Testing — you're hired to check if one specific door or window can be broken into. Narrow, focused, time-boxed. Example: "test if our website's login page can be hacked."
  • Ethical Hacking — the general term for someone using hacker skills legally, with permission. Pen testing falls under this umbrella, but so does other stuff, like getting paid to find bugs in an app (bug bounty hunting).
  • Red Teaming — instead of just checking the front door, you try to break in any way possible — the door, a window, tricking a family member into letting you in, sneaking in through the garage. It tests the whole house and whether anyone notices you got in, not just one weak point.

The core idea: you can't defend well against attacks you don't understand. So offensive security teaches you to actually perform the attack techniques (in safe, legal lab environments like TryHackMe) so you learn how real intrusions happen.

Why it matters: every defensive concept from the CIA Triad section above has a matching offensive technique. Confidentiality gets tested by trying to access data you shouldn't. Integrity gets tested by trying to modify something you shouldn't. This module is your first taste of actually doing that, instead of just reading about it.

None None

Hands-On: Finding Hidden Pages with dirb

None

Websites sometimes have pages that exist on the server but aren't linked anywhere you can click — like an old admin panel or a page still available even though it should be locked down. dirb finds these by trying thousands of common page names against a site and checking which ones actually respond.

The scenario: TryHackMe's "FakeBank" room gives you a live target — a fake banking site — and asks you to find hidden pages a real user would never stumble onto.

The command:

dirb http://fakebank.thm

What happened when I ran it:

DIRB v2.22
By The Dark Raver
----------------------------
---- Scanning URL: http://fakebank.thm/ ----
+ http://fakebank.thm/bank-transfer (CODE:200|SIZE:4663)
+ http://fakebank.thm/images (CODE:301|SIZE:179)
----------------------------
DOWNLOADED: 4610 - FOUND: 2

Out of 4,610 page names it tried, two actually existed on the server:

  • /images — likely just a media folder, low risk
  • /bank-transfer — a page that lets you transfer money, sitting completely unlinked from the actual site's navigation
None

Why this matters: /bank-transfer is the real finding here — a sensitive banking function with no login wall and no link pointing to it from the real site. Anyone who guesses or brute-forces the URL can reach it directly. This is exactly the kind of "hidden but not actually protected" page that dirb is built to catch, and it's a mistake that shows up in real-world breaches — hiding a page is not the same as securing it.

Prevention: never rely on a page being "hard to find" as its only protection. Every sensitive function (like a money transfer) needs proper authentication, regardless of whether it's linked in the site's menu or not.

Hands-On: Attacking the Hidden Admin Page

Finding a hidden page is only half the story — the real question is whether it actually does something dangerous. This task proves it.

The scenario: Remember the /bank-transfer page dirb found earlier? It turns out that page isn't just visible — it's fully functional, with no login or authorization check. Anyone who knows (or guesses) the URL can use it.

Steps:

  1. Go to http://fakebank.thm/bank-transfer
  2. Enter the account number 8881 (visible right on the bank's homepage — no login needed to see that either)
  3. Deposit an amount that brings the balance from negative back to positive
  4. Go back to the account page and confirm the balance turned positive
None

Why this matters: This is a textbook example of broken access control — one of the most common and dangerous web vulnerabilities (it's #1 on the OWASP Top 10, which you'll likely cover in a later week). The page existed, had zero authentication, and let anyone modify financial data belonging to another account. In a real bank, this would mean an attacker could add money to their own account, drain someone else's, or manipulate transactions — all without ever "hacking" in the dramatic sense. They just found an unlocked door.

Connecting it back to the CIA Triad: this breaks Integrity — the account balance data was modified by someone who had no right to change it — and arguably Confidentiality too, since the account number was exposed with no protection.

Prevention:

  • Require authentication on every endpoint that modifies sensitive data, not just the "main" login-protected pages
  • Never assume a page is safe just because it isn't linked anywhere (this is the "security through obscurity" mistake from Task 3)
  • Implement proper authorization checks — even a logged-in user should only be able to modify their own account, not any account number they type in

First room, officially done. Four tasks, 32 points, and one real vulnerability found and exploited from scratch — not just read about. This is what "learning by doing" actually looks like: no prior security experience, just following the process and understanding why each step worked.

None

One room down, a long path ahead — but the first step is always the hardest, and that one's behind me now. 🎯

None

Beyond TryHackMe: Recon Commands Every Beginner Should Know

Before running any real commands, I wanted my terminal to look and feel like an actual tool for this work — not the default blue Windows console. Here's what I set up:

  • Windows Terminal instead of the legacy console — modern, tabbed, customizable
  • Dark color scheme for that classic security-tool look
  • Cascadia Mono font — clean and easy to read
  • Oh My Posh — styles the prompt to show my username, current path, and shell type in colored segments instead of plain text
None

Small thing, but it made the terminal feel like a real workspace instead of just a leftover Windows utility — and it makes for much cleaner screenshots going forward in this series.

TryHackMe walks you through tools in a browser lab — but these basic commands work on your own machine right now, no lab needed. They're the actual first moves used in real reconnaissance, by both attackers mapping a target and defenders diagnosing their own systems.

whoami Shows the current logged-in user. Attackers use this after gaining access to see whose permissions they now have.

ipconfig (Windows) / ifconfig (Mac/Linux) Shows your machine's IP address and network interfaces — your device's digital "address."

netstat -a Lists active network connections and listening ports on your machine — how you'd spot something suspicious "phoning home."

ping google.com Sends small packets to check if a host is reachable and how long the round trip takes.

tracert google.com (Windows) / traceroute google.com (Mac/Linux) Think of visiting a website like mailing a letter that passes through several sorting offices before reaching its destination — it doesn't go directly, it hops through checkpoints. tracert shows you every one of those checkpoints (called "hops") between your computer and the website.

My actual output:

1    6 ms    3 ms    3 ms   192.168.100.1
2   60 ms   27 ms   13 ms   202.163.100.239
3   35 ms   38 ms   57 ms   [still resolving...]

What each column means:

  • Column 1 (1, 2, 3…) = the hop number — which checkpoint this is, in order
  • The three "ms" numbers = three separate test pings to that same checkpoint, showing how long each one took (in milliseconds). Three tests instead of one just gives a more reliable reading.
  • The IP address at the end = the actual address of that checkpoint

What my three hops actually were:

  • Hop 1: my own home router — the very first stop, which is why it's so fast (3–6 ms)
  • Hop 2: my internet provider's router — one step further out, so slightly slower (13–60 ms)
  • Hop 3: the next server further along the path toward Google

Eventually, after enough hops, you reach the destination itself (Google's server).

None

Why this matters: dirb found a hidden page on a target website earlier — these commands do the same kind of "mapping" job, just at the network/machine level instead of the web-page level. Same mindset, different layer.

Why This Matters for You, Too

If you're reading this with zero background — that's exactly who this series is for. A week ago, I hadn't run a single security command in my life. Today, I found a real vulnerability, exploited it myself, and understood why it worked, not just followed steps blindly.

Cybersecurity isn't reserved for people with years of networking experience or a computer science PhD. It's built on patience and curiosity — trying a command, seeing what breaks, asking "why did that happen?" The tools (TryHackMe, dirb, a terminal) are free and available to anyone. The only real requirement is showing up and being willing to feel like a beginner for a while.

If a full-stack developer with zero prior security experience can find and exploit a real vulnerability in one sitting, you can too. Pick one thing from this article — even just creating a TryHackMe account — and start today. The rest builds from there, one small win at a time.

What's Next

I've found the offensive side of security — now it's time for the other half of the story: Defensive Security. Next week, I'll be looking at this exact same kind of vulnerability from the blue team's perspective — how you'd actually detect and stop what I just did.

None

#CyberSecurity #EthicalHacking #TryHackMe #CyberSecurityForBeginners #LearningInPublic