Skip to content

Personas

Instead of a generic Ubuntu server, each HYDRA session randomly selects one of three personas — complete simulated environments designed to attract specific attacker profiles.

Why personas matter

A blank server gives attackers nothing to explore. A server with realistic credentials, services, and history gives them a reason to stay — and every minute they stay produces training data.

The insight: financially valuable environments attract deeper engagement. Our data confirms this: fintech_trading generates 2.4× more commands than corp_ad.

The three personas

fintech_trading

A trading API server belonging to a small fintech company.

Element Content
Hostname srv-prod-01
Services PostgreSQL, Redis, Node.js trading API
Decoy credentials AWS keys in /root/.aws/credentials, .env.prod with DB passwords
bash_history pg_dump trading_prod -t wallets, vim /opt/trading/config/.env.prod
MOTD Production server warning banner

Performance: 34 signal sessions, 1,349 avg commands, 94s avg duration.

crypto_validator

A Solana blockchain validator node.

Element Content
Hostname solana-val-01
Services Solana validator, monitoring stack
Decoy credentials Keypairs in /root/.config/solana/, ~4,847 SOL simulated balance
bash_history solana balance, solana-keygen, validator management commands

Performance: 17 signal sessions, 643 avg commands, 148s avg duration. Notably, 303 login attempts used usernames sol and solana — scanners specifically target Solana nodes.

corp_ad

An Active Directory member server in a corporate environment.

Element Content
Hostname dc-backup-03
Services Samba, SSSD, Kerberos, LDAP
Decoy credentials Kerberos keytabs, LDAP exports, service accounts
bash_history smbclient, ldapsearch, kinit admin@CORP.LOCAL

Performance: 15 signal sessions, 555 avg commands, 86s avg duration. Fewer commands but more varied TTPs — LDAP, Kerberos, and SMB enumeration.

How personas work technically

The PersonaEngine manages persona selection and injection:

  1. Selection — Random choice at session_start, weighted by configuration
  2. VFS overlay — Each persona has a fs_blueprint.yaml defining its filesystem tree. The VFS starts with this blueprint and forks a CoW copy for the session.
  3. LLM context — The persona's description is injected into the LLM system prompt, so responses match the environment (e.g., listing Solana-related processes on the crypto persona)
  4. Identity overrides — Hostname, MOTD, environment variables, running services
  5. Live events — Periodic asynchronous output (cron job logs, monitoring alerts) to make the environment feel alive
  6. Filler files — Universal dotfiles (.Xauthority, .lesshst, .rnd) added to every persona so ls -la /root doesn't look suspiciously clean