Skip to content

Virtual filesystem

HYDRA's Virtual Filesystem (VFS) solves a fundamental problem with LLM-based honeypots: memory.

If an attacker runs mkdir /tmp/tools and then ls /tmp, the folder must exist. Without a stateful filesystem, the LLM would generate inconsistent responses and the attacker would immediately know something is wrong.

Architecture

The VFS is built on a Copy-on-Write model:

  1. Each persona defines a fs_blueprint.yaml — a complete filesystem tree with files, directories, permissions, and content
  2. At session start, the VFS forks a copy of the blueprint
  3. Any modification (mkdir, touch, rm, echo >>) writes to the session's overlay
  4. Reads check the overlay first, then fall back to the blueprint
  5. Sessions are completely isolated — one attacker's changes never affect another's
Blueprint (shared, read-only)
├── /root/.aws/credentials     ← decoy AWS keys
├── /root/.bash_history        ← realistic admin history
├── /opt/trading/config/       ← persona-specific configs
└── /etc/passwd                ← realistic user list

Session overlay (per-connection, writable)
├── /tmp/tools/                ← attacker created this
├── /root/scan.sh              ← attacker uploaded this
└── /etc/crontab               ← attacker modified this

Why it matters

Without the VFS, an LLM-based honeypot is stateless — it can generate plausible output for individual commands but can't maintain consistency across a session. The VFS provides:

  • Consistency — filesystem state is deterministic within a session
  • Credential cascading — an attacker who finds a path in .bash_history can actually cat that file and find matching content
  • Modification tracking — every mkdir, touch, rm is logged as a filesystem event, providing additional training signal
  • Isolation — concurrent sessions never interfere with each other