Spartan: The Shell Script That Chains Your Recon Tools (And Why That's Both Good and Bad)

Hook

The most starred reconnaissance automation framework you've never heard of is a 300-line shell script that does exactly one thing: run other people's tools in the right order.

Context

Bug bounty hunters and penetration testers spend their first hours on any engagement doing the same tedious dance: enumerate subdomains, check which ones respond, scan ports, identify technologies, capture screenshots, and brute-force directories. This reconnaissance phase is critical—miss a subdomain and you might miss the vulnerable admin panel—but it's also mind-numbingly repetitive.

Before automation frameworks, security researchers ran these tools manually, copy-pasting domains between terminal windows and losing track of which scans completed. Early attempts at automation involved Bash one-liners that grew increasingly unwieldy, or heavyweight frameworks that required learning complex configuration languages. Spartan emerged as a middle path: a shell script that orchestrates the most popular reconnaissance tools with zero configuration. You point it at a target, and it runs the entire playbook while you grab coffee. The approach resonated—194 stars suggests plenty of researchers wanted exactly this simplicity.

Technical Insight

Spartan's architecture is refreshingly straightforward: it's a sequential pipeline implemented as a shell script that calls external binaries. There's no database, no API, no daemon—just a script that runs tools in a predetermined order and saves output to timestamped directories.

The core workflow starts with subdomain enumeration using Sublist3r, which queries search engines and certificate transparency logs. Spartan then passes these subdomains through httprobe to filter for live hosts—no point scanning subdomains that don't respond. The live hosts feed into Masscan for high-speed port scanning (this is where the sudo requirement comes from; raw socket access needs root). Results flow through CMSeeK for CMS fingerprinting, then the Wayback Machine gets queried via waybackurls to discover historical URLs. Finally, Aquatone captures screenshots, and Dirsearch brute-forces directories on discovered web servers.

Here's a simplified version of how Spartan chains these tools:

#!/bin/bash
DOMAIN=$1
OUTPUT_DIR="recon_${DOMAIN}_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTPUT_DIR"

# Subdomain enumeration
echo "[*] Enumerating subdomains..."
sublist3r -d "$DOMAIN" -o "${OUTPUT_DIR}/subdomains.txt"

# Filter for live hosts
echo "[*] Filtering live hosts..."
cat "${OUTPUT_DIR}/subdomains.txt" | httprobe > "${OUTPUT_DIR}/live_hosts.txt"

# Port scanning
echo "[*] Scanning ports..."
sudo masscan -iL "${OUTPUT_DIR}/live_hosts.txt" -p1-65535 --rate=10000 -oJ "${OUTPUT_DIR}/masscan.json"

# CMS detection
echo "[*] Identifying CMS..."
while read host; do
    cmseek -u "$host" --batch >> "${OUTPUT_DIR}/cms_results.txt"
done < "${OUTPUT_DIR}/live_hosts.txt"

# Screenshot capture
echo "[*] Capturing screenshots..."
cat "${OUTPUT_DIR}/live_hosts.txt" | aquatone -out "${OUTPUT_DIR}/aquatone"

# Directory brute-forcing
echo "[*] Brute-forcing directories..."
while read host; do
    python3 dirsearch.py -u "$host" -e php,html,js --plain-text-report="${OUTPUT_DIR}/dirsearch_${host//[:.\/]/_}.txt"
done < "${OUTPUT_DIR}/live_hosts.txt"

echo "[+] Reconnaissance complete! Results in ${OUTPUT_DIR}"

The elegance here is in what Spartan doesn't do. It doesn't try to parse tool output, correlate findings, or present a unified dashboard. Each tool writes to its own output file, and you examine results manually. This Unix philosophy approach—do one thing well—means Spartan has minimal attack surface for bugs and zero learning curve if you already know the underlying tools.

The shell-based implementation makes customization trivial. Want to add nuclei for vulnerability scanning? Insert a nuclei command in the pipeline. Need to run subfinder instead of Sublist3r? Swap one line. Compare this to framework-based reconnaissance tools where adding a new tool means writing Python integration code, handling configuration schemas, and updating documentation.

The timestamped output directories are particularly clever for bug bounty work. Each scan creates a new folder with the date embedded, so you can run Spartan weekly on the same target and compare results over time. This simple versioning strategy beats complex database-backed approaches when you're tracking subdomain changes across monthly reconnaissance cycles.

However, the sequential execution model reveals the fundamental trade-off. While tools run one after another, Spartan makes no attempt at parallelization. Scanning 500 subdomains means waiting for Masscan to finish all 500 before CMSeeK starts. Modern frameworks like Axiom distribute these tasks across cloud instances, but Spartan runs everything on your local machine in a single thread. For small to medium engagements (under 100 subdomains), this doesn't matter. For enterprise-scale reconnaissance, you'll be waiting hours.

Gotcha

The sudo requirement is Spartan's biggest practical limitation. Masscan needs raw socket access for SYN scanning, which requires root privileges. This means you can't run Spartan in containerized environments without privileged mode, can't use it in CI/CD pipelines without security exceptions, and shouldn't run it on your primary workstation where a compromised dependency could escalate privileges. Some practitioners work around this by commenting out the Masscan stage and running nmap as a non-root user, but then you lose the high-speed scanning that makes reconnaissance tolerable.

The lack of error handling means failures cascade silently. If Sublist3r crashes, the live_hosts.txt file remains empty, and subsequent tools scan nothing. You'll get a "reconnaissance complete" message with empty result files, and unless you watch the terminal output, you won't know anything failed. Production-grade automation would check exit codes, implement retries, and fail loudly when tools misbehave.

Spartan also runs every tool with default settings, which is both a simplicity win and a flexibility loss. Masscan defaults to 10,000 packets per second—fast enough to crash cheap VPS network interfaces and loud enough to trigger every IDS on the planet. There's no rate limiting, no proxy support, and no user-agent rotation. For stealthy red team engagements, these defaults make Spartan unsuitable. The project's GitHub README lists ambitious features like CORS misconfiguration scanning and S3 bucket enumeration, but the TODO checkboxes remain unchecked and the last commit suggests development stalled. You're getting a working proof-of-concept, not an actively maintained tool.

Verdict

Use Spartan if you're learning reconnaissance methodologies and want to understand how tools connect in a workflow, you're doing personal bug bounty hunting where speed matters more than stealth, or you need a quick automation for one-off assessments and don't want to configure a heavyweight framework. It's ideal for CTFs, lab environments, and understanding the reconnaissance playbook before graduating to complex tooling. Skip Spartan if you need production-grade reliability with error handling and logging, you're working on sensitive engagements requiring stealth and rate limiting, you need parallel execution for large-scale scans across hundreds of subdomains, or you want actively maintained software with modern features. For those cases, invest time learning ReconFTW's configuration system or build custom pipelines with ProjectDiscovery's modular tools.