Crucible

Overview

Crucible is the unified management platform for penetration testing engagements. It wraps 16 specialized security tools in a structured workflow: create an engagement, configure scope and targets, launch tools, monitor progress in real time, review findings, generate reports, and export deliverables — all from a single browser interface.

Crucible runs as a Flask/Socket.IO application on port 5500 over HTTPS with session-based authentication (_auth.py). It supports 34 visual themes.

Managed Tools

Benefits of Managed Mode

While every tool in the table above can run standalone from the command line, running them through Crucible provides significant advantages:

New Engagement Wizard

The wizard creates a new penetration testing engagement with all the configuration tools need to operate.

Step 1 — Client & Engagement

Step 2 — Scope Definition

Define what is in scope for the engagement. Each scope type enables specific tools.

Step 3 — Consultant & Reporting

Step 4 — Tool Registration

Based on the scopes enabled in Step 2, Crucible auto-registers the appropriate tools. You can also manually register additional tools. Each registered tool gets:

• A settings file (<tool>_settings.yaml) pre-populated from the scope definition
• An output directory under the engagement directory
• Console, findings, and log tracking in the dashboard

Edit Engagement Wizard

Opens the same form as New Engagement, pre-populated with the current configuration. All fields are editable. Changes to scope definitions propagate to tool settings files. Adding a new scope auto-registers the corresponding tool. Removing a scope does not delete existing findings — it only prevents new launches.

Additional edit-only options:

• Re-base paths — If the engagement directory was moved, Crucible detects the mismatch via crucible_meta.json and offers to rebase all internal paths
• Archive & Rescan — Archives current tool output and re-launches with fresh settings (useful for re-assessment)

Project Dashboard

The main workspace after creating or selecting an engagement. All interaction happens through the tabbed interface.

Settings Tab

Per-tool configuration management. Each registered tool has its own settings panel.

Common Settings (All Tools)

Authentication Settings (Fracture, Siphon)

Web and API tools need to know how to authenticate to the target application. Supported methods:

Test Connection

The Test Connection button validates that the configured authentication works against the target before launching a full assessment. It performs a lightweight HTTP request with the configured auth method and reports success/failure with status code and response details.

AuthProbe Integration

The Run AuthProbe button launches AuthProbe against the target URL to detect the authentication technology in use (e.g., Okta, Azure AD, custom form, Basic Auth). Results populate the auth method dropdown automatically, reducing manual configuration. AuthProbe supports --rendered mode for JavaScript-heavy login pages.

Spec File Upload (Siphon)

Upload an OpenAPI/Swagger specification file (.json or .yaml) for API testing. Siphon uses the spec to discover all endpoints, methods, and parameter schemas — testing both documented endpoints and probing for undocumented (rogue) endpoints.

Wireless Settings (Aether Family)

Archive & Rescan

Archives the current tool's output directory (timestamped backup) and creates a fresh output directory. Use this for re-assessment without losing prior results. The archived data remains in the engagement directory under archive/.

Console Tab

Real-time process management and live output streaming for all registered tools.

Tool Launch Controls

Console Output

• Live stdout/stderr streaming via Socket.IO
• Color-coded: findings highlighted, errors in red, status updates in blue
• Console history preserved in memory and on disk — new tabs receive full history
• Per-tool console tabs — switch between tools to see their individual output
• Combined feed view showing all tools' status in one panel

Pre-Flight Health Check

Before launching, the Health Check button verifies that the tool's script exists, is executable, and all required dependencies are available. Reports specific errors if anything is missing.

Instance Details

For each running tool, view: current scope (in-scope vs OOS), target list, settings file path, process ID, uptime, and checkpoint data (if paused).

Scheduling

Testing hours are critical for engagements where the client has restricted testing to business hours or maintenance windows.

Subprocess Management

View every child process spawned by each tool (nmap, nuclei, gobuster, etc.) with PID, command line, CPU/memory usage, and runtime. Kill individual subprocesses without terminating the parent tool.

Intelligence Tab

Aggregated intelligence from all tools, organized into 40+ panels across 9 categories. Intelligence is read-only — it reflects what tools have discovered.

OSINT Intelligence (OSift)

Network Intelligence (Scattershot3)

Web Application Intelligence (Fracture)

API Intelligence (Siphon)

Intelligence Export

Each intelligence panel supports XLSX export — download the data as a structured Excel spreadsheet for offline analysis or inclusion in reports.

Findings Tab

Central management of all security findings across every tool in the engagement.

Findings Table

All findings sorted by risk severity (Critical → High → Medium → Low → Info), then by tool, then alphabetically. Each row shows:

• Risk badge (color-coded: Critical, High, Medium, Low, Info)
• Title, IP:Port, service, tool source, CVE IDs, description preview

Filtering & Search

Finding Detail Panel

Click any finding to expand the full detail panel showing:

• Title & Risk — with risk override history
• Description — full vulnerability description
• Impact — what an attacker can achieve
• IP, Port, Service, Hostname — affected asset details
• CVEs — linked CVE identifiers
• OWASP / NIST Mapping — compliance framework references
• Remediation — recommended fix
• Command — exact command that produced the finding
• Output — tool output (truncated to 4096 chars with full-view link)
• Evidence File — link to the output file on disk
• Exploit Details — ExploitDB, Metasploit module references
• Notes — tester-added notes (free-text, persisted per finding)

Finding Actions

Findings Snapshots & Diffing

Crucible can take a snapshot of the current findings state. Later, you can diff against a previous snapshot to see what changed: new findings, removed findings, and risk overrides. Useful for re-assessment engagements.

Export Formats

Action Items Tab

Cross-tool recommendation pipeline. When a tool discovers something that another tool should investigate, it emits an action item.

How Action Items Work

1. SS3 discovers a web server → emits action item: "Test https://target:443 with Fracture"
2. SS3 discovers an API endpoint → emits action item: "Test https://api.target with Siphon"
3. OSift discovers a subdomain → emits action item: "Scan sub.target.com with SS3"
4. SS3 discovers a database port → emits action item: "Test target:3306 with Auger"

Action items include the target, recommended tool, and any context (e.g., discovered service type, version). You can accept (launch the recommended tool) or dismiss individual items.

Tool Generation Chains

Exclusion Filtering

Action items whose targets match the engagement exclusion list are automatically filtered out and will not appear as pending recommendations.

Auto-Queue

Auto-queue is Crucible's automated tool chaining system. When a tool finishes, Crucible examines all pending action items, groups them by recommended tool, and launches the next tool with pre-populated targets and credentials.

Auto-Queue Configuration

Auto-Queue Behavior

• Dequeue timing — Runs when a tool completes. Also retries every 30 seconds if a launch was blocked (e.g., by parallelism rules or RAM limits).
• Parallelism enforcement — Auto-queue respects the same group rules as manual launches: exclusive tools cannot overlap, OSINT can only parallel with SS3.
• RAM check — Blocks launch if system RAM usage exceeds 85%.
• Credential propagation — When the engagement has authentication configured, auto-queue writes credentialled settings files for tools that need auth (Fracture, Siphon).
• Dedup — Won't re-queue a tool/target combination that's already been launched or is currently running.
• Pause awareness — When a project is paused, auto-queue stops dequeuing. Resumed projects restart the dequeue cycle.

Out-of-Scope (OOS) Handling

Logs Tab

Combined log viewer for the entire engagement.

Log Sources

• Tool Logs — Parsed from __CRUCIBLE_LOG__ tokens with severity: INFO, WARNING, ERROR, FINDING, STATUS, DONE
• Crucible Logs — Application-level events: tool launches, pauses, resumes, kills, settings changes, finding modifications
• Combined View — Merged timeline of all sources

Log Features

Errors Tab

Filtered view showing only error-level entries across all tools.

• Time-range filter (From/To pickers) identical to Logs tab
• Error-count pill reflects the same ERROR/EXCEPTION/TOOL_ERROR/FATAL/CRITICAL levels
• Auto-categorized by source: tool errors vs Crucible errors vs communication errors

Reports Tab

One-click report generation across 50+ report types organized by scope category.

Report Scopes & Types

Report Options

Report Types Available

The /api/report-types/<project_id> endpoint returns only report types whose scope gate matches the engagement's active scopes. A wireless report won't appear unless the engagement has wireless scope enabled and an Aether-family tool registered.

Auditability

Crucible maintains comprehensive audit trails for every action in the engagement:

Parallelism Groups

Crucible enforces concurrency rules to prevent resource exhaustion and tool conflicts:

Integration Points

Crucible implements defense-in-depth across authentication, transport, session management, and data handling.

Transport Security: All traffic is encrypted with TLS 1.2 or higher. In production deployments, Crucible sits behind an nginx reverse proxy with a properly signed certificate. For standalone or lab use, Crucible generates a self-signed certificate at startup. Unencrypted HTTP connections are redirected to HTTPS.

Authentication: Crucible uses the shared _auth.py module — the same session-based authentication system used across the Crucible platform. Users authenticate with a username and password, and sessions are managed via Flask's secure session cookies with the HttpOnly and Secure flags set.

CSRF Protection: All state-changing POST, PUT, and DELETE requests are protected against Cross-Site Request Forgery via token validation. The CSRF token is embedded in forms and validated server-side on every mutation.

Session Management: Sessions expire after 30 minutes of inactivity. A 5-minute warning is displayed before expiration, giving the operator time to extend the session. Session data is stored server-side; only the session identifier is transmitted to the client.

Audit Logging: All significant actions — tool launches, kills, finding modifications, project creation and deletion, export and report generation, and authentication events — are written to a persistent audit log with timestamps and the authenticated user identity.

Path Traversal Protection: All file upload endpoints validate filenames and paths to prevent directory traversal attacks. Uploaded files are sanitized and placed in designated directories only.

Credential Handling: When a managed tool requires sudo privileges (e.g., Scattershot3 for raw socket operations or Aether for wireless interface control), the sudo password is passed from the browser to the server via an encrypted SocketIO channel and relayed directly to the tool's stdin. The password is held only in memory for the duration of the relay and is never written to disk, logged, or persisted in any form.

Every finding in Crucible carries a catalogue ID that identifies the tool of origin and the specific finding type. Catalogue IDs follow the pattern <PREFIX>-NNN where the prefix is a two-letter tool code and NNN is a sequential number within that tool's catalogue.

Catalogue ID Prefixes

Risk Levels

All findings use uppercase risk classifications: CRITICAL (exploitable with immediate business impact), HIGH (exploitable or high likelihood of exploitation), MEDIUM (exploitable under specific conditions or moderate impact), LOW (minor impact or difficult to exploit), and INFO (informational — no direct security impact but relevant for security posture awareness).

Cross-Tool Deduplication

When multiple tools report the same vulnerability, Crucible resolves duplicates by matching on three fields: normalized title (case-insensitive, whitespace-trimmed), IP address, and port number. The merged finding retains the highest risk level from any contributing tool and records all source tools in the source_tools field. This ensures that an SSL/TLS weakness discovered by both Scattershot3 (network recon) and Fracture (web testing) appears as a single finding in reports while preserving attribution to both tools.

Crucible's ActionEngine automatically generates follow-up tasks when tools discover new targets, services, or entry points. This creates an intelligent pipeline where reconnaissance findings flow into targeted testing without manual intervention.

Generation Rules

Action items are generated based on a tool-to-tool mapping that defines which tools should be recommended when a discovery is made:

• Fracture is recommended when OSift or Scattershot3 discovers a web service (HTTP/HTTPS ports, detected web servers)
• Siphon is recommended when OSift or Scattershot3 discovers an API endpoint or service
• Auger is recommended when Scattershot3 discovers a database service (MySQL, PostgreSQL, MSSQL, Oracle, MongoDB, Redis)
• Scattershot3 is recommended when OSift discovers new IP addresses or domain resolutions that expand the target scope

When a tool emits a __CRUCIBLE_ACTION_ITEM__: token, the payload contains the recommended tool, target, and justification. The ActionEngine validates the target, checks scope, and creates the item.

IP Validation

Before accepting any action item, the target IP is validated against multiple filters: known DNS resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) are rejected, network and broadcast addresses (x.x.x.0) are rejected, loopback and multicast ranges are rejected, leading-zero octets (which indicate date or version artifacts, not IP addresses) are rejected, and addresses outside the engagement scope are rejected. This prevents tools from generating bogus action items based on misinterpreted data.

Lifecycle States

Each action item progresses through a defined lifecycle:

1. Pending — the item has been generated and is awaiting operator review. The operator can see the target, recommended tool, justification, and a preview of the command that will be executed.
2. Queued — the operator approved the item, and it has been submitted to QueueManager. It will launch when parallelism constraints allow.
3. Running — the tool is executing against the specified target.
4. Complete — the tool finished successfully. Its findings have been injected into the FindingsEngine.
5. Failed — the tool encountered an error during execution.
6. Dismissed — the operator determined the follow-up is unnecessary and dismissed the item.

Scope-Aware Registration

Action items are only generated for tools relevant to the engagement's active scopes. If the wireless scope is not active, no Aether action items will be created regardless of what other tools discover. If the API scope is not active, no Siphon items will be generated. This prevents irrelevant action items from cluttering the queue.