DetCordon

The Problem

Web malware changes faster than signatures can ship. PHP webshells, scanner-driven RCE payloads, and zero-day exploit kits all have one thing in common: by the time you have a detection rule, the sample set has already moved.According to the 2025 Verizon DBIR, web application exploits remain the #1 vector for breaches, with 75% of attackers using commodity tools that mutate daily.

Today's options are either inline blocking (WAFs that must be right every time) or static analysis (sandboxes designed for PE files, not HTTP). Neither works well for server-side web malware that only activates in the context of a specific application stack.

DetCordon takes a third approach: containment-first observation. Let the malware execute in a purpose-built, disposable environment where every syscall, file write, and network connection is recorded. Preserve the samples. Ship them to a separate, hardened sink. Then decide what to block.

The Architecture

Two hosts. One direction of travel. Zero bytes flowing back.

Ten Containment Rules

These are non-negotiable. Every deployment, every backend (Docker or Firecracker), every mode (analysis or honeypot) enforces all ten:

• 01 No host bind-mounts — Victim writes to tmpfs only. Reset means destroy and recreate, not rm -rf.  This prevents sample bytes from ever touching the sandbox host's real filesystem. If the attacker compromises the victim, they still can't pivot to the host.
• 02 Internal + default-drop egress — Victim has no outbound access except to the sink's two ports. No DNS, no package repos, no exfiltration.  The default-drop egress rule is generated as an nftables set in the deployment artifacts, not left to operator judgment.
• 03 WAF in DetectionOnly — Malware must succeed to be observed. The ModSecurity tap never blocks, never rate-limits, never modifies the request.  DetectionOnly means we capture what the attacker intended, not what survived a block rule. This is critical for zero-day observation.
• 04 Write-only samples, UDP events — The sandbox VM has no inbound channel. No reverse shell can establish C2 because nothing listens.  Samples go out over TCP (reliable). Events go out over UDP (lossy but fast). Nothing comes in. Ever.
• 05 sha256-path, mode 0400, no extension — Stored as samples/<sha256> with no file extension and read-only for owner. Nothing to double-click.  The absence of a file extension means even a misconfigured browser or file manager won't accidentally execute the sample.
• 06 Sink-guard always-on — Every close-write on the sink is fanotify-monitored and hashed against an allowlist. Unknown write = incident alert.  The guard runs as a separate process with its own systemd unit. It cannot be stopped without alerting.
• 07 eBPF host-pid is opt-in — Default cgroup-scoped bounds the eBPF sidecar's blast radius. Host-level pid visibility requires explicit operator override.  A misconfigured eBPF program with host-pid scope can observe all host processes. Cgroup-scoping prevents this by default.
• 08 Time-boxed (30 min default) — Hard kill after 30 minutes. Configurable per deployment, but never disabled.  If something goes wrong — a fork bomb, a slow exploit, an operator who forgot to tear down — the system self-destructs within the time limit.
• 09 No sample bytes over UDP — Sample bodies are never sent over the loss-tolerant channel. UDP is for metadata only.  Sample integrity is critical for forensic admissibility. TCP with sha256 verification on the sink side guarantees we have what the attacker dropped.
• 10 Sink host ≠ sandbox host — Different physical or virtual machine. Kernel isolation between what's being attacked and what stores the evidence.  If the attacker compromises the sandbox VM (which is the expected outcome), the sink host — with its evidence and decryption key — must remain unreachable from that VMs network position.

Target Market

DetCordon addresses three distinct buyer personas with overlapping needs:

The addressable market is the intersection of web security and malware analysis — a niche that today's PE-file-focused sandboxes and signature-based WAFs both underserve.

Business Model

Competitive Position

DetCordon's differentiation is narrow and deep: it is the only open-architecture malware observation platform purpose-built for web-server-side payloads rather than user-downloaded PE files.

While Cuckoo/CAPE has a larger malware-analysis community, neither supports server-side web payloads natively. A PHP webshell in Cuckoo runs under Windows detonation — the wrong environment entirely.

DetCordon's moat is not in detection logic (ModSecurity + OWASP CRS are standard) but in the containment topology: two-host, one-way, age-encrypted, fanotify-guarded. No other open product combines all five properties.

Backends

Two sandbox backends, one operator workflow:

The Firecracker backend supports three boot modes: cold-boot (fresh kernel + rootfs each time), rootfs-reset (recreate writable layer from a clean snapshot), and native-snapshot (restore memory + disk from a known state for sub-second boot). Boot policy is configurable through the TUI or CLI.

Roadmap

Build & Deploy

# Build all crates
cargo build --release --workspace

# Run tests
cargo test --workspace

# Generate deployment artifacts (TUI)
cargo run -p waf-deploy

# Headless generation (Firecracker, dry-run)
cargo run -p waf-deploy -- \
  --backend firecracker \
  --mode analysis \
  --dry-run

# Run the sink with age encryption
cargo run -p waf-sink -- \
  --udp 0.0.0.0:5514 \
  --tcp 0.0.0.0:5515 \
  --out /var/lib/waf-sink \
  --recipient age1...

Prerequisites: Rust edition 2021, libmodsecurity3, pkg-config.

Why Not a Kernel Module?

Every capability the sandbox needs is already in-kernel behind safer interfaces. An out-of-tree kernel module would add ring-0 attack surface — the opposite of what a containment project should do.

Further Reading

• Architecture doc — products/detcordon/doc/architecture.md (mermaid topology + dataflow + sequence diagrams)
• AGENTS.md — full developer documentation, environment variables, wire formats, coordination protocol
• Firecracker plan — doc/firecracker-plan.md: VM lifecycle, snapshot/reset, boot policy
• Slide deck — doc/presentation.html: impress.js narrated walkthrough (12 slides)
• RAGBAZ Atlas — doc.ragbaz.cc/docs/products/detcordon