New Engagement Wizard
4-step wizard for creating and configuring a new pentest engagement.
Overview
The New Engagement wizard walks you through creating a fully configured pentest project in four steps. Each step builds on the previous — engagement metadata, tool selection, scope definition, and review. On submission, Crucible creates the directory structure, writes per-tool settings files, and registers the project.
Step 1 — Engagement Details
Core metadata about the engagement and the people involved. The Client Short value is particularly important — it becomes part of every file path and directory name for this engagement.
| Field | Required | Description |
|---|---|---|
| Client Name | Yes | Full legal name of the client organization. Used in report headers and project metadata. |
| Client Short | Yes | Abbreviated client identifier (e.g., ACME). Used in directory paths: <clients_base>/ACME/2026/crucible/ACME_20261015_140000/. Keep it short, uppercase, no spaces. |
| Year | Yes | Engagement year. Determines the year directory in the output path. Defaults to the current year. |
| Start Date | No | Engagement start date. Informational — used in report cover pages and project metadata. |
| End Date | No | Engagement end date. Can be used with engagement hours to enforce testing windows. |
| Engagement Type | No | Type of engagement (e.g., External Pentest, Internal Assessment, Full Scope). Used in report titles. |
| Engagement ID | No | Your organization's internal engagement tracking identifier. |
| Consultant Name | No | Name of the lead consultant or tester performing the engagement. |
| Consultant Title | No | Professional title of the consultant (e.g., Senior Security Engineer). |
| Consultant Email | No | Consultant's email address for report attribution. |
| Client POC Name | No | Client point of contact — the person who authorized testing and receives updates. |
| Client POC Phone | No | POC phone number for out-of-band communication during testing. |
| Client POC Email | No | POC email address for coordination and report delivery. |
Step 2 — Tools
Select which tools to enable for this engagement. Each tool category is shown with checkboxes. Enabling a tool adds it to the project, creates its output directory, and makes its settings panel available in the Settings tab.
Tip: Only enable tools you plan to use — each creates directories and configuration files. You can add tools later via Edit Engagement.
Tool Categories
Tools are organized by testing domain:
| Category | Tools | Purpose |
|---|---|---|
| Recon | Scattershot3, OSift, AuthProbe | Network scanning, OSINT gathering, authentication fingerprinting |
| Web / API | Fracture, Siphon | Web application testing (OWASP Top 10) and API testing (OWASP API Top 10) |
| Wireless | Aether, Aether-B, Aether-Z, Aether-U | WiFi, Bluetooth, Zigbee, and UWB assessment |
| Database | Auger | Database security auditing (MySQL, PostgreSQL, MSSQL, Oracle, MongoDB, Redis) |
| Network Analysis | Trawler | PCAP traffic analysis and protocol inspection |
| Compliance | Bastion, Dredge | Firewall policy audit and endpoint security/hardening assessment |
| Cloud | Forge | Cloud infrastructure assessment (AWS, Azure, GCP) |
| Mobile | Quill | Mobile application analysis (APK/IPA) |
| File Analysis | Isotope | Static file analysis with YARA rules |
| AI Red Team | pAIn | AI/ML model adversarial testing |
Step 3 — Scopes
Define testing scopes to organize tools and targets. Each scope groups related tools and defines the boundaries of what they can target. Scope configuration is critical — tools launched via auto-queue use these boundaries to determine valid targets.
Scope Types
| Scope | Typical Tools | Description |
|---|---|---|
| External | SS3, OSift, AuthProbe, Fracture, Siphon | External-facing assets — public IPs, domains, web applications |
| Internal | SS3, AuthProbe, Fracture, Siphon, Auger | Internal network — RFC 1918 ranges, Active Directory, file shares |
| OSINT | OSift | Open-source intelligence gathering — domains, emails, breaches |
| Web App | Fracture | Web application testing scope — specific URLs and paths |
| API | Siphon | API testing scope — base URLs and spec files |
| Wireless | Aether, Aether-B, Aether-Z, Aether-U | Wireless assessment — SSIDs, BSSIDs, channels |
| Database | Auger | Database targets — hosts, ports, credentials |
| Firewall | Bastion | Firewall audit — management IPs, policy files |
| Cloud | Forge | Cloud infrastructure — provider, region, credentials |
| Mobile | Quill | Mobile apps — APK/IPA uploads |
| File | Isotope | File analysis targets |
| Endpoint | Dredge | Endpoint security — hosts for hardening assessment |
Scope Definition Fields
Each scope has these configuration fields:
- CIDR Ranges — Target networks in CIDR notation (e.g.,
10.0.0.0/24,192.168.1.0/24). Tools will only scan addresses within these ranges. - URL Targets — Specific URLs for web/API tools (e.g.,
https://app.example.com). - Hostname Targets — Domain names and hostnames.
- Exclusion List — IPs, ranges, or hostnames to never scan, even if they fall within a CIDR range. Critical for protecting production systems, out-of-scope hosts, and infrastructure.
- Tool Assignments — Which tools are active in this scope.
Step 4 — Review & Create
Review all settings before creating the engagement. The summary shows:
- Client details and engagement metadata
- Enabled tools by category
- Scope definitions with target counts
- Output directory path
On submit, Crucible:
- Creates the directory structure at
<clients_base>/<client_short>/<year>/crucible/<client_short>_<timestamp>/ - Creates per-scope subdirectories for each active scope
- Writes per-tool settings JSON files with defaults and scope-backfilled targets
- Writes project metadata (
crucible_meta.json) - Registers the project in
projects.json
Edit Engagement
Access from the project dashboard via the gear icon or from the engagement sidebar. The edit view presents the same fields as the wizard, pre-populated with the current configuration.
What you can change:
- Client details and engagement metadata
- Add or remove tools (adding a tool creates its output directory; removing does not delete existing data)
- Modify scope definitions (CIDR ranges, exclusions, targets)
- Update consultant and POC information
Important: Changes take effect for future tool launches. Running tools are not affected — they continue with their original settings until they complete or are restarted.