add new writeups (#2)

* Add Bandit Level 21 to Level 22 writeup

* Add Bandit Level 22 to Level 23 writeup

* Add TryHackMe Pre-Security Module 3 writeup

Author: Denarzai

_posts/2026-07-03-bandit-level-21-22.md

@@ -0,0 +1,101 @@
+---
+title: "OverTheWire Bandit: Level 21 to Level 22"
+date: 2026-07-03 08:33:00 +0500
+categories: [CTF, Bandit]
+tags: [linux, cron, crontab, scheduled-tasks, overthewire, beginner]
+---
+
+## The Goal
+
+A program is running automatically at regular intervals via cron. Find what it does and use it to get the password for bandit22.
+
+## What is Cron
+
+Cron is a time-based job scheduler built into Linux. It runs commands automatically at specified times without any user interaction. You define tasks in a crontab file and cron executes them in the background on schedule.
+
+## What I Did
+
+Navigated to `/etc/cron.d/` where cron job configurations are stored:
+
+```bash
+bandit21@bandit:~$ cd /etc/cron.d/
+bandit21@bandit:/etc/cron.d$ ls
+behemoth4_cleanup  clean_tmp  cronjob_bandit22  cronjob_bandit23  cronjob_bandit24  e2scrub_all  leviathan5_cleanup  manpage3_resetpw_job  otw-tmp-dir
+```
+
+Read the bandit22 cron job:
+
+```bash
+bandit21@bandit:/etc/cron.d$ cat cronjob_bandit22
+@reboot bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null
+* * * * * bandit22 /usr/bin/cronjob_bandit22.sh &> /dev/null
+```
+
+Two entries for the same script — `@reboot` runs it once when the server boots, `* * * * *` runs it every minute. The `&> /dev/null` discards all output so nothing is printed to any terminal.
+
+Read the script itself:
+
+```bash
+bandit21@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit22.sh
+#!/bin/bash
+chmod 644 /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
+cat /etc/bandit_pass/bandit22 > /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
+```
+
+The script does two things every minute:
+1. Sets the permissions on a file in `/tmp` to `644` — world readable
+2. Writes bandit22's password into that file
+
+Since the file is world readable, anyone can read it including bandit21:
+
+```bash
+bandit21@bandit:/tmp$ cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv
+RYVux2rHEm9tiXHmLFzuR7Vhx6AZQMEz
+```
+
+## Understanding the Crontab Format
+
+The five fields before the username define the schedule:
+
+```
+* * * * * bandit22 /usr/bin/cronjob_bandit22.sh
+│ │ │ │ │
+│ │ │ │ └── day of week (0-7, 0 and 7 = Sunday)
+│ │ │ └──── month (1-12)
+│ │ └────── day of month (1-31)
+│ └──────── hour (0-23)
+└────────── minute (0-59)
+```
+
+`*` means every value for that field. So `* * * * *` runs every minute of every hour of every day.
+
+Some examples:
+- `0 * * * *` — every hour at minute 0
+- `0 9 * * *` — every day at 9am
+- `0 9 * * 1` — every Monday at 9am
+- `30 6 1 * *` — 6:30am on the 1st of every month
+
+`@reboot` is a special keyword that runs the job once when the system starts, regardless of time.
+
+## What I Tried That Didn't Work
+
+Tried to list and navigate `/tmp` directly — permission denied. The `/tmp` directory itself was restricted so you can't browse it with `ls` or `find`. But you can still read a specific file inside it if you know the exact path and the file has read permissions. The script set `chmod 644` on the file which made it readable by everyone, so `cat /tmp/filename` worked even though listing the directory didn't.
+
+## What I Learned
+
+**Cron jobs run as a specific user.** The username in the crontab entry (`bandit22`) determines whose privileges the script runs with. This script runs as bandit22, which is why it can read `/etc/bandit_pass/bandit22`.
+
+**`/etc/cron.d/` contains system-wide cron jobs.** Individual user cron jobs live in `/var/spool/cron/crontabs/`. The `/etc/cron.d/` directory is readable by all users — useful for reconnaissance when you have access to a system.
+
+**Cron jobs writing to world-readable files is a misconfiguration.** If a privileged cron job writes sensitive data to a location other users can read, that data is exposed. This is a real-world finding in penetration tests.
+
+**You don't need to list a directory to read a file in it.** If you know the exact filename and the file has read permission, `cat /path/to/file` works regardless of whether you can `ls` the directory.
+
+## Commands Used
+
+| Command | What it did |
+|---|---|
+| `ls /etc/cron.d/` | Found the cron job configurations |
+| `cat cronjob_bandit22` | Read the schedule and script path |
+| `cat /usr/bin/cronjob_bandit22.sh` | Read what the script actually does |
+| `cat /tmp/t7O6lds9S0RqQh9aMcz6ShpAoZKF7fgv` | Read the password written by the cron job |

_posts/2026-07-03-bandit-level-22-23.md

@@ -0,0 +1,94 @@
+---
+title: "OverTheWire Bandit: Level 22 to Level 23"
+date: 2026-07-03 08:53:00 +0500
+categories: [CTF, Bandit]
+tags: [linux, cron, md5sum, cut, bash-scripting, overthewire, beginner]
+---
+
+## The Goal
+
+Another cron job running automatically. This time the script is more complex — it generates a filename using a hash and writes the password there. The challenge is figuring out what filename the script generates when it runs as bandit23.
+
+## What I Did
+
+Checked `/etc/cron.d/` and read the bandit23 cron job:
+
+```bash
+bandit22@bandit:/etc/cron.d$ cat cronjob_bandit23
+@reboot bandit23 /usr/bin/cronjob_bandit23.sh  &> /dev/null
+* * * * * bandit23 /usr/bin/cronjob_bandit23.sh  &> /dev/null
+```
+
+Read the script:
+
+```bash
+bandit22@bandit:/etc/cron.d$ cat /usr/bin/cronjob_bandit23.sh
+#!/bin/bash
+myname=$(whoami)
+mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1)
+echo "Copying passwordfile /etc/bandit_pass/$myname to /tmp/$mytarget"
+cat /etc/bandit_pass/$myname > /tmp/$mytarget
+```
+
+The script runs as bandit23 via cron. That means `$(whoami)` returns `bandit23`. The filename is generated by hashing the string `I am user bandit23` with md5sum and cutting the output to just the hash.
+
+I needed to calculate that hash myself since the script runs as bandit23 but I'm logged in as bandit22:
+
+```bash
+bandit22@bandit:/tmp$ echo "I am user bandit23" | md5sum >> t1
+bandit22@bandit:/tmp$ cat t1
+8ca319486bfbbc3663ea0fbe81326349  -
+```
+
+The hash is `8ca319486bfbbc3663ea0fbe81326349`. Read the file at that path:
+
+```bash
+bandit22@bandit:/tmp$ cat 8ca319486bfbbc3663ea0fbe81326349  -
+gKXDTAXnIz3OBxiPjRZ2uqutUlPZrBsw
+```
+
+## Understanding the Script
+
+Breaking down the key line:
+
+```bash
+mytarget=$(echo I am user $myname | md5sum | cut -d ' ' -f 1)
+```
+
+Three commands chained with pipes:
+
+**`echo I am user $myname`** — outputs the string `I am user bandit23`
+
+**`md5sum`** — takes that string and produces a hash. MD5 is a cryptographic hash function — it takes any input and produces a fixed-length 32-character hex string. The same input always produces the same output, but you can't reverse it to get the original. The raw output looks like:
+```
+8ca319486bfbbc3663ea0fbe81326349  -
+```
+The `  -` at the end means md5sum was reading from stdin.
+
+**`cut -d ' ' -f 1`** — splits the output by spaces and keeps only the first field. Without this, the filename would include the `  -` suffix which would be messy. `cut` strips it down to just the clean hash string.
+
+The resulting hash becomes both the filename and an indirect reference to who the script ran as — you can only figure out the filename if you know it was generated from `I am user bandit23`.
+
+## What I Tried That Didn't Work
+
+Initially tried using `$mytarget` as a variable in my own shell — but that variable doesn't exist in my session, only inside the script when it runs as bandit23. So `cat /tmp/$mytarget` expanded to `cat /tmp/` which is a directory.
+
+The fix was to manually calculate the hash value myself using the same commands the script uses, substituting `bandit23` as the username.
+
+## What I Learned
+
+**`$(command)` is command substitution.** Whatever is inside `$()` gets executed and its output becomes the value. So `myname=$(whoami)` stores the output of `whoami` into the variable `myname`.
+
+**`cut` extracts specific fields from text.** `-d` sets the delimiter character to split on, `-f` specifies which field number to keep. It's commonly used to parse structured output where fields are separated by a consistent character like spaces, colons, or commas.
+
+**MD5 is not secure for cryptography** but is still widely used for non-security purposes like generating consistent filenames from input strings, checksums for file integrity, and similar tasks. For password hashing it's completely broken — too fast to brute force and vulnerable to precomputed rainbow tables. Use bcrypt or Argon2 for passwords.
+
+**Reading a script carefully lets you predict its output** without running it. The key insight here was realising the script runs as bandit23, substituting that username into the hash calculation, and computing the result manually.
+
+## Commands Used
+
+| Command | What it did |
+|---|---|
+| `cat /usr/bin/cronjob_bandit23.sh` | Read the script to understand what it does |
+| `echo "I am user bandit23" \| md5sum` | Calculated the hash the script generates when run as bandit23 |
+| `cat /tmp/8ca319486bfbbc3663ea0fbe81326349` | Read the password from the file the script wrote |

_posts/2026-07-04-tryhackme-presecurity-module-3.md

@@ -0,0 +1,67 @@
+---
+title: "TryHackMe Pre-Security: Module 3 — Operating Systems"
+date: 2026-07-04 04:47:00 +0500
+categories: [Learning, TryHackMe]
+tags: [tryhackme, linux, windows, operating-systems, privilege-escalation, cli, beginner]
+---
+
+## Overview
+
+Module 3 of TryHackMe's Pre-Security path covered operating systems across five rooms — OS fundamentals, Windows basics, Linux CLI, Windows CLI, and a practical privilege escalation exercise. Most of the individual concepts weren't new to me at this point, but working through them in a structured environment filled in gaps and showed me how these pieces connect in real scenarios.
+
+## Room 1 — Operating Systems Introduction
+
+The first room covered what an OS actually does — managing hardware, processes, memory, and user permissions. The key distinction was between **kernel space** and **user space**:
+
+- **Kernel space** — the privileged core of the OS with direct hardware access. The kernel manages everything below the surface.
+- **User space** — where applications run with limited permissions. If an application crashes here it doesn't bring down the whole system.
+
+This distinction matters in security because most privilege escalation attacks are attempts to move from user space into kernel space — or to gain the privileges of a process running closer to the kernel than you should have.
+
+## Room 2 — Windows Basics
+
+Windows interface fundamentals — Task Manager, Windows Security, Defender Firewall, Windows Update. Most of this was familiar from daily use but seeing it framed through a security lens was useful. Task Manager isn't just for killing frozen apps — it's a real-time view of what's running on a system, which is one of the first places you look during incident response to identify suspicious processes.
+
+Windows Defender Firewall controls what network traffic is allowed in and out. Understanding what it does conceptually is important before getting into firewall rule analysis in later modules.
+
+## Room 3 — Linux CLI Basics
+
+Navigating the Linux filesystem, searching for files, reading configuration files, inspecting system information. Most of this I already knew from working through OverTheWire Bandit — `ls`, `cat`, `find`, `grep` and the logic of Linux file permissions were all covered there in much more depth and with actual problem solving rather than guided exercises.
+
+What Bandit teaches through challenges, this room taught through explanation. Having done Bandit first meant I already had the practical intuition and this room just gave me the formal framing around concepts I'd already applied.
+
+## Room 4 — Windows CLI Basics
+
+The Windows Command Prompt equivalent of the Linux CLI room — navigating files, locating hidden files, reading file contents, gathering system and network information from the terminal. The key takeaway applies to both operating systems: the command line gives you speed, precision, and the ability to automate tasks that would take many clicks in a GUI.
+
+In real-world security work, you often can't rely on a GUI — remote access, restricted environments, and incident response scenarios all require CLI comfort on both Windows and Linux.
+
+## Room 5 — Privilege Escalation Practical
+
+The most hands-on room of the module. A complete attack chain on a Linux system:
+
+1. SSH into the system as `sammie`
+2. Lateral movement to `johnny`
+3. Escalation to `root`
+4. Retrieve the flag from `/root/flag.txt`
+
+A few things worth noting from working through this:
+
+**Typos cost time.** Multiple failed `su` attempts because of `jhonny` and `jhony` instead of `johnny`. Running `whoami` and `id` first to confirm your current user context before attempting account switches prevents this — something I'll carry forward.
+
+**Credentials get exposed in unexpected places.** Passwords discovered through shell history and sticky notes. In a real assessment this is one of the first places to look after gaining initial access.
+
+**Privilege escalation is a chain, not a single step.** Moving from sammie → johnny → root required understanding each stage — what credentials were available, which user had access to what, and how to move progressively through the access chain.
+
+## The Bigger Picture
+
+What this module solidified wasn't individual commands — it was seeing how these pieces connect. Kernel space versus user space explains why privilege escalation is possible and what it means. The Linux file permission system I learned in Bandit is what makes setuid binaries and misconfigured files exploitable. The Windows security tools are the defensive layer that attackers try to bypass.
+
+The concepts are no longer isolated facts. They're parts of a system I can now see working together.
+
+## What's Next
+
+Module 4 covers networking fundamentals — how data actually moves across networks at the protocol level. This is where the conceptual groundwork from the first three modules starts becoming directly applicable to understanding attacks.
+
+---
+*TryHackMe username: sdenarzai786*