TryHackMe OWASP Top 10 2025 Walkthrough Security Misconfigs, Supply Chain, Crypto Failures & Insecure Design

🎯 Room Info

📖 What This Room Is About

This room is different from the others in this series — instead of one vulnerability, it's a guided tour through four related categories from the OWASP Top 10 2025, all grouped under the theme of application design flaws: bugs that exist not because a developer made a typo, but because a fundamental design or configuration decision was wrong from the start.

The four sections:

1. ⚙️ Security Misconfigurations — insecure defaults, exposed debug endpoints, unnecessary services left running
2. 📦 Software Supply Chain Failures — trusting a dependency, package, or build pipeline that shouldn't be trusted
3. 🔐 Cryptographic Failures — weak, outdated, or misused encryption/hashing
4. 🧱 Insecure Design — flaws baked into the architecture itself, not fixable with a patch alone

This is one of the more conceptually important rooms in the series — these categories explain why a huge share of real breaches happen, well beyond any single CTF exploit chain.

🧠 Skills You'll Practice

• Spotting insecure default configurations (debug mode, default credentials, verbose error pages)
• Reasoning about supply chain trust (dependency confusion, unsigned packages, compromised CI/CD)
• Identifying weak or broken cryptographic implementations
• Distinguishing an implementation bug from a design flaw

Part 1 — ⚙️ Security Misconfiguration

What it is

A security misconfiguration happens when a system is deployed with insecure default settings, unnecessary features left enabled, or missing hardening — even though the underlying code might be perfectly fine.

Walkthrough

Start with reconnaissance to spot exposed configuration issues:

nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>

Check for common misconfiguration signatures:

curl -I http://<TARGET_IP>
curl http://<TARGET_IP>/.env
curl http://<TARGET_IP>/debug
curl http://<TARGET_IP>/server-status

Things worth checking:

• Verbose error pages — do stack traces or framework version numbers leak when you trigger an error?
• Default credentials — does an admin panel accept admin:admin or similar?
• Debug endpoints left enabled — Django's DEBUG=True, Flask's debugger, or similar frameworks exposing internals
• Directory listing enabled — browsing to a folder shows a raw file list instead of a 403/404

💡 Why this matters: misconfiguration is consistently one of the most common root causes of real breaches — not because the vulnerability is exotic, but because it's easy to overlook a single "turn this off before production" setting.

🚩 Click to reveal: Part 1 flag

Redacted — swap in your own captured flag if you want to keep a private record.

Part 2 — 📦 Software Supply Chain Failures

What it is

A supply chain failure happens when you trust something you shouldn't — a compromised dependency, a malicious package with a name similar to a legitimate one (typosquatting), or a build/deploy pipeline that isn't properly secured.

Walkthrough

This section is usually more conceptual/investigative than exploit-driven. Typical tasks:

Inspect a project's dependency file:

cat package.json
cat requirements.txt

Look for:

• Dependencies pinned to suspiciously specific or outdated versions
• Package names that look almost right but aren't (reqeusts instead of requests, lodash-es typo variants, etc.)
• Dependencies pulled from unofficial or unverified sources

Check for exposed CI/CD configuration:

cat .github/workflows/deploy.yml

Look for hardcoded secrets, overly broad permissions, or a pipeline that pulls from an untrusted external script:

- name: Deploy
  run: curl -s http://some-external-domain.com/setup.sh | bash

💡 Why this matters: piping a remote script straight into bash is a textbook supply chain risk — you're trusting that external server to serve exactly what you expect, forever, with no verification. This exact pattern has caused real incidents.

🚩 Click to reveal: Part 2 flag

Redacted — swap in your own captured flag if you want to keep a private record.

Part 3 — 🔐 Cryptographic Failures

What it is

Cryptographic failures cover everything from using outdated hashing algorithms (MD5, SHA1 for passwords), to weak encryption, to hardcoded secrets, to sensitive data transmitted without TLS at all.

Walkthrough

Check for weak hashing:

If you can access a database dump or a leaked file containing password hashes:

cat leaked_users.txt

Identify the hash format (hash length and structure are usually enough to fingerprint it):

hashid <hash_value>

If it's an unsalted MD5 or SHA1 hash, crack it:

hashcat -m 0 leaked_users.txt /usr/share/wordlists/rockyou.txt   # MD5
hashcat -m 100 leaked_users.txt /usr/share/wordlists/rockyou.txt # SHA1

Check for hardcoded secrets:

grep -r "SECRET_KEY\|API_KEY\|password" . --include="*.py" --include="*.js" --include="*.env"

Check for missing/weak TLS:

curl -I http://<TARGET_IP>          # Is HTTPS even offered?
sslscan <TARGET_IP>:443             # If HTTPS exists, what ciphers/versions does it support?

💡 Why this matters: an unsalted, fast hash (MD5, SHA1) turns a database leak into an instant password disclosure — hashcat can test billions of guesses per second against these. Proper systems use slow, salted algorithms designed for passwords specifically (bcrypt, scrypt, Argon2).

🚩 Click to reveal: Part 3 flag

Redacted — swap in your own captured flag if you want to keep a private record.

Part 4 — 🧱 Insecure Design

What it is

This is the broadest and most conceptual category. Insecure design means the architecture itself has a flaw — no amount of patching the implementation fixes it, because the problem isn't a bug, it's a decision. Examples: a password reset flow that doesn't rate-limit attempts, a multi-step checkout process that trusts the client to report the final price, or a permissions model that was never actually designed to separate user roles.

Walkthrough

This section usually asks you to identify the flaw conceptually rather than exploit a single clean payload. Common patterns to look for in the provided scenario/app:

Missing rate limiting on sensitive actions:

for i in $(seq 1 50); do
  curl -s -X POST http://<TARGET_IP>/reset-password -d "email=victim@example.com"
done

If nothing blocks or throttles this, the design never accounted for abuse.

Client-trusted business logic (price, quantity, permissions passed from the client):

curl -X POST http://<TARGET_IP>/checkout \
  -H "Content-Type: application/json" \
  -d '{"item_id": 4, "price": 0.01}'

If the server accepts a client-supplied price instead of looking it up server-side, that's an insecure design decision baked into the checkout flow, not a coding typo.

💡 Why this matters: insecure design flaws can't be fixed with input validation alone — they usually require rethinking the architecture (e.g., always deriving price server-side from a product ID, never trusting a client-supplied value for anything security- or money-relevant).

🚩 Click to reveal: Part 4 flag

Redacted — swap in your own captured flag if you want to keep a private record.

📋 Every Command, In Order

# Misconfiguration
nmap -sC -sV -oN nmap-initial.txt <TARGET_IP>
curl http://<TARGET_IP>/.env
curl http://<TARGET_IP>/debug

# Supply chain
cat package.json
cat .github/workflows/deploy.yml

# Cryptographic failures
hashid <hash_value>
hashcat -m 0 leaked_users.txt /usr/share/wordlists/rockyou.txt
sslscan <TARGET_IP>:443

# Insecure design
for i in $(seq 1 50); do curl -s -X POST http://<TARGET_IP>/reset-password -d "email=victim@example.com"; done
curl -X POST http://<TARGET_IP>/checkout -H "Content-Type: application/json" -d '{"item_id": 4, "price": 0.01}'

🎓 Key Takeaways

• Misconfiguration is a hardening problem, not a coding problem. The fix is usually a checklist: disable debug mode, remove default creds, restrict directory listing — before deployment, every time.
• Supply chain trust has to be earned, not assumed. Pin dependency versions deliberately, verify package sources, and never pipe an unverified remote script into a shell during a build.
• Cryptography has "correct" answers — use them. Bcrypt/Argon2 for passwords, TLS everywhere, no hardcoded secrets in source code. These aren't judgment calls; they're solved problems with well-known right answers.
• Insecure design is the hardest category to fix retroactively. It requires questioning "who is allowed to do what, and what do we trust the client to tell us" at the architecture level — not just patching individual endpoints.
• All four categories point at the same underlying lesson: security has to be a design decision made early, not a layer bolted on afterward.

🏁 Series Wrap-Up

That closes out this 10-room TryHackMe series — from Linux fundamentals (Bounty Hacker, Pickle Rick) through classic web vulnerabilities (IDOR, LFI, client-side bypass, subdomain takeover), into more advanced territory (race conditions, Windows forensics, AI prompt injection), and finishing with the broader architectural lessons from the OWASP Top 10.

If you're working through these same rooms yourself: don't just follow along — try breaking the payloads on purpose, see what actually triggers each defense, and build the instinct for why each fix works. That's the difference between finishing a room and actually learning the skill.

Thanks for reading — see the rest of this series on my Dev.to profile
https://dev.to/ashardrach).