Settings Tab
Per-tool configuration with authentication, file uploads, and scope integration.
Overview
Each registered tool has its own settings panel accessible from the Settings tab. Settings are saved as JSON files in the project directory (e.g., fr_settings.json for Fracture). Changes take effect on the next tool launch — they are not retroactive to running tools.
Settings panels are organized by tool, with common features:
- Save button persists settings to disk immediately
- Reset button reverts to defaults
- Scope backfill automatically injects scope definition values (CIDR ranges, exclusions) into tool settings on save
Scattershot3 Settings
Network reconnaissance configuration. Controls how aggressively SS3 scans, which tools it invokes, and what targets to skip.
| Field | Required | Description |
|---|---|---|
| Timing Template | No | Nmap timing template (T0–T5). T4 is recommended for most engagements — fast but not reckless. T3 is default (polite), T5 is insane (may drop packets). Lower values are stealthier but dramatically slower. |
| Discovery Min Rate | No | Minimum packets per second during the host discovery phase. Higher values speed up large-scope scans. Default: auto (nmap decides). Overrides scope definition value if set there. |
| Discovery Min Parallelism | No | Minimum number of parallel host probes during discovery. Higher values increase throughput on fast networks. Default: auto. |
| Passive Seed Duration | No | Seconds to listen passively for network traffic before active scanning begins. Useful for detecting live hosts without sending probes. Default: 0 (skip passive phase). |
| Targets | Yes | IP addresses and CIDR ranges to scan. Auto-populated from the scope definition — manual edits are overwritten on scope backfill. |
| Excluded Tools | No | Third-party tools to skip during the scan. Checkboxes for: gobuster, nikto, wpscan, nuclei, sslscan, testssl, shcheck, webanalyze, whatweb, ssh-audit. Useful when a tool causes issues or is too noisy for the engagement. |
| Host Exclusions | No | IP addresses to skip even if they fall within target ranges. Use for production systems, printers, or hosts that must not be scanned. |
| Nmap Extra Flags | No | Custom nmap flags appended to all scan commands. Example: --script-args http.useragent='Mozilla/5.0' |
OSift Settings
OSINT reconnaissance configuration. Controls which domains to gather intelligence on and how aggressively to probe DNS.
| Field | Required | Description |
|---|---|---|
| Domains | Yes | Target domains for OSINT gathering (e.g., example.com, corp.example.com). One per line. Auto-populated from scope definition. |
| Passive Only | No | When enabled, disables active DNS probing (no zone transfers, no brute-force subdomain enumeration). Uses only passive sources (certificate transparency, search engines, WHOIS). Safer for stealth engagements. |
| DNS Resolver | No | Custom DNS resolver IP address. Default: system resolver. Use a fast public resolver (e.g., 8.8.8.8) for large domain lists. |
| dnsx Enrichment | No | Enable the dnsx DNS enrichment pass that resolves all discovered subdomains with additional record types. Adds detail but extends scan time. |
| Subdomain Wordlist | No | Path to a custom subdomain wordlist file. Default: built-in wordlist. Large wordlists increase discovery but slow the scan significantly. |
Fracture Settings
Web application testing configuration. Defines target URLs, authentication, and scan behavior.
| Field | Required | Description |
|---|---|---|
| Target URL | Yes | Primary web application URL to test (e.g., https://app.example.com). This is the starting point for Fracture's spider and all OWASP Top 10 testing. |
| Additional Target URLs | No | Extra URLs to include in the assessment. Each gets its own testing pass. |
| Spider Depth | No | Maximum link depth for the web spider. Higher values find more pages but take longer. Default: 3. |
| Max Pages | No | Maximum number of pages to spider. Prevents runaway crawling on large applications. Default: 500. |
| Nuclei Templates | No | Custom nuclei template directories. Default: all built-in templates. Narrow this to reduce scan time or focus on specific vulnerability classes. |
| Excluded Checks | No | Specific checks or tool passes to skip. Useful when a check causes false positives or is too disruptive for the target. |
Authentication Settings
Configure how Fracture authenticates to the target application. This is critical for testing behind-login functionality.
| Field | Description |
|---|---|
| Enabled | Toggle authentication on/off. When off, Fracture tests only unauthenticated functionality. |
| Method | Authentication method: none (no auth), form_login (HTML form with username/password), basic (HTTP Basic Auth), bearer (Bearer token in Authorization header), cookie (pre-set session cookie), custom_header (custom header name/value pair). |
| Username / Password | Credentials for form_login and basic auth. |
| Login URL | URL of the login page (for form_login). Fracture navigates here to submit credentials. |
| CSRF Field | Name of the CSRF token field in the login form (e.g., csrf_token, _token). Fracture extracts and submits this automatically. |
| Session Cookie | Pre-authenticated session cookie value (for cookie method). Useful when the login flow is too complex for automated auth. |
| Token | Bearer token or API key value (for bearer method). |
| Token Type | Token type prefix (default: Bearer). Some APIs use Token or custom prefixes. |
| Custom Header Name / Value | For custom_header method — specify the exact header name and value to send with every request. |
Test Connection
Click Test Connection to probe the target URL and auto-detect the authentication method. The test:
- Sends a GET request to the target URL
- Checks for login redirects, HTTP 401/403 responses, and auth headers
- Attempts form login, basic auth, and bearer auth in sequence
- On success, populates the auth method, session cookie, CSRF field, and other fields automatically
This saves time compared to manually identifying the auth mechanism. If auto-detect fails, configure auth manually using the fields above.
Siphon Settings
API testing configuration. Defines target API endpoints, specs, and rate limiting.
| Field | Required | Description |
|---|---|---|
| API Base URL | Yes | Primary API base URL (e.g., https://api.example.com/v1). This is the root for all API endpoint testing. |
| Additional API URLs | No | Extra API base URLs to include. |
| OpenAPI Spec | No | Upload an OpenAPI/Swagger specification file (JSON or YAML). Uploading a spec enables Siphon to test all documented endpoints. Without a spec, Siphon discovers endpoints via crawling — which may miss undocumented endpoints that the spec defines. |
| Rate Limit | No | Maximum requests per second. Use to avoid overwhelming the API or triggering rate-limiting defenses. Default: no limit. |
| Excluded Endpoints | No | API endpoint paths to skip (e.g., /health, /metrics). Useful for avoiding monitoring endpoints that generate noise. |
Authentication
Same authentication methods as Fracture (form_login, basic, bearer, cookie, custom_header). API testing commonly uses bearer (API key or JWT) or custom_header (e.g., X-API-Key).
The Test Connection button works the same as in Fracture — probes the API base URL and auto-detects the auth mechanism.
Auger Settings
Database security testing configuration.
| Field | Required | Description |
|---|---|---|
| Host | Yes | Database server hostname or IP address. |
| Port | Yes | Database port. Common defaults: MySQL 3306, PostgreSQL 5432, MSSQL 1433, Oracle 1521, MongoDB 27017, Redis 6379. |
| Database Type | Yes | Database engine: MySQL, PostgreSQL, MSSQL, Oracle, MongoDB, or Redis. Determines which test modules and queries Auger runs. |
| Username | Yes | Database account username. Use an account with sufficient privileges to run security queries (SHOW GRANTS, INFORMATION_SCHEMA access, etc.). |
| Password | Yes | Database account password. |
| Databases | No | Specific databases to test. If blank, Auger tests all accessible databases. Narrowing this reduces scan time and avoids touching production databases outside scope. |
Wireless Settings (Aether Family)
Configuration for WiFi, Bluetooth, Zigbee, and UWB assessments. Requires a compatible wireless adapter.
| Field | Required | Description |
|---|---|---|
| Interface | Yes | Wireless adapter to use. Detected automatically from the system — select from the dropdown. Must support monitor mode for WiFi assessments. |
| Channel Hopping | No | Enable automatic channel hopping to capture traffic across all channels. Disable to lock to a specific channel. |
| Capture Duration | No | Seconds to capture wireless traffic before analysis. Longer durations find more clients and networks but delay results. |
| Target BSSIDs | No | Specific access point MAC addresses to target. If blank, all detected networks are assessed. |
| Target SSIDs | No | Specific network names to target. If blank, all detected networks are assessed. |
| Deauth Enabled | No | Enable deauthentication attacks to force clients to reconnect (for WPA handshake capture). Disruptive — only enable when authorized and acceptable for the engagement. |
WiFi Interface Management
The Settings tab includes wireless interface management controls:
- Detect Interfaces — Scan the system for wireless adapters (both Linux and macOS).
- Scan SSIDs — Quick scan for nearby wireless networks to verify adapter functionality.
- Monitor Mode — Switch the adapter to monitor mode (required for passive capture and deauth).
- Managed Mode — Switch back to managed mode (normal WiFi operation).
- Radio Cleanup — Kill straggler processes (airmon-ng, airodump, etc.) that may be holding the interface.
AuthProbe Integration
Run AuthProbe against a target URL directly from the Settings tab to fingerprint its authentication stack before configuring Fracture or Siphon. AuthProbe identifies:
- Login page locations and form structures
- Authentication methods in use (form-based, HTTP Basic, OAuth, SAML, etc.)
- CSRF token field names and patterns
- Session management mechanisms (cookies, JWTs, custom tokens)
- Software fingerprints (known CMS platforms, frameworks, WAFs)
Results can be used to pre-populate Fracture and Siphon auth settings, saving manual investigation time.
Scope Backfill
When you save settings for any tool, Crucible automatically backfills scope definition values into the tool's settings file. This ensures tool-level target lists stay synchronized with the engagement's scope definition.
Backfill injects:
- CIDR ranges and IP targets from the scope into the tool's target list
- Exclusion lists from the scope into the tool's host exclusions
- URL targets from the scope into web/API tool target URLs
Note: Manual edits to tool-level targets are overwritten by scope backfill on save. If you need tool-specific targets that differ from the scope, configure them after saving and avoid re-saving from the scope-linked settings.