Home / Origin Story

The Origin of Shadow Protocol

A late-night conversation that became a comprehensive security education resource.

How This Started

January 5, 2026 — 9:31 PM

It began with a simple question that anyone learning security eventually asks:

"I'm learning how hacking works to better defend. I've always known THAT a hacker attacks port 22 but I never understood it. I'm now learning how the workflow actually works and what tools are used step by step. Sure I used SSH every day but never knew how they used Hydra etc.

Now I'm studying payloads. Get them to run some code... many different ways. Assume it gets run. The hacker needs to reverse shell back to himself but if he gives up his IP address then he's potentially caught. How do they hide their own IP when trying to create a reverse SSH back to themselves or do they do something different?"

This is the question that separates surface-level security knowledge from real understanding. Anyone can Google "what is a reverse shell." But understanding why a raw reverse shell to your home IP is "amateur hour" requires knowing how the entire attack chain actually works.

The Conversation Evolved

What followed was a Socratic dialogue that kept going deeper:

Phase 1: The IP Problem (9:31 PM)

The answer started simple: proxy chains and tunneling. The shell bounces through multiple nodes. Each hop only knows its neighbors. Your real IP never touches the victim.

But that raised more questions:

  • Where do these proxies come from?
  • How do you get reliable ones that aren't honeypots?
  • What about cloud infrastructure?

Phase 2: The Coffee Shop Problem (9:39 PM)

The student proposed a mental model:

"If I were them I would VPN from a coffee shop or library's computer or VPN from my machine to a Linode Linux purchased with a stolen credit card and then proxy 3x from there to a 'stolen' Linux box somewhere and then proxy 3x to the target. What am I missing?"

This led to discussing physical OPSEC—the part most people forget:

  • Cameras everywhere
  • MAC address logging
  • Phone pinging cell towers
  • License plate readers
  • Payment trails

"Most get caught through meatspace mistakes, not network forensics."

Phase 3: Going Deep Technical (9:50 PM)

The request became explicit:

"Tell me a technical walkthrough of how someone would do it answering my questions and MORE that I didn't answer. I don't need the story as much as a daring adventure... I want context of why he would do it and what his goal would be... no creative story just context and then go super deep technical with command options level technical explanations. Add a cool thing at the end. 'One more thing...' $SomeMicDropSomething."

This produced:

  • A complete 8-phase attack walkthrough
  • Actual command examples with flags explained
  • The rationale behind every decision
  • Detection strategies for each technique

And the "One More Thing" that should keep defenders up at night: Golden SAML.

Phase 4: Even Deeper (10:29 PM)

More questions emerged:

"How do they disassociate themselves from the Hyperscalers ownership of the account it is running?"

"Is this leaving files or opening connections?"

"Do they do nmap one day and then try an attack... when do they connect and control the hacked server or is it all trial and error advanced scripting?"

"How do they keep a process running for days or even weeks... If I opened Brave for a week it would crash."

"How do people figure this out without getting arrested?"

Each question demanded deeper explanation. The conversation covered:

  • Stolen cloud credentials and crypto-purchased accounts
  • Beacon vs. interactive shell models
  • Jitter and sleep intervals
  • WMI event subscriptions
  • Memory-only operation
  • Legal learning paths (CTFs, bug bounties, certifications)

Phase 5: The Sleeper Problem (Final "One More Thing")

The conversation ended with the terrifying reality of sleeper implants:

"Your network might be compromised right now by something that hasn't started operating yet. And you'd have no way to know.

That's not theoretical. That's the actual state of cybersecurity for high-value targets.

Welcome to the paranoia."

Why This Became a Website

11:09 PM

"Make a full length HTML page that covers every single detail we have discussed. Make it long verbose and follow an arc. Before you make it ask me questions about the format of the webpage HTML and do not summarize topics."

The design discussion that followed covered:

  • Dark terminal aesthetic (yes)
  • ASCII art + CSS flowcharts (yes)
  • Both chronological AND conceptual navigation (yes)
  • Danger heat maps for risk levels (yes)
  • Progress tracking (yes)
  • Detection strategies interspersed throughout (yes)
  • Legal learning section with lab setup guides (yes)
  • Glossary with hover tooltips (yes)

The Handoff to Claude Code

11:19 PM

Rather than trying to export the conversation through some interface, the human simply copied the entire conversation into a new Claude Code session with the instruction:

"I want to make a complex website. Not one HTML... layer deep. Set up so that we can add many HTML pages."

Claude Code received the full context—every question, every answer, every design decision—and built the site you're now reading.

Key Themes That Emerged

1. Understanding the "Why"

Every technique explanation includes the rationale:

  • Why proxy chains instead of direct connections
  • Why beaconing instead of persistent shells
  • Why LOLBins instead of custom malware
  • Why multiple persistence mechanisms

2. The Attacker's Perspective

To defend effectively, you need to think like an attacker:

  • What are they trying to achieve?
  • What are their constraints?
  • Where are their risks?
  • What makes them fail?

3. Defense is Harder

The asymmetry is brutal:

  • Attackers need to find ONE path in
  • Defenders must cover EVERY path
  • Attackers can wait years
  • Defenders must detect in time to matter
  • Some attacks (Golden SAML, sleepers) are nearly undetectable

4. Legal Learning Paths Exist

The final section emphasizes that all of this can be learned legally:

  • Home labs with your own VMs
  • CTF competitions
  • Bug bounty programs
  • Certifications with hands-on labs
  • Professional red team work

What This Project Represents

This isn't a hacking tutorial. It's not a script kiddie manual.

It's an attempt to bridge the gap between:

  • "Enable MFA and you're secure" (checkbox compliance)
  • "Here's a Mimikatz command" (context-free syntax)

Real security understanding requires knowing:

  1. What attackers are trying to do
  2. Why they make specific choices
  3. How each technique actually works
  4. What artifacts they leave behind
  5. How defenders can detect them

That's what this project aims to provide.

The Conversation Continues

This is a living document. The original conversation raised questions that still need pages:

  • Initial access techniques ✓
  • Reconnaissance methodology ✓
  • Credential access in depth ✓
  • Lateral movement options ✓
  • Exfiltration channels ✓
  • C2 framework configuration ✓

The structure was built. The content grew.

The Evolution (January 2026)

What started as a single-page concept exploded into something much larger.

From 14 to 37 Chapters

The original build created 14 core chapters. Within days, the project grew to include:

Reconnaissance & Infrastructure

OSINT & Recon, Social Engineering, Attack Infrastructure, C2 Setup

Initial Access & Post-Exploitation

Initial Access, Payloads, Web Apps, Wireless, Physical, BadUSB, Execution, Persistence, Beaconing, Discovery, PrivEsc, Credentials, Lateral Movement, Anti-Forensics

Objectives & Specialized Environments

Exfiltration, Ransomware Ops, Supply Chain, Active Directory, Cloud, Containers & K8s, Mobile, IoT, Advanced Techniques

Defense & Reference

Detection Strategies, Purple Team, Forensics & IR, Attribution, Legal & Learning, The Long Con, Mr. Robot Decoded, Glossary, Disclaimer

The Mr. Robot Voice

A key insight emerged: dry technical documentation doesn't engage. The site adopted an "Elliot Alderson" voice—part internal monologue, part hacker philosophy, part genuine paranoia. The goal: trick people into learning by making them feel like hackers.

"A femtocell. Looks like a router. Sits on a desk like it belongs there. But every phone in range? They connect to it automatically. The closest tower wins. And now you ARE the tower. Every call, every text, routed through hardware you control."

Technical accuracy first. Engaging voice second. Never sacrifice one for the other.

The Great Expansion

Initial chapters were stubs—headers with "coming soon" placeholders. This violated the core mission. A systematic expansion added thousands of lines of real content:

Chapter Before After Content Added
C2 Setup 174 438 Framework comparison, redirectors, domain fronting, malleable profiles
Supply Chain 169 351 SolarWinds case study, dependency confusion, typosquatting
Payloads 169 358 Staged vs stageless, obfuscation, msfvenom examples
Physical Red Team 177 625 Badge cloning, lock picking, Proxmark3, social engineering
Credentials 179 686 Mimikatz, LSASS dumps, Kerberoasting, AS-REP roasting, cracking
Beaconing 181 683 Jitter math, DNS tunneling, domain fronting, malleable C2
Social Engineering 219 495 Evilginx2 MFA bypass, vishing, smishing, caller ID spoofing
Exfiltration 276 576 DNS exfil, cloud channels, steganography, Discord webhooks

Total expansion: ~3,000+ lines of substantive content.

The Laws

To maintain quality as the project grew, two immutable laws were established and codified in the project's CLAUDE.md:

LAW: Content Quality Standard

No placeholder content. No "coming soon" stubs. If a section header exists, it must have complete content. Every page must include: introduction, technical content, code examples, detection/defense, MITRE ATT&CK mapping, and tool references.

LAW: Version Numbering

Every commit must include a version bump. Semantic versioning (vMAJOR.MINOR.PATCH). Version displays in the top bar. History tracked in CLAUDE.md.

Technical Improvements

  • SPA Navigation: Sidebar never reloads. Pages fetch dynamically. Scroll position preserved.
  • Scroll Isolation: Sidebar and main content scroll independently. No bleed-through.
  • Chapter Navigation: Every page has prev/next buttons following sidebar order.
  • SEO: Meta descriptions, Open Graph tags, robots.txt, sitemap.xml.
  • Mobile: Responsive sidebar with hamburger toggle.
  • Copy Buttons: One-click code copying on all terminal blocks.

Current State: v3.8.0

SHADOW PROTOCOL v3.8.0
├── 37 chapters
├── ~25,000+ lines of HTML content
├── Comprehensive attack lifecycle coverage
├── Defensive detection for every offensive technique
├── MITRE ATT&CK mappings throughout
├── 200+ tool references with links
├── Legal disclaimer and acceptable use policy
└── Two immutable laws governing content quality

What's Next

The foundation is solid. Future work includes:

  • Citation System: Inline references to MITRE, CVEs, research papers
  • Lab Exercises: Hands-on practice scenarios for each chapter
  • Episode Breakdowns: Mr. Robot technique analysis by episode
  • Interactive Diagrams: Mermaid flowcharts for complex attack paths
  • Detection Playbooks: SIEM queries and response procedures

The conversation that started at 9:31 PM on January 5th never really ended.

"You're asking the right questions. Understanding the offensive workflow is exactly how you build real defense instead of checkbox compliance."

— From the original conversation, 9:31 PM

"Every page a reader lands on should provide real value. No page should ever feel incomplete or abandoned."

— The Content Quality Law, January 7th, 2026