yeah this is my portfolio

00 // who

about me

ok so. i'm a systems engineer — or if you want the more accurate term, i'm just someone who's really really good with computers and won't stop until i understand how something works at a fundamental level.

i do security research on bugcrowd whenever the mood strikes, which is more often than "occasionally" and less often than "professionally." it's not a job, it's just what happens when you get curious about how an app handles its auth and can't let it go.

my day-to-day involves a lot of bash, python, some duckscript, html when needed, and a general attitude that every system deserves to be poked at. i have servers running. multiple docker stacks. tmux sessions i haven't closed in weeks. a homelab that keeps growing because apparently i can't stop.

i know networks. like, actually know them — not "i took a class" know them. i've configured vlans, dealt with firewall rules at 2am, debugged weird dns behavior that turned out to be my own fault. that kind of knowing.

cybersecurity specialist? yeah. i know how attacks work because understanding offense is the only way to build anything actually defensive. the attacker mindset isn't a toggle, it's a permanent setting.

bugcrowd researcher systems engineer cybersecurity specialist homelab enjoyer it generalist

primary role

systems engineer

// the catch-all that actually fits

for fun

bugcrowd researcher

// bugs don't hunt themselves

specialization

cybersecurity

// offense-informed, always

homelab status

perpetually expanding

// it never stops

vibe

obsessively technical

// if i'm doing something i'm learning everything about it

whoami.sh

$ whoami systems_engineer + security_researcher $ uname -a linux homelab 6.x.x-generic #1 smp $ cat /etc/personality always_curious=true stops_when_understood=false homelab_services=too_many vibe=immaculate

4 languages

6+ infra domains

∞ tabs open

0 unsolved mysteries

1 homelab

99% terminal usage

01 // what i know

skills & languages

the stuff i actually use. not a checkbox list for a recruiter, just the real stack.

// programming languages

🐍

python

automation, tooling, scripting, data. honestly the language that does everything i need it to do. if i need to build something, python.

primary

⚡

bash

the terminal is home. bash is the language of that home. server automation, pipeline wiring, quick scripts that turn into not-so-quick scripts.

daily driver

🦆

duckscript

cross-platform scripting without the overhead. simple, readable, gets out of the way. useful when bash would be overkill or annoying.

scripting

🌐

html

web layer fundamentals. knowing how the frontend is structured matters a lot when you're probing web apps. also useful for, y'know, building stuff.

web / recon

example.py — python (the real deal)

# typical python workflow — automation + a little probing import requests, json, subprocess from pathlib import Path def probe_api(base: str, endpoints: list) -> dict: """enumerate endpoints, collect interesting responses""" session = requests.Session() results = {} for ep in endpoints: r = session.get(f"{base}{ep}", timeout=5) results[ep] = { "status": r.status_code, "size": len(r.content), "type": r.headers.get("Content-Type", "") } return results $ python3 example.py --target https://target.example.com ✓ mapped 34 endpoints — 2 returned unexpected 200s

setup.sh — bash (as it was meant to be used)

#!/usr/bin/env bash # spin up the whole stack. one command. done. set -euo pipefail SERVICES=("proxy" "scanner" "monitor" "db" "dns") LOG_DIR="$HOME/lab/logs" mkdir -p "$LOG_DIR" for svc in "${SERVICES[@]}"; do docker-compose up -d "$svc" \ && echo "✓ $svc up" \ || echo "✗ $svc failed" done tmux new-session -d -s lab-monitor "./monitor.sh" ✓ all services up — monitor running in tmux session

// technical domains

🐳

containerization

docker expert

docker compose advanced

container networking advanced

custom image builds comfortable

🖥️

server ops

linux admin expert

tmux native

service config advanced

system hardening advanced

🌐

networking + apis

network infra advanced

rest apis expert

dns / routing advanced

traffic analysis comfortable

task.ds — duckscript

# duckscript — underrated, honestly # cross-platform, no dependencies, just works os = os_name echo "running on: ${os}" fn check_service result = exec curl -s -o /dev/null -w "%{http_code}" http://localhost:8080 if equals ${result} "200" echo "✓ service healthy" else echo "✗ service down — status: ${result}" end end ✓ service healthy

02 // for fun

bug hunting

i do this on bugcrowd because it's genuinely interesting, not because i have to.

bugcrowd researcher

finding what others miss
because i actually look

bug bounty programs on bugcrowd are just a good excuse to go deep on a target with permission. the methodology is the same every time: understand the system before you touch it. map everything. then start asking uncomfortable questions.

the most interesting bugs aren't xss injections — they're logic flaws. places where the developer made a reasonable assumption that happens to not hold. those take actual thought, not just a scanner.

do i do this as a job? no. do i do it constantly? kind of. the line between "hobby" and "just what my brain does" has blurred.

01

recon first, always

map the surface before touching anything. subdomain enum, endpoint discovery, tech stack fingerprinting.

02

understand the app

use it like a normal user. find the patterns. identify what assumptions are baked in.

03

break assumptions

do exactly what you're not supposed to do. carefully. methodically. within scope.

04

write it clearly

a good report is reproducible and unambiguous. the finding is only as useful as the write-up.

// research depth

recon

95%

api testing

88%

auth analysis

83%

logic bugs

79%

reporting

91%

scope creep

0%

recon.py — typical session

$ python3 recon.py --target target.example.com [*] starting recon on target.example.com [*] subdomains found: 14 [*] interesting: api.target.example.com [*] interesting: admin.target.example.com [*] probing api endpoints... [?] /api/v1/users — returns more than it should [?] /api/v2/admin — accessible without auth token [*] reproducing manually... [!] confirmed — idor vulnerability in /api/v1/users [!] drafting report

check_auth.sh — auth flow analysis

# check if jwt validation is actually happening TOKEN="eyJhbG..." # tampered ENDPOINT="https://api.target.example.com/user/profile" curl -s -H "Authorization: Bearer $TOKEN" $ENDPOINT \ | python3 -m json.tool { "user": "admin", "role": "superuser", // oh. } signature verification: not enforced

03 // background

experience & depth

security researcher

bugcrowd platform

ongoing · when the mood strikes

participating in public and private bug bounty programs. web app vulns, api weirdness, auth bypasses, logic flaws. the ones that take thought, not just a scanner run. doing it because it's interesting.

systems engineer

self + labs

ongoing · deep technical focus

building and running actual infrastructure. multi-service docker stacks, server management, network design, api integrations, automation pipelines. the kind of work that never fully stops because there's always something to optimize or something new to spin up.

cybersecurity specialist

domain expertise

ongoing · offense-informed defense

understanding how systems break is a prerequisite for knowing how to build them right. threat modeling, attack surface mapping, defensive architecture that actually thinks about real attack vectors instead of checkbox compliance.

homelab architect

personal infrastructure

ongoing · perpetually expanding

this started small. now it's a full network with multiple vlans, a docker host running a bunch of services, custom dns, monitoring dashboards, isolated security testing network, and more. it's production. ish.

general it knowledge

everywhere, honestly

built over time · never stops

not the kind of it knowledge where you google basic things. the kind where you've hit enough weird edge cases and weird failures that you actually understand why things work the way they do.

🔍

vulnerability research

// systematic, methodical, actually fun

🐳

docker & containers

// full lifecycle, no hand-holding

🌐

network infrastructure

// design, configure, troubleshoot, repeat

⚙️

api work (build + abuse)

// integration and probing — same skillset, different intent

🖥️

server administration

// linux-first, headless-comfortable

🔐

security architecture

// defense that thinks like the attacker

📺

tmux power user

// sessions, panes, scripts — the terminal is home

🏠

homelab engineering

// treated like real infra because it is

🛠️

general it

// broad baseline, deep on what matters

04 // systems

infrastructure & operations

the actual stuff that runs. not theoretical, not tutorial-level — real operational experience.

01

🐳

docker environments

container orchestration from single services to complex multi-container stacks. custom networking, volume management, image optimization. built from experience, not documentation.

02

🖥️

server management

linux server administration with focus on reliability and security. configuration management, service monitoring, log analysis, remote management. comfortable in entirely headless environments.

03

📺

tmux mastery

not a novelty — a core workflow tool. persistent sessions, custom layouts, scripted session initialization, remote session management. the terminal is not just a tool, it's the environment.

04

🌐

network infrastructure

network design from the ground up. dns, routing, vlans, firewall rules, traffic segmentation. understanding networks at the packet level, not just the dashboard level.

05

⚙️

api integration

deep familiarity with rest apis — building integrations and probing them for unexpected behavior. auth patterns, rate limiting, endpoint mapping, response analysis. second nature.

06

🏠

home lab engineering

a personal lab that runs production-grade infrastructure for testing, learning, and building. multiple services, isolated networks, custom monitoring. treated like real infrastructure — because it is.

// homelab architecture

🔥

firewall

perimeter

🔀

router

vlan routing

🖧

managed switch

tagged ports

📡

dns resolver

local + upstream

🐳

container host

main docker node

📊

monitoring

dashboards

🔒

security vlan

isolated testing

💾

storage

persistent vols

// network topology — simplified

├─ 🌍 wan (internet) upstream

└─ 🔥 firewall 10.0.0.1 active

├─ 🖥️ vlan 10 — servers 10.10.0.0/24 active

├─ 🐳 vlan 20 — containers 10.20.0.0/24 active

├─ 🔒 vlan 30 — security lab 10.30.0.0/24 isolated

└─ 📊 vlan 99 — management 10.99.0.0/24 restricted

lab_status.sh — daily check

me@homelab:~$ docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" name status ports proxy up 22 days 80->80, 443->443 scanner up 22 days internal monitor up 18 days 3000->3000 dns up 22 days 53->53/udp db up 22 days internal auth-proxy up 5 days 8080->8080 me@homelab:~$ tmux ls lab: 4 windows (created mon) [attached] monitor: 2 windows (background) research: 3 windows (active) me@homelab:~$ uptime up 22 days, 14:32:08 load average: 0.42, 0.38, 0.41

05 // security

cybersecurity specialization

offense-informed. not just "i know what xss is." actually understands the mechanisms.

🔍

vulnerability assessment

// systematic, thorough, not tool-dependent

🌐

web application security

// owasp, injection, auth flaws, logic bugs

⚙️

api security testing

// endpoints, rate limits, data exposure, auth

📡

network security

// traffic analysis, segmentation, exposure mapping

🏠

infrastructure hardening

// reduce attack surface. defense in depth. actually.

🔐

auth & session analysis

// tokens, session management, privilege escalation paths

🧠

threat modeling

// attacker perspective applied to defensive design

📋

security reporting

// reproducible, unambiguous, actionable

the best defenders think like attackers. understanding how systems actually break is the prerequisite for building systems that don't.

// operating philosophy, not a slogan

01. understand the system deeply before looking for flaws. surface-level scanning finds surface-level bugs.

02. think about what assumptions the developer made and whether those assumptions actually hold.

03. business logic vulnerabilities are often more impactful than technical ones. follow the data, follow the money.

04. a finding is only as good as its documentation. reproducibility first, cvss score second.

05. stay in scope. always. the discipline is part of the methodology, not a restriction on it.

06. the goal is understanding, not just finding. knowing why something is exploitable is more valuable than knowing that it is.

threat_model.py

$ python3 threat_model.py --target webapp --verbose [*] mapping attack surface for: webapp [*] auth entry points: 4 identified [*] api endpoints: 31 mapped [*] file upload handlers: 2 detected [*] third-party integrations: 6 [?] session management — non-standard implementation [?] /api/v2/* — no rate limiting detected [!] /upload endpoint — missing content-type validation [✓] threat model complete — 7 vectors prioritized

defense_check.sh — hardening audit

#!/usr/bin/env bash # quick hardening checklist for a new server checks=( "ufw status" "sshd -T | grep -i permitrootlogin" "sshd -T | grep -i passwordauthentication" "systemctl status fail2ban" "cat /etc/sysctl.d/99-sysctl.conf | grep net.ipv4" ) ✓ firewall: active (22 rules) ✓ root login: prohibited ✓ password auth: no (keys only) ✓ fail2ban: running ✓ ip hardening: applied

06 // foundations

general it knowledge

the broad baseline. not a buzzword list — stuff i've actually needed and used.

🖥️

operating systems

linux (various distros)

shell environments

boot & init systems

process management

user & permission models

package management

kernel basics

🌐

networking

tcp/ip fundamentals

dns & dhcp

vlans & trunking

firewalls & acls

subnetting & cidr

packet analysis

routing protocols

🔒

security

encryption & pki

auth flows & tokens

owasp methodology

log analysis

access control models

incident investigation

vulnerability lifecycle

🛠️

tools & platforms

docker & compose

git & version control

tmux & terminal tools

monitoring stacks

web proxies

automation frameworks

text editors (vim, etc.)

⚙️

automation

bash scripting

python automation

duckscript tasks

cron & scheduling

api-driven workflows

event-driven scripts

ci/cd concepts

💾

storage & data

filesystem management

volume configuration

database basics

backup strategies

data serialization

log management

data retention policies

🌍

web & apis

http/https protocol

rest api design

auth mechanisms

proxy & routing

tls & certificates

web server config

cors & csp

🔧

troubleshooting

systematic debugging

log interpretation

network diagnostics

root cause analysis

performance profiling

documentation habits

5-whys methodology

daily_ops.sh — the usual

# a representative day. abbreviated. me@homelab:~$ ssh server.local connected to server [10.10.0.5] me@server:~$ docker stats --no-stream all containers nominal — no memory pressure me@server:~$ tail -100 /var/log/auth.log | grep FAILED 3 failed ssh attempts from 45.33.32.xx me@server:~$ ufw deny from 45.33.0.0/16 && ufw reload rule added. reloaded. me@server:~$ python3 check_services.py ✓ all 6 services healthy. 0 anomalies detected

07 // toolbox

tools i actually use

not a certification dump. the tools that actually exist in my workflow.

🐍python

⚡bash

🦆duckscript

🐳docker

📺tmux

⌨️vim

🔍wireshark

🕷️burp suite

📦git

🐧linux

🌐nmap

🌀curl

🔗requests

📮postman

📊grafana

🔔prometheus

📡dig / nslookup

⚙️httpie

🕵️tcpdump

🗺️gobuster

📄jq

🌐html/css

🔀nginx

🔑ssh

🔥ufw

tmux config — how i live

# ~/.tmux.conf — abridged # remap prefix to ctrl+a like god intended unbind C-b set -g prefix C-a # split panes with sane keys bind | split-window -h -c "#{pane_current_path}" bind - split-window -v -c "#{pane_current_path}" # status bar — minimal but informative set -g status-style "bg=colour234 fg=colour250" set -g status-right "#[fg=colour39]%H:%M #[fg=colour28]%d-%b" # current sessions on this machine: lab 4 windows research 3 windows monitor 2 windows

docker-compose.yml — example stack

version: "3.9" services: proxy: image: nginx:alpine ports: ["80:80", "443:443"] volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro networks: [frontend] app: build: ./app environment: - DB_HOST=db networks: [frontend, backend] db: image: postgres:15 networks: [backend] # not exposed networks: frontend: # internet-facing backend: # isolated

network_tools.sh — toolchain demo

# various network tools in a typical session $ nmap -sV -sC --open 10.10.0.0/24 -oN scan.txt starting nmap 7.94 — scanning 256 hosts discovered: 12 hosts up $ dig @10.10.0.1 internal.lab A ;; answer section: internal.lab. 300 IN A 10.10.0.50 $ curl -s -o /dev/null -w "%{http_code} %{time_total}s" http://internal.lab/health 200 0.023s $ ss -tlnp | grep LISTEN LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1234)) LISTEN 0 128 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=1234))

08 // other stuff

the misc section

other things that are true about me that didn't fit anywhere else.

🏠

homelab obsession

started with one server. now it's a whole network with vlans, multiple services, monitoring, the works. the homelab never stops growing. it never will. this is fine.

🐛

bugs are puzzles

the reason bugcrowd is fun is the same reason escape rooms are fun — except the puzzles are actually interesting and you learn something real from solving them.

📚

constant learning

there's always something new. that's not a complaint, it's the best part. the tech space moves fast enough that staying sharp requires actually caring. i care.

🔬

how does it work

the question that drives most of my rabbit holes. understanding the mechanism behind something is more satisfying than just making it work. probably explains the security interest.

⌨️

terminal > everything

if i can do it in the terminal, i will do it in the terminal. not because it's faster necessarily, but because it's more satisfying and you actually understand what's happening.

🧪

test in the lab first

the homelab exists partly so i have a place to break things without consequences. new tool? spin it up in an isolated container first. that's just discipline.

fun_facts.sh — things that are true

$ cat ./facts.txt 1. i have more tmux sessions open than browser tabs. yes, really. 2. my first instinct when something breaks is to read the logs, not google it. 3. i've rewritten the same bash script "properly" at least 3 times. 4. i know exactly what my homelab's power consumption is. 5. the first thing i do on a new machine is install tmux and set up dotfiles. 6. i've debugged dns issues at unreasonable hours and would do it again. 7. "it works on my machine" is never the end of the sentence for me. 8. i do bugcrowd for fun. the fact that it can pay out is a bonus. 9. if a system has an api, i will find out what it does with unexpected input. 10. duckscript is genuinely underrated and i will die on this hill.

systems engineer who breaks things too

about me

skills & languages

bug hunting

finding what others miss because i actually look

experience & depth

infrastructure & operations

cybersecurity specialization

general it knowledge

tools i actually use

the misc section

finding what others miss
because i actually look