Best practices for writing and extending exploit modules in Rustsploit.
Always mention CVE IDs, vendor names, and affected products in:
- The module file docstring / top-level comments
- Output messages (e.g.,
[*] Testing CVE-2025-14847 on {}, target) - The Module Catalog
Validate server responses before declaring success — false positives hurt credibility:
if response.status() == 200 && body.contains("expected_indicator") {
println!("{} Confirmed vulnerable: {}", "[+]".green(), target);
} else {
println!("{} Not vulnerable or patched", "[-]".red());
}If the exploit downloads or writes files (e.g., memory dumps, webshells):
- Store in the current working directory or a named subfolder
- Name files descriptively:
mongobleed_results_{target}.txt,nginx_pwner_results_{target}.txt - Inform the operator where output was written
If the exploit adds credentials or accounts (e.g., camera modules), document:
- The impact of the change
- How to revert (e.g., default creds to restore, commands to run)
Use cfg_prompt_* helpers from crate::utils if end-user input is needed. These respect the priority chain (API custom_prompts > global options > interactive stdin), ensuring modules work in shell, API, and CLI modes:
use crate::utils::{cfg_prompt_default, cfg_prompt_yes_no};
let command = cfg_prompt_default("command", "Command to execute", "id").await?;
let deploy = cfg_prompt_yes_no("deploy_webshell", "Deploy webshell?", true).await?;For modules supporting internet-wide scanning (target 0.0.0.0/0):
if target == "0.0.0.0" || target == "0.0.0.0/0" || target == "random" {
loop {
let ip = generate_random_public_ip();
if !is_excluded_ip(ip) {
execute(ip.to_string().as_str()).await.ok();
}
}
}See EXCLUDED_RANGES documentation in Security & Validation.
Disable honeypot detection in mass-scan mode to avoid interactive prompts blocking the scan loop.
- Safe check — writes/reads a test file to verify exploitability
- Unsafe reboot — reboots the device to confirm (destructive)
- Command exec — output retrieved, supports blind mode
- SSH shell — deploys Dropbear SSH on port 1337
- Sends malicious compressed packet with inflated
uncompressedSize - Parses error response to extract leaked memory chunks (field names / types)
- Prints any leaked strings (potential credentials / data) to console
- Includes deep-scan mode for extended analysis
- Authenticates via
/rest/login(token / cookie-based) - Creates a malicious workflow with expression injection payload
- Triggers via
/rest/workflows/{id}/run - Cleans up test workflow after execution
- 6 payload types: Info, Command, Environment, Read File, Write File, Reverse Shell
- SQL injection via
Authorization: Bearer ';{injection}header - Writes webshell via
SELECT INTO OUTFILE - Uses
.pthtrigger for Pythonchmodexecution - Interactive modes: deploy webshell, execute command, test SQLi only
- 10 checks: version disclosure, CRLF injection, PURGE method, variable leakage, merge slashes, header bypass / IP spoofing, alias traversal,
X-Accel-Redirectbypass, PHP detection, CVE-2017-7529 integer overflow - Results saved to
nginx_pwner_results_{target}.txt - Prints reminders for manual checks (Redis, CORS, request smuggling)
⚠️ Authorized testing only. These modules can cause service disruption.
| Module | Notes |
|---|---|
null_syn_exhaustion |
Raw socket, IP spoofing, XorShift128+ RNG, configurable PPS, >1M PPS capable |
connection_exhaustion_flood |
FD-bounded semaphore, supports infinite mode with graceful Ctrl+C |
tcp_connection_flood |
DNS pre-resolved, high-concurrency handshake stress, infinite mode |
http2_rapid_reset |
CVE-2023-44487 — HTTP/2 stream reset flood |
All exploit modules automatically benefit from the framework's multi-target dispatcher. There is no need to implement target iteration inside individual modules. The framework handles:
- Comma-separated targets —
192.168.1.1,192.168.1.2,192.168.1.3 - CIDR ranges —
192.168.1.0/24expands to all hosts in the subnet - File-based targets — pass a file path containing one target per line
- Random targets —
randomor0.0.0.0/0generates random public IPs withEXCLUDED_RANGESenforcement
The dispatcher calls the module's run() function once per resolved target. Modules only need to handle a single target string.