Wiki / Crucible / Docs

Crucible Docs

Overview & Benefits New Engagement Wizard Settings Tab Summary Tab Console & Controls Findings Tab Intelligence Tab Action Items & Auto-Queue Reports Import Logs & Errors Auditability Engagement Hours & Scheduling
← Back to Crucible

Console & Controls

Real-time tool output, execution controls, and engagement scheduling.

Tool Sidebar

The left sidebar lists all registered tools with real-time status indicators:

  • ● Running — tool is actively executing
  • ✓ Complete — tool finished successfully
  • ✗ Failed — tool exited with an error
  • ◷ Queued — tool is in the execution queue, waiting for its turn
  • ⏸ Paused — tool was paused and can be resumed
  • ○ Not Started — tool has not been launched yet

Click any tool to view its console output. The sidebar updates in real-time via Socket.IO — no page refresh needed.

For scope-qualified tools (e.g., ss3:external), the sidebar shows the scope label and indicates whether the run is in-scope or OOS (out-of-scope).

Live Console

Real-time stdout/stderr streaming from the selected tool via Socket.IO. Each tool maintains a 5,000-line ring buffer — older lines are discarded as new ones arrive.

Auto-scroll keeps the view pinned to the bottom while output streams. Toggle auto-scroll off to inspect earlier output without losing your place — the view stays where you scrolled. Toggle it back on to jump to the latest output.

For completed or failed tools, the console loads the full scan.log from disk rather than the in-memory buffer, so output is available even after Crucible restarts.

Interactive Prompts

Some tools require user input during execution (e.g., sudo password, confirmation to proceed, target selection). When a tool emits a prompt token (__CRUCIBLE_PROMPT__), a modal dialog appears with the prompt text.

Type your response and click Send — the response is written to the tool's stdin. All connected clients in the same project room see the prompt simultaneously; the first response wins and is sent to the tool.

Prompts are also logged for audit purposes.

Execution Controls

Control tool execution from the console toolbar:

▶ Start Launch
Launch the tool with its current settings. Before starting, Crucible: (1) checks system RAM is below 85%, (2) verifies the tool script exists, (3) checks parallelism rules — if an exclusive tool is already running, the launch is blocked with an explanation. The tool's settings are loaded from disk and scope-backfilled targets are injected.
■ Stop Graceful
Send SIGTERM for graceful shutdown. The tool receives the signal, saves its checkpoint.json (recording completed phases and progress), and exits cleanly. Subprocesses spawned by the tool are terminated first. This is the preferred way to stop a tool.
✗ Kill Force
Force-terminate with SIGKILL after a timeout period. The tool and all its subprocesses are killed immediately without checkpoint. Use only when Stop doesn't work — no checkpoint is saved, and the tool cannot resume from where it left off.
⏸ Pause Checkpoint
Request a graceful pause. The tool writes a checkpoint.json recording its current state and exits. The tool's status changes to 'paused'. Resume later from where it left off. Important: Crucible sends the pause signal but never kills the tool process directly — the tool itself checkpoints and exits.
▶ Resume Continue
Re-launch a paused tool with the --resume flag. The tool reads its checkpoint.json and continues execution from the last saved state — phases already completed are skipped.
⏸ Pause All Batch
Pause all running tools in the project simultaneously. Also pauses the execution queue so no new tools launch. Use when you need to temporarily halt all testing (e.g., production incident, testing window closed).
▶ Resume All Batch
Resume all paused tools and unpause the execution queue. Queued tools begin launching again according to parallelism rules.

Engagement Scheduling

Schedule an engagement to auto-start at a future date and time. At the scheduled time, all enabled tools launch through the queue manager, respecting parallelism rules.

Use this to:

  • Begin testing at a precise time agreed upon with the client
  • Start scans overnight when network load is lower
  • Coordinate start times across multiple engagements

You can view, edit, or cancel scheduled starts from the console. Multiple schedules can be set for different dates (e.g., Phase 1 on Monday, Phase 2 on Wednesday).

Engagement Hours

Set an allowed testing window. Tools automatically pause when the window closes and resume when it reopens. Useful for engagements with restricted testing hours.

FieldRequiredDescription
Enabled No Toggle engagement hours enforcement on/off.
Start Time No Daily testing start time. Default: 08:00. Tools will not launch or resume before this time.
End Time No Daily testing end time. Default: 18:00. Running tools will be paused when this time is reached.
Timezone No Timezone for the hours window. Default: US/Central. Use IANA timezone names (e.g., US/Eastern, Europe/London, Asia/Tokyo).
Days No Weekdays when testing is allowed. Default: Monday–Friday (checkboxes). Uncheck Saturday/Sunday to prevent weekend testing.

Queue Management

View and manage the execution queue from the console:

  • Queue view — Shows all queued tools with their priority, queued timestamp, and scope.
  • Remove from queue — Remove a specific tool from the queue (it won't launch).
  • Clear queue — Remove all queued tools at once.
  • Queue persistence — The queue is saved to disk (execute_queue.json) on every change, so it survives Crucible restarts. On startup, Crucible loads the persisted queue and resumes processing.
  • Retry logic — When queued tools can't launch (RAM pressure, parallelism block), the queue retries every 30 seconds.
← Summary Tab
Findings Tab →