Security

I’m a Full Stack Engineer moving into red teaming. This page separates what I’ve shipped, what I practice in labs, and what I’m still learning.

Direction

I’ve built authentication flows, APIs, device networks, and deploys that real people use. That tells me where systems get misconfigured: default credentials, shared keys, unchecked callbacks, ports nobody meant to open.

The goal is red teaming, which means thinking like an adversary against whole systems. The path there runs through web and API exploitation, Linux and network attacks, and lab work I can show.

Full Stack Engineering → Secure Engineering → Offensive Security → Red Teaming

Offensive track Learning

  • Networking fundamentals: how traffic moves, and where it can be intercepted or redirected.
  • Linux security and privilege escalation.
  • Web and API security: authentication, authorization, injection, and misconfiguration.
  • Vulnerability assessment and ethical-hacking methodology.
  • Hands-on practice on TryHackMe and Hack The Box.

I’ll link profiles, completed paths, and certifications here once they can be verified. Until then, all of this is labelled as learning.

Lab writeups Lab

My first writeups are in progress. They cover retired machines and my own systems only, and they focus on methodology, not just flags.

The first one planned is a self-assessment: attacking my own Simple Form deploy the way the ransomware bot did, then going further.

Seen from the builder’s side Shipped

These are controls I’ve implemented in real systems, each paired with what an attacker would try against it.

Station tokens and plant isolation

Each factory device has its own token, and the server maps it to a single plant.

An attacker would try cloning a device image, stealing a token, or replaying offline events.

Webhook-secret validation and tenant routing

Callbacks are checked for the sender’s secret before any parsing or routing.

An attacker would try forged POSTs to the callback URL, or pushing one tenant’s events into another’s.

OAuth 2.0, OIDC, JWT, and API keys

Used across integrations and apps, and built from scratch in an experimental OIDC provider.

An attacker would try redirect URI manipulation, token leakage, or a missing state or nonce check.

RBAC, rate limiting, and honeypots

Role-based access in operational systems. Rate limits and a honeypot field on public form submissions.

An attacker would try horizontal privilege escalation, credential stuffing, or automated spam.

Loopback-only databases and real secrets

The database is reachable only from the app on the same machine, and credentials are real secrets.

This is the exact door that was open before the incident below.

The incident

Simple Form’s PostgreSQL instance was reachable from the internet with default-style credentials. A ransomware bot scanned for the port, logged in, and held the data as leverage. It didn’t need an exploit.

From the attacker’s side it was cheap: mass scanning, a short credential list, automated ransom. That’s what made it land for me. Most real compromises go through the boring door.

Read the full write-up

Boundaries

  • No professional red-team or penetration-testing engagements yet.
  • No CVEs, bug bounties, or certifications to claim yet.
  • All offensive work stays on my own systems, retired lab machines, or permitted CTFs.