spray-n-pray-support/README.md

# Spray 'N Pray

Spray 'N Pray is a self-hosted password spraying console for authorized security engagements. It's a Go-native single-page app (Fiber + vanilla JS + SQLite) that runs unattended, scheduled spraying against ADWS, FTP, HTTP/HTTPS, Kerberos, LDAP/LDAPS, MSSQL, OWA, RDP, RPC, SMB, and SSH either locally or tunneled out through a chain of SOCKS5 jump hosts. It includes account-lockout-aware Safe Mode, email/webhook notifications, and full activity logging.

> **Authorized use only.** Spray 'N Pray is built for penetration testers and red teamers operating under a signed engagement or explicit written authorization. Do not point it at systems you don't have permission to test.

## Platforms

Prebuilt binaries are published for:

- Linux (amd64, arm64)
- macOS (amd64, arm64)
- Windows (amd64)

## Getting Started

```
./spraynpray -iface 0.0.0.0 -port 1337
```

Must be run as root. Once it's running, open the console in a browser at the address it prints on startup.

## Reporting Issues

Becauase this is a private repo, issues must be submitted via email. **All bug reports, feature requests, and questions must go to [issues@krkn.tech](mailto:issues@krkn.tech)**.

A good report is one we can act on without a back-and-forth to get basic details. The template below covers what we need; the sections after it explain *why* each part matters and how to fill it in safely.

### Copy-paste template

````markdown
**Subject line:** [Spray 'N Pray] <short summary of the problem>

**Version:**
<from the app>

**Platform:**
<OS, version, architecture>

**Protocol & config at the time:**
- Protocol:
- Safe Mode: on / off
- SOCKS5 proxy: on / off

**Summary:**
<one or two sentences -what's wrong>

**Steps to reproduce:**
1.
2.
3.

**Expected behavior:**
<what you thought would happen>

**Actual behavior:**
<what actually happened - include exact error text if there was any>

**Screenshots / recordings:**
<attached, or "N/A" - see redaction note below before attaching>

**Activity log:**
<attached (exported via the download icon in the Activity pane), or "N/A" -see redaction note below>

**Additional context:**
<anything else worth knowing -recent changes, how often it happens, workarounds you've tried, etc.>
````

### Field-by-field notes

**Subject line** - Prefix it with `[Spray 'N Pray]` and keep the summary to one line. We triage by subject before opening the email, so a vague subject like "bug" or "help" gets picked up last.

**Version** - Shown in the console's top bar, immediately to the right of the "Spray 'N Pray" title, and also printed to the terminal when the binary starts. If you built from source yourself, say so and include the commit hash.

**Platform** - Full OS name/version and CPU architecture (e.g. "Ubuntu 22.04, amd64" or "macOS 14.5, arm64"). Cross-platform tools break differently on different platforms; this is often the first thing that narrows a bug down.

**Protocol & config** - Which protocol was selected (ADWS, FTP, HTTP, HTTPS, Kerberos, LDAP, LDAPS, MSSQL, OWA, RDP, RPC, SMB, SSH), and whether Safe Mode and SOCKS5 proxying were on. Most bugs in this app are protocol-specific or proxy-specific, so this narrows the search dramatically.

**Summary** - The elevator-pitch version of the bug. This is what we read first to decide severity and routing.

**Steps to reproduce** - Numbered, in the exact order you did them. "It doesn't work sometimes" is not reproducible; "1. Set protocol to LDAP, 2. Enable SOCKS5 proxy, 3. Click Spray" is. If you can't get it to reliably reproduce, say so explicitly and describe how often it happens instead (e.g. "roughly 1 in 5 runs").

**Expected vs. actual behavior** - Two separate, explicit statements, not one blended paragraph. This is the single biggest thing that speeds up triage: it tells us immediately whether this is a crash, a wrong-result bug, or a UX misunderstanding, without us having to infer it.

**Screenshots / recordings** - A screenshot of the console (or a short screen recording) is often faster than a paragraph of description, especially for UI bugs. Most email clients let you drag an image or video straight into the compose window as an attachment.

> **Redact before you attach.** This tool runs against real engagements. Before sending a screenshot or recording, check it for and blur/crop out: target hostnames and IP addresses, domain names, usernames, and - most importantly - any password or credential the tool found (they render in plain text in the Users panel and the Activity log). A UI bug report doesn't need real target data to be useful; a sanitized `corp.local` / `dc01.fake.local` stand-in reproduces the bug just as well.

**Activity log** - The Activity pane has a download icon next to "Clear" that exports the full session log - including timestamps - as a plain-text file. Attaching this (rather than copy-pasting a few lines) gives us the surrounding context: what ran before the bug, timing, and any other warnings or errors that fired around the same time.

> **Same redaction rule applies.** The activity log records valid credentials on a hit, and host/domain names throughout. Open the exported file and scrub anything engagement-sensitive before attaching - find/replace the real domain and any `VALID` lines' credentials with placeholders.

**Additional context** - Anything that doesn't fit the fields above: this is a regression from a version that worked, it only happens on your second run after a fresh install, you're behind a corporate proxy, etc. If you're not sure whether something is relevant, include it -extra context costs us nothing to skip; missing context costs a round-trip email.

## License

Spray 'N Pray is source-available under a custom license — see [LICENSE](LICENSE). In short: free to use, including on paid engagements, and free to modify for your own internal use; you may not sell, sublicense, or redistribute it (or a derivative) as a commercial product or service.