Sandbox Tools

Workflow

1. Confirm scope

   • Identify artifact type (event log, registry hive, binary, PCAP, archive, memory image, timeline source, Office document, PDF, email, disk image, phone extraction, browser data).
   • Confirm where artifacts are expected (Desktop\readonly for input artifacts, Desktop\readwrite for analysis output).
   • Ask the user to clarify if the artifact type is ambiguous.

2. Check for MCP server availability

   • If the task involves registry analysis, check whether the regipy MCP server is enabled.
   • If the task involves reverse engineering, check whether Ghidra or radare2 MCP servers are enabled.
   • MCP servers allow interactive, iterative analysis. Prefer them when enabled and the task benefits from back-and-forth exploration.
   • If an MCP server is not enabled, fall back to command-line tools for the same artifact type.

3. Pick the least-friction toolchain

   • Prefer tools that are already bundled in C:\Tools (native binaries, fastest).
   • If a Python-based tool is needed, use launchers from C:\venv (see references/python-tools.md).
   • If source-based helper scripts are needed, check C:\git.
   • If enrichment data is needed (YARA rules, GeoIP, Sigma rules), check C:\enrichment (see references/enrichment-data.md).
   • When multiple tools can do the job, prefer the one with structured output (JSON/CSV) over plain text, as it enables further processing.

4. Run a quick triage pass before deep analysis

   • Hash and identify file type.
   • Extract high-signal metadata (timestamps, signer/imports for binaries, key fields for logs).
   • Save outputs into a case subfolder under Desktop\readwrite.

5. Escalate only when needed

   • Start with broad, low-cost checks.
   • Move to heavier tooling (decompilers, disassemblers, yara-at-scale, timeline fusion, memory forensics) only after triage identifies leads.

6. Cross-reference with enrichment data when appropriate

   • Match hashes or IOCs against available threat intel.
   • Run YARA rules against suspicious files.
   • Enrich IP addresses with GeoIP data.

7. Return reproducible output

   • Provide exact commands with full paths.
   • Explain why each tool was chosen.
   • Include assumptions and next-step branches.

Output template

Use this structure in responses:

• Objective: What question the analysis answers.
• Tool choices: Why these tools were selected (with full paths).
• Commands: Copy/paste-ready commands with absolute paths.
• Findings: Concise, evidence-first observations.
• Next checks: 2-4 concrete follow-ups.

Guardrails

• Prefer offline-capable workflows; do not assume internet access in the final analysis sandbox.
• Never invent tool output; clearly mark estimated or pending results.
• Keep pathing Windows-native unless the user explicitly asks for PowerShell-to-Bash translation.
• Always use absolute paths in commands (e.g., C:\Tools\hayabusa\hayabusa.exe, not just hayabusa).
• Treat Desktop\readonly as evidence input and keep all derived files in Desktop\readwrite.
• If a command may alter evidence, provide a read-only alternative first.
• If a tool is missing or a command fails, suggest an alternative tool that provides similar functionality rather than stopping. Multiple tools exist for most artifact types.
• When writing output files, use descriptive names that include the artifact name and analysis type (e.g., evtx_security_hayabusa_results.csv).
• Prefer structured output formats (JSON, CSV) when the tool supports them, to enable downstream processing.