Crucible — Action Items & Auto-Queue

Overview

Action items are the cross-tool intelligence pipeline that chains tool outputs into follow-up actions. When one tool discovers something that another tool should investigate, it generates an action item. For example:

SS3 discovers a web server on 10.0.0.5:443 → generates a Fracture action item to test that web application
SS3 discovers an open database port on 10.0.0.10:3306 → generates an Auger action item to audit the database
OSift discovers API endpoints in DNS/certificate data → generates a Siphon action item to test those APIs
OSift discovers subdomains resolving to IPs → generates an SS3 action item to scan those hosts

This pipeline eliminates manual target hand-off between tools. Without Crucible, you'd copy targets from SS3 output into Fracture's config by hand — action items automate that.

Generator Map

Which tools generate action items for which other tools:

Target Tool	Generated By	Trigger
Fracture	OSift, SS3	Web server discovered (HTTP/HTTPS on any port)
Siphon	OSift, SS3	API endpoint or service discovered
Auger	SS3	Database port discovered (MySQL, PostgreSQL, MSSQL, Oracle, MongoDB, Redis)
SS3	OSift	New IP addresses or CIDR ranges discovered via DNS resolution
Isotope	Fracture, SS3	Downloadable file discovered during web spidering or service enumeration
AuthProbe	SS3	Web server discovered — fingerprint its authentication before Fracture tests it

Action Item Statuses

Each action item progresses through these states:

Pending New

Action item generated but not yet acted on. Awaiting manual approval or auto-queue processing.

Approved Ready

Approved for execution. Will be picked up by auto-queue (if enabled) or can be launched manually.

Queued Queued

In the execution queue, waiting for parallelism and RAM constraints to clear.

Running Active

The recommended tool is currently executing against this action item's target.

Complete Done

Tool completed execution. Findings (if any) are in the Findings tab.

Dismissed Skip

Manually dismissed — the action item will not be executed. Use for targets that are out of scope or already tested.

Approval Tiers

Action items have two approval modes that control how they enter the execution pipeline:

AUTO Automatic

The action item is automatically approved and queued for execution when generated. No human review required. Use for in-scope targets where the scope definition is well-defined — the tool's targets are already constrained by the engagement scope.

CONFIRM Manual

The action item requires manual approval before execution. It stays in 'pending' status until a user clicks Approve. Use for targets that need human judgment — OOS (out-of-scope) items, ambiguous targets, or when you want explicit control over what gets tested.

Auto-Queue System

When auto-queue is enabled for a project, Crucible automatically processes action items as tools complete:

Tool completes — SS3 finishes scanning the external scope
Action items generated — SS3 produced 12 Fracture items, 3 Auger items, 2 AuthProbe items
Grouping — Items are grouped by recommended tool. All 12 Fracture targets become a single Fracture launch with multiple target URLs
Target injection — Targets are written into the tool's settings file (e.g., Fracture's scan.target_url and scan.target_urls)
Parallelism check — Queue manager checks if launching this tool would violate parallelism rules or exceed 85% RAM
Launch — Tool is launched through the queue. If blocked by parallelism, it waits and retries every 30 seconds

Auto-queue does NOT:

Override scope boundaries — only in-scope targets are processed
Launch tools that aren't enabled for the project
Process items with CONFIRM approval tier without manual approval
Run multiple exclusive-group tools simultaneously

Auto-Queue Scope Warning

⚠️ Scope Boundary Awareness — Read Before Enabling Auto-Queue

Auto-queue processes action items based on scope definitions configured in the engagement wizard. If your scope definition is incomplete or overly broad, auto-queue may launch tools against targets you did not intend to test. Before enabling auto-queue:

• Verify your CIDR ranges are correct — a typo in a CIDR (e.g., /16 instead of /24) can expand the scope to thousands of unintended hosts
• Populate exclusion lists — production systems, printers, medical devices, and other sensitive infrastructure should be explicitly excluded
• Review generated action items before enabling auto-queue on a new engagement — check that the targets match your Rules of Engagement
• Use CONFIRM approval tier for your first engagement with auto-queue — review every action item manually until you're confident in the scope definition

Auto-queue scope enforcement is only as good as the scope definition you provide. An incorrect scope definition combined with auto-queue can result in unauthorized testing of out-of-scope systems — a legal liability regardless of intent.

Out-of-Scope (OOS) Handling

When a tool generates an action item whose target falls outside the defined scope (e.g., SS3 discovers a web server on an IP not in the CIDR ranges), the item is flagged as OOS (out-of-scope).

OOS items appear in the action items list with a distinct visual indicator. They are never auto-approved regardless of the approval tier setting — they always require manual approval.

OOS Approval Flow

To execute an OOS action item:

Review the target to confirm it should be tested
Click Approve OOS on the action item
The item moves to 'approved' status and enters the queue

When you approve an OOS item, it is logged with a timestamp and the approving user for audit purposes.

Authorization Reminder

⚠️ Explicit Written Permission Required for OOS Targets

Before approving any OOS (out-of-scope) action item, you must have explicit written permission from the asset owner to test the target. This means:

• The target must be covered by your signed Rules of Engagement (RoE) or Statement of Work (SoW)
• If the target is not in your original RoE/SoW, obtain a written scope amendment from the client before proceeding
• Document the authorization in your engagement notes — who approved it, when, and the exact scope addition
• A verbal "go ahead" is not sufficient — you need written authorization that can be produced if questioned

Testing a system without explicit written authorization is illegal under the CFAA, CMA, and equivalent laws worldwide, regardless of intent. The OOS flag exists specifically to protect you from accidental scope breaches — do not bypass it without proper documentation.

OOS Settings

OOS behavior is configured per-engagement in the project settings:

Manual Operations

Beyond auto-queue, the action items interface supports manual operations:

Approve Approve

Manually approve a pending action item. It enters the execution queue immediately.

Dismiss Dismiss

Dismiss an action item — it will not be executed. Dismissed items remain visible (with a strikethrough) for audit purposes.

Launch Now Launch

Immediately launch the recommended tool for this action item, bypassing the queue. The tool starts with the action item's target injected into its settings. Respects parallelism rules — if an exclusive tool is running, the launch is blocked.

Add Note Note

Add a free-text note to any action item. Use for documenting why an item was approved, dismissed, or deferred.

Bulk Approve / Dismiss Batch

Select multiple items and approve or dismiss them in one operation. Useful for triaging large batches of action items after a recon tool completes.

Dynamic Tool Registration

When auto-queue tries to launch a tool that wasn't enabled in the original engagement wizard (e.g., OSift discovers API endpoints but Siphon wasn't selected), Crucible automatically registers the tool into the project:

Creates the tool's output directory under the appropriate scope
Adds the tool to the project's tool list
Makes its settings panel available in the Settings tab
Emits a tool_registered Socket.IO event so the console sidebar updates live

The original tool list is preserved in original_tools so you can see what was manually selected vs. what was auto-added. Auto-added tools are tracked separately in auto_added_tools.

Target Injection Details

When an action item is executed, Crucible injects the action item's target into the tool's settings file before launch:

Tool	Injected Setting	Format
Fracture	`scan.target_url` + `scan.target_urls`	URL with auto-detected scheme (https for ports 443/8443/9443/4443/3443/8444, http otherwise)
Siphon	`scan.api_base_url` + `scan.api_base_urls`	URL with auto-detected scheme
Auger	`host` + `port`	Parsed from `ip:port` format
SS3	`scan.targets`	IP addresses or CIDR ranges
OSift	`domains`	Domain names
AuthProbe	`target_url`	URL (in-memory only, no settings file)
Isotope	Resolved file paths	Local file paths resolved by searching all tool output directories for matching filenames

Target Deduplication & Validation

Before injecting targets, Crucible applies several safety checks:

Deduplication — removes duplicate targets from mixed newline/comma separation
ASN rejection — ASN identifiers (e.g., AS22843) are rejected with an error log — no tool can expand ASN numbers into IPs. Convert to IP ranges first
URL scheme detection — targets without a scheme get https:// for known HTTPS ports (443, 8443, etc.) and http:// for everything else
Exclusion check — targets whose IP or hostname appears in the project's exclusion list are silently dropped

Audit Trail

Every action item state change is logged for audit purposes:

Generation — timestamp, source tool, target, recommended tool, scope, OOS flag
Approval/Dismissal — timestamp, user who acted, reason (if noted)
Launch — timestamp, settings injected, queue position
Completion — timestamp, exit code, findings count

This audit trail is preserved in the engagement directory and is accessible from the Logs tab. Stale running items (from server restarts) are automatically repaired on load — their status is reset to 'pending' so they can be re-launched.

Crucible Docs

Action Items & Auto-Queue