Break it in the lab.
Write down what actually happened.
Security research with the reasoning left in. Every write-up runs in an isolated environment, records the commands that worked, and is honest about the ones that did not.
# scope: 10.20.0.0/24 — isolated lab segment, no egress operator@lab:~$ nmap -sV --reason -oA recon 10.20.0.15 Nmap scan report for target-01 (10.20.0.15) Host is up (0.00042s latency). PORT STATE SERVICE VERSION REASON 22/tcp open ssh OpenSSH 8.9 syn-ack ttl 63 80/tcp open http nginx 1.18 syn-ack ttl 63 # a banner is a claim, not evidence operator@lab:~$ note "confirm nginx version before acting on it" saved -> recon/notes.md
What you will find here
Lab write-ups
Full walkthroughs from isolated environments: enumeration, the exploitation path, the dead ends, and the cleanup afterwards.
Tooling notes
Scripts and configs worth keeping, with the reasoning behind each flag rather than a copy-paste dump you cannot debug.
Defence and hardening
Detection, server hardening and post-incident notes. The half of the job that rarely gets written up properly.
Latest write-ups
Hardening a fresh VPS: the first fifteen minutes
Keys before you disable passwords, default-deny firewalling, unattended security upgrades, and why a backup on the same disk is not a backup.
Reading nmap output properly
What open, closed and filtered actually mean, why the version column is a hypothesis rather than a fact, and the two flags worth making a habit.
Building a home lab you are not afraid to break
Segmenting a lab with VLANs, why the target network gets no internet at all, and the snapshot discipline that makes a finding reproducible instead of anecdotal.
Ground rules
Everything here is produced in environments I own or am explicitly authorised to test. No live third-party systems, no client data, no exceptions. If a technique cannot be demonstrated safely in a lab, it does not get published.