Dosu Logo
Home
Documents
ShadowHunt Concept
ShadowHunt Concept
Type
External
Status
Published
Created
Mar 8, 2026
Updated
Apr 3, 2026
Updated by
Dosu Bot

We watch from the shadows --- our eyes never close.
AI summary
DaemonEye is a silent observability and hunt layer for sensitive,
restricted, and air-gapped environments. It transforms endpoints into
stealth honeypots, offering passive observation by default, surgically
traceable on-demand capabilities, and cryptographically auditable
forensics. Telemetry remains under customer control, with a proxy tree
architecture ensuring scalability and reliability. The system focuses on
silently tracing process lineages and network interactions when a
heuristic triggers, allowing analysts to reconstruct attack paths
without alerting adversaries. Key principles include customer
sovereignty over data, silent observation, auditable forensics, air-gap
friendliness, privacy defaults, and extensible integration. The workflow
involves passive baseline collection, heuristic triggers, silent trace
commands, focused capture of events, cross-host stitching, analyst
review, and manual action.

1. Overview / Elevator Pitch#

DaemonEye is a silent observability and hunt layer for sensitive,
restricted, and air-gapped environments. It turns endpoints into stealth
honeypots: passive by default, surgically traceable on demand, and
cryptographically auditable. Telemetry never leaves customer control
unless explicitly exported by an operator. Proxy tree architecture
(Fanout-style) provides scale and store-and-forward reliability without
exposing data outwards.
One-line: DaemonEye silently observes endpoints and, when a
heuristic triggers, places a focused, tamper-evident trace on that
process lineage and its network interactions so analysts can reconstruct
the attacker's path without tipping them off.

2. Core Principles & Telemetry Commitment#

  • Customer sovereignty: All telemetry is owned and controlled by the
    customer. DaemonEye provides software, not custody. Agents and proxies
    use mTLS to the customer Security Center; no automatic egress to
    external cloud services.
  • Silent observation: Default mode is passive. Rules and traces are
    operator-visible only; they generate no host-visible artifacts that
    could alert an adversary.
  • Auditable forensics: All trace start/stop and trace events are
    cryptographically signed (Ed25519) and recorded in a write-only audit
    ledger to preserve chain of custody.
  • Air-gap friendly: Fully functional offline; rule packs and updates
    can be delivered via signed bundles and sneaker-net updates.
  • Privacy & safety defaults: Mask command args by default, RBAC for
    who can start traces, rate limits and resource caps to avoid host
    disruption.
  • Extensible integration: Security Center can export (explicitly
    configured) one-way sinks (Splunk, Elastic, Kafka) ---
    operator-initiated only and explicitly permissioned.

3. Core Concept & Workflow (Analyst POV)#

  1. Passive baseline: procmond collects lightweight process
    metadata, parent/child relationships, and connection tuples into the
    local store (redb).
  2. Heuristic trigger: A rule (e.g., Apache -> bash spawn) fires in
    Security Center or agent evaluator.
  3. Silent trace command: SC issues a TraceCommand to the agent via
    the proxy tree; the agent starts focused tracing of the root PID and
    descendants.
  4. Focused capture: procmond captures fork/exec, cmdline snapshots,
    file-open metadata, socket opens/closes, and small memory artifacts
    as configured. All events are signed and stored locally.
  5. Cross-host stitching: If a traced process connects to remote
    host running DaemonEye, SC can fan-out a trace to the remote host,
    linking events via a shared trace_id.
  6. Analyst review: UI presents lineage graphs, replayable timeline,
    filtered SQL queries, and exportable signed forensic packages.
  7. Action (manual): Analysts decide containment or continued
    surveillance --- DaemonEye avoids automated enforcement by default.

4. Proxy Tree Architecture (Fanout-style)#

Topology: One Security Center (SC) per logical enclave and a tree
of Proxies (PX) for scale. Agents (AG) connect up to a PX; PXs forward
to upstream PX or SC. No cycles.
Roles:

  • Agent (AG): procmond + daemoneye-agent. Collects events, obeys
    trace commands, connects only to assigned PX list.
  • Proxy (PX): store-and-forward node. WAL (redb), batching,
    compression, flow control, QoS, command routing.
  • Security Center (SC): fleet registry, rule execution, correlation,
    UI, audit ledger, export configuration (none by default).
    Data plane & Control plane: Events flow up (AG->PX->...->SC). Control
    messages (TraceCommand) flow down (SC->PX->...->AG). All mTLS
    authenticated.
    PX features: WAL, ingress/egress queues, compression (zstd),
    priority lanes (trace, alert, bulk), disk watermarks, failover &
    fallback lists for agents, per-link flow control, health metrics visible
    inside the enclave only.

5. Message & Trace Model (Example shapes)#

TraceCommand (ControlMsg payload)

message TraceCommand {
  string trace_id = 1;
  string target_agent = 2; // agent_id or tag
  uint32 target_pid = 3;
  uint32 depth = 4; // max child depth
  bool collect_cmdlines = 5;
  bool collect_network = 6;
  bool collect_file_meta = 7;
  uint32 max_duration_secs = 8;
  string initiated_by = 9; // operator id
  int64 timestamp = 10;
  bytes signature = 11; // operator signature
}

EventBatch (Agent->Proxy)

message EventBatch {
  string agent_id = 1;
  uint64 seq = 2; // per-agent monotonic
  int64 ts_start = 3;
  int64 ts_end = 4;
  repeated Event events = 5;
  bytes batch_sig = 6;
}

TraceChunk (trace events stored with signature)

{
  "trace_id": "T-20251013-001",
  "seq": 42,
  "type": "execve",
  "ts": 1697212345000,
  "payload": {
    "pid": 1234,
    "ppid": 1220,
    "name": "bash",
    "cmdline": ["/bin/bash", "-c", "rm -rf /tmp/*"],
    "exe_hash": "blake3:..."
  },
  "sig": "ed25519:..."
}

6. What gets captured (Focused trace)#

  • Process events: fork/clone, execve, exit, uid/gid, ppid, tty,
    start_time
  • Command lines & env snapshots (privacy masked by default)
  • File activity: open/create/rename/unlink (metadata + optional
    small artifact hashes)
  • Network events: socket create, connect, accept, local/remote
    ip, associated pid
  • Binary hashes: blake3/sha256 of executed binaries
  • Optional memory snippets: small header regions for quick artifact
    triage (policy controlled)
  • Timestamps & sequence numbers: for robust timeline stitching
  • All events cryptographically signed and stored to the audit ledger

7. OS Implementation Guidance (stealth vs coverage)#

Linux: prefer eBPF (aya / bpftrace / ebpf) for stealthy exec/connect
tracing; fallback to /proc polling if needed.
Windows: ETW for process/network events; avoid noisy hooks. Signed
installers and SLSA provenance for enterprise.
macOS: EndpointSecurity framework for process events; proc info
fallback.
Legacy / constrained devices: tiny procmond polling with minimal
footprint and configurable sampling.

8. UI & Hunt Workflows (key features)#

  • Timeline player: step through events; search & filter; jump to
    specific event types
  • Lineage graph: interactive root->children->network hops with
    click-to-snapshot
  • Mark & Watch: flag process/command to start an extended trace or
    build a watch rule
  • Hypothesis sandbox: run ad-hoc SQL queries against stored trace
    data (read-only)
  • Replay & export: produce signed forensic packages (trace +
    artifacts + audit chain)
  • RBAC & approvals: trace start requires role/approval depending on
    policy; all actions logged and signed

9. Telemetry & Privacy Controls#

  • Default mask: commandline args masked; explicit operator action to
    reveal (with justification)
  • Retention controls: operator sets per-site retention window; SC
    enforces purge policies
  • Rate & resource limits: max events/sec per agent, max trace
    duration, max total bytes per trace
  • Operator consent & audit: who started trace, why, and when ---
    immutably recorded
  • Export gates: explicit export sinks must be configured and
    approved (signed export packages)

10. MVP Backlog (priority)#

Goal: demonstrate Apache->bash->ssh scenario with cross-host trace and
signed forensic export

  1. Passive collector PoC (Linux): lightweight exec/connect events ->
    redb store
  2. SC rule evaluator (SQL) + minimal UI to view rule hits
  3. TraceCommand implementation (agent side) + focused trace capture &
    signing
  4. Proxy (PX) MVP: agent->px WAL, px->sc batching, acks & replay
  5. Cross-host link event & manual follow feature in SC
  6. Forensic export: signed trace package (trace_events + metadata)
  7. Tests: performance (10k processes simulated), stealth verification,
    resource caps

11. Risks & Mitigations#

  • Legal/privacy exposure: require operator policy, mask PII by
    default, RBAC for tracing.
  • Host impact / availability: resource caps, sampling fallbacks,
    graceful degrade on memory pressure.
  • Attacker detection of tracing: no host-visible artifacts; use
    kernel-level stealth sources where possible; avoid creating new files
    or processes.
  • Data growth: retention policies, compression, PX buffering, tiered
    storage.
  • False positives / analyst fatigue: tuned rule packs,
    analyst-friendly UI, dedupe & contextual enrichment.

12. Operational & Security Notes#

  • Customer-owned PKI: customer generates root CA; node certs
    short-lived; SC distributes CRLs via PX.
  • No cloud keys by default: SLSA provenance and cosign signatures
    provided for releases; verification possible offline.
  • Signed rule packs: packs signed by EvilBit Labs (or customer) then
    verified by SC before activation.
  • Airgap update kit: signed tarball or container images, verifiable
    with local tools.

13. Example configs (snippets)#

Agent (minimal):

agent:
  proxy_hint: px-us-east-1a.local:7443
  site_tag: us-east-1a
  tls:
    cert: /etc/daemoneye/agent.crt
    key: /etc/daemoneye/agent.key
    ca: /etc/daemoneye/ca.pem
  stream:
    batch_max_events: 2000
    batch_max_ms: 250
  trace:
    default_depth: 6
    privacy_mask_args: true

Proxy (minimal):

proxy:
  listen: 0.0.0.0:7443
  upstream: px-region-1.local:7443
  wal_path: /var/lib/daemoneye/proxy/wal
  fsync_interval_ms: 100
  flow:
    priorities: [trace, alert, bulk]
    compression: zstd

14. Taglines & Messaging (workshopping)#

  • "We watch from the shadows --- and our eyes never close." *(your
    seed)*
  • "Silent eyes. Relentless recall."
  • "Observe. Correlate. Reveal --- without warning the adversary."
  • "Every endpoint is a honeypot. Every action is preserved."

15. Next steps (concrete)#

  1. Accept this canvas and convert to one-page PRD and sprint
    backlog.
  2. Skirmish: Implement Agent PoC (Linux eBPF or /proc fallback) and PX
    MVP (WAL + batching).
  3. Run 2-week red team exercise (apache->bash->ssh) to validate stealth,
    latency, and cross-proxy tracing.
  4. Draft legal & privacy policies and RBAC approval flows for
    enterprise buyers.
  5. Build UI mockups for timeline & lineage and iterate with target
    users (SOC analysts).
    Prepared for: Ken / EvilBit Labs --- DaemonEye Shadow-Hunt design