DEV Community

Cover image for I built a local OSINT recon dashboard that goes deeper than just checking if a username exists
ic0e
ic0e

Posted on

I built a local OSINT recon dashboard that goes deeper than just checking if a username exists

github.com/ic0e/OS-Recon

Most people who've looked into OSINT tools have come across Sherlock or Maigret - you give them a username and they tell you where it exists across the web. They're useful, but they share the same limitation: they call an HTTP request, check the status code, return true or false, done.

The problem is that the user is expected to check all the data, gather it and analyze it, using different tools & messy workflows.


What it actually does

OS-Recon is a local recon dashboard. You give it a username (or a few), and it works in Human In The Loop (HITL) stages:

STAGE 1: NORMAL SCAN
It probes dozens of platforms concurrently and tries to be smarter about false positives by using a Chrome impersonator. When a platform blocks the request, it gets flagged as blocked rather than "found", so you know to check it manually instead of chasing a ghost.

STAGE 2: GITHUB ANALYZATION

If your target has a GitHub profile, there's a dedicated module that goes through their public repositories, parses commit history, and automatically flags exposed email addresses - most developers don't realize their email is embedded in every commit they've ever pushed.

STAGE 3: DEEP PRY

This is the core feature of the project. For the profiles that are actually found, you can launch the deep pry layer - it spins up isolated stealth browser instances (real headless Chrome, not just HTTP requests) that bypass anti-scraping walls and pull the raw metadata that static scanners can't reach. Bios, outbound links, platform-specific variables, the kind of data that only shows up when a real browser loads the page.

STAGE 4: AI ANALYSIS

All the collected data can be piped through an AI analysis tab powered by Groq that produces a structured risk report - pattern detection, username consistency across platforms, etc. This is the most unfinished part but already useful.


Why build this when other tools exist?

The honest answer is that I wanted one workflow instead of four. The usual process is: run Sherlock, manually check the blocked ones, open a separate tool for GitHub recon, copy-paste everything into a doc. OS-Recon tries to be the single starting point for a recon session - not to replace anything, but to stop constant context switching and mess.


What it looks like

The frontend is a React/TypeScript dashboard with a scan view, a deep pry launchpad, and the analytics tab. Here's the scan running:

scan demo

And the stealth browser layer pulling deep profile data:

deep pry demo


Where it's at

It's an early MVP. The core flow: scan, deep pry, The GitHub scan works end to end. The AI analytics module is functional but rough. False positive rate on the scanner still needs work.

Everything runs locally. The stack is FastAPI + React/TS + nodriver + HTTPX + curl-cffi.

If you want to try it or contribute: github.com/ic0e/OS-Recon

Feedback welcome, especially if something breaks or the approach seems wrong. If you're a dev, contributions and issues are open on GitHub.

Top comments (0)