DEV Community: Shlok Shah

I kept losing scan chains to timeouts and copy-paste errors, so I built a recon-to-exploitation orchestrator instead of another scanner

Shlok Shah — Tue, 28 Jul 2026 11:59:00 +0000

Every engagement I ran involved the same 30+ tools, run in roughly the same order — but never actually chained: subfinder to find subdomains, then dnsx, httpx, naabu, nuclei for the recon side, then a second wave of SQLMap, Dalfox, Jaeles, Nikto once targets were confirmed live, then manually copying output between each so the next tool had the right input file. If step 4 of 30 failed silently, I wouldn't notice until the report came back with a missing section three hours later.

The tools themselves are excellent. The problem was the wiring between them across the entire pipeline — not just enumeration, but the vulnerability scanning and exploitation steps after it too.

So I built Oculus — a single-file Python orchestrator that chains ~30 industry-standard CLI tools across five phases — discovery, infrastructure mapping, content discovery, vulnerability analysis, and targeted exploitation — with actual orchestration logic on top, not just a bash script gluing stdout to stdin.

🔗 Code: https://github.com/shlokkokk/Oculus

Try it in three commands

git clone https://github.com/shlokkokk/Oculus.git oculus && cd oculus
chmod +x install.sh && ./install.sh
python3 oculus.py -d example.com --full-recon --no-confirm

That runs subdomain enum → resolution → alive hosts → ports → nuclei, then spits out output-example.com/report.html. Or skip the subset and run everything:

python3 oculus.py -d example.com --full-spectrum --no-confirm

The four problems actually worth solving

1. Silent failures. Most recon scripts treat "the tool ran" and "the tool worked" as the same thing. Oculus gives every module an explicit status:

Status	Meaning
`OK`	Finished with usable output
`Skipped`	Missing tool, missing input, or no API key — step didn't run
`Partial`	Ran but some sub-tools timed out or degraded
`Failed`	Critical failure — e.g. every subdomain tool errored out

That distinction matters: a Partial on Nikto shouldn't block your report, but a Failed on subdomain enum means everything downstream is garbage — you need to know that immediately, not after reading a report with an empty findings section.

2. Fixed timeouts don't scale. A 600-second cap makes sense for a 50-host scan and is actively wrong for a 5,000-host one. Oculus scales timeouts to the size of the target list instead of using one constant everywhere, so large scopes don't get killed mid-run just because the number was tuned for a small test case.

3. Losing a scan to a crash. Session state gets written to output-<domain>/session.json after each module completes, so a killed process resumes from where it left off instead of restarting the whole 36-module chain.

4. Babysitting a terminal for hours. Full Spectrum runs all 36 modules across 5 concurrent phases, which can run long. Oculus pushes one consolidated push notification per module via ntfy:

ntfy:
  enabled: true
  url: "https://ntfy.sh/your-topic"
  send_module_complete: true   # one ping per module, not per finding

Each ping has target, phase, status, per-tool line counts, and merged totals (unique subdomains, alive hosts, vulns) — so you can walk away from the terminal without losing track.

The full pipeline — not just recon

Running everything (--full-spectrum) walks all 36 modules through 5 phases, each with its own concurrency model:

PHASE 1 · DISCOVERY
  Subdomain Enum → DNS Bruteforce → DNS Resolution → Alive Hosts → TLS Scan
  + concurrent: ASN mapping, cloud asset probing, OSINT, Shodan, GitHub dorking

PHASE 2 · INFRASTRUCTURE
  Fast port scan + tech fingerprinting + WAF detection + screenshots, concurrently
  + full Nmap port scan and Nikto run in the background

PHASE 3 · CONTENT DISCOVERY
  URL collection → advanced crawl (hakrawler) → parameter mining + JS endpoint extraction
  + subdomain takeover checks, Cariddi crawl in the background

PHASE 4 · VULNERABILITY ANALYSIS
  Nuclei → GF pattern filtering, directory + API fuzzing concurrently
  + Jaeles signature scanning in the background

PHASE 5 · TARGETED EXPLOITATION
  SQLMap + Ghauri (SQLi), Dalfox (XSS), open redirect, CRLF injection,
  SSTI (Tplmap), 403 bypass, CORS misconfig, HTTP smuggling — all concurrent

That fifth phase is the part people miss when they hear "recon tool" — Oculus isn't stopping at "here are your live subdomains." It runs SQLMap/Ghauri, Dalfox, Tplmap, and CRLFuzz against confirmed live targets automatically, with the same status tracking and resumability as every earlier phase.

If you don't want the full run, there are two lighter presets: --full-recon (just the core 8-step discovery chain, 15-45 min) and --deep (a fixed 14-step advanced chain assuming recon's already done). Full Spectrum is the one that goes end to end.

What's actually running under the hood

Discovery: subfinder, amass, assetfinder → dnsx → httpx → naabu/nmap, katana/gau/waybackurls, hakrawler
Infrastructure & content: wafw00f, whatweb, gowitness/EyeWitness, ParamSpider/Arjun, LinkFinder, Cariddi, subzy, tlsx
Vulnerability analysis: nuclei, gf, ffuf, Kiterunner, Jaeles
Exploitation: SQLMap + Ghauri, Dalfox, Tplmap, CRLFuzz, nomore403, custom CORS/redirect/smuggling probes
OSINT & passive intel: theHarvester, Shodan + InternetDB, GitHub code search, ASN/cloud bucket probing
Orchestrator: pure Python 3.8+, no framework — just requests, dnspython, tldextract
Reports: HTML, JSON, and Markdown generated from the same session data
New in v4.2: a full web UI (FastAPI backend, React/Vite frontend) for running scans, watching live output, and browsing reports in-browser — including a screenshot review tab that groups captures by domain

What I'd actually want feedback on

The timeout-scaling formula and the four-state module status model are the two design decisions I iterated on the most, and I'm not fully convinced I've got them right yet. If you run recon pipelines regularly — what's your failure mode? Silent tool failures, timeout tuning, or something else entirely?

Only point this at systems you own or have written permission to test — it's built for authorized engagements and CTFs, not opportunistic scanning.

⭐ If you find it useful: https://github.com/shlokkokk/Oculus

Building Watchtower: An Autonomous Portfolio Intelligence System with Real-Time Cross-Platform Telemetry

Shlok Shah — Tue, 21 Jul 2026 16:23:36 +0000

When shipping and maintaining open-source projects, monitoring portfolio performance across the web is surprisingly fragmented.

Developers often manually check GitHub for stars and forks, browse Hacker News or Dev.to to see if recent posts received traction, and guess whether their project documentation has fallen out of sync with active codebase updates.

To solve this, I built Watchtower—an autonomous, open-source portfolio intelligence command center that monitors repository metrics, auto-discovers cross-platform mentions, predicts star milestone trajectories, and dispatches real-time telemetry alerts directly to mobile devices.

Key Architectural & Functional Highlights

1. Real-Time Mobile Telemetry (Telegram & Discord)

Watchtower monitors repository changes and cross-platform traction, sending structured notifications to your phone via Telegram Bot API and Discord Webhooks:

Star & Fork Alerts: Displays exact stargazer and fork growth alongside 14-day top traffic referrers (+1 star (1 -> 2 total)).
Reaction & Comment Alerts: Detects reader interactions on Dev.to and Hacker News posts with exact deltas (+1 new comment (7 -> 8 total)).
Traffic Spike Alerts: Triggers instant momentum warnings when page views surge by +25 or Hacker News points increase by +5.

2. Cross-Platform Auto-Discovery Engine

Rather than requiring manual log entries for every blog post or forum launch, Watchtower automatically queries:

Dev.to REST API: Inspects published article metadata and body markdown for embedded repository URLs, tracking page views, reactions, and comments.
Hacker News Algolia API: Discovers Show HN submissions and discussion threads pointing to your GitHub repositories.

3. Predictive Star Milestone Velocity

Using a rolling 7-day historical log of individual repository star counts, Watchtower calculates daily star growth speed and projects the estimated days remaining to reach upcoming milestone thresholds (10, 25, 50, 100, 250, 500, 1000 stars).

4. Automated README Staleness Detection

Documentation often lags behind active development. Watchtower queries commit histories to compare the last modification date of README.md against general repository push timestamps. If codebase updates are more than 30 days newer than the README, Watchtower flags the project with a staleness warning.

5. Actionable Weekly Recommendations

Watchtower evaluates conversion ratios (page views vs. star velocity), inactivity duration, and launch performance to generate rule-based weekly action items (e.g., "Receiving traffic but 0 stars — consider reviewing repository description and Topics to improve conversion").

Tech Stack & Security Model

Frontend Command Center: React, Vite, Vanilla CSS, Recharts, Lucide Icons.
Backend Automation: Node.js, Octokit REST API, Dev.to API, Algolia Search API.
Notification Gateways: Telegram Bot API and Discord Webhooks.
Security & Privacy: Zero API secrets bundled in the client build; all serverless interactions use authenticated proxy gateways.

Open Source & Community Feedback

Watchtower is completely open source and free to self-host on Vercel or schedule via GitHub Actions cron workflows.

If you find Watchtower useful or interesting, dropping a star on the GitHub repository means a lot and helps the project grow!

GitHub Repository:

https://github.com/shlokkokk/Watchtower

I would love to hear feedback and ideas from the developer community. What metrics or automated workflows do you currently use to manage your open-source portfolio?

I was tired of studying security tools from static cheatsheets, so I built ShellStack

Shlok Shah — Sat, 18 Jul 2026 09:41:35 +0000

I was tired of studying security tools from static cheatsheets, so I built ShellStack

When I started prepping for CEH and doing more CTFs, I ran into the same wall over and over: every resource for learning offensive security tools was either a wall of text in a PDF, a GitHub gist with no context, or a cheatsheet that assumed you already knew what half the flags did.

I didn't want notes. I wanted something that felt like sitting at an actual terminal — where I could browse tools, see real commands with context, and build the exact command I needed without digging through five tabs.

So I built ShellStack.

🔗 Live: https://shell-stack.vercel.app/
💻 Code: https://github.com/shlokkokk/ShellStack

What it actually does

ShellStack is a cybersecurity study platform built around one idea: learning security tools should feel operational, not passive.

280+ curated offensive security tools, organized into 19 categories, each with deep-dive docs — commands, common flags, when to use it, installation notes, and real examples
Interactive command builders — instead of memorizing flag combos, you fill in a form and get a ready-to-copy command generated live
20 CEH-aligned learning modules, built for structured study instead of flipping through slides
1,000+ command cheat sheet with fast search and one-click copy
A terminal-inspired UI that actually feels like a cyber-ops console instead of another docs site

The build

Stack: React 19, TypeScript, Vite, Tailwind CSS, GSAP, React Router, Radix UI primitives

A few things I focused on:

Search that actually ranks results. Early on, tool search was just naive string matching, which meant typing "nmap" could bury the actual Nmap entry under ten unrelated tools that happened to mention it in a description. I rebuilt it to weight exact and prefix matches higher, so the tool you're looking for shows up first, not buried on page 3.

Command builders that don't feel like a form. The tricky part wasn't the UI, it was designing a data model that could represent wildly different tools (a text-flag-heavy tool like Nmap vs. a mostly-positional-args tool) without a special case for every single one. Each tool's builder config lives in its own data file, so adding a new interactive tool doesn't mean touching the builder logic itself.

Content as data, not hardcoded pages. All 280+ tools and 20 CEH modules live in structured data files (src/data/tools/, src/data/modules/), not scattered across component files. This means the entire tool directory, cheat sheet, and CEH explorer all pull from the same source of truth — adding a new tool is a data entry, not a new component.

What's next

I'm still refining the command builder UX — it works, but I'm not 100% sure it's intuitive for someone seeing it cold. If you try it out, I'd genuinely love to know where it trips you up.

Also planning to expand the CEH module coverage and add a few more interactive builders for tools that currently only have static command references.

Try it

If you're studying for CEH, doing CTFs, or just want a faster way to look up a tool's flags without leaving your browser tab, take it for a spin:

🔗 https://shell-stack.vercel.app/
⭐ Star it on GitHub if it's useful: https://github.com/shlokkokk/ShellStack

Feedback, issues, and PRs are all welcome — this is very much a living project.