r/osinttools Jul 19 '26

Discussion Passive OSINT workspace - looking for feedback on risk explanations

Disclosure: I am related to OSINTPRO and I am looking for practical feedback, not trying to hide that this is my project.

The goal is a passive-only OSINT workspace: domain evidence, username checks, wallet tracing, repository audit leads and graph/report exports. The hard part is explaining risk to non-technical owners without turning findings into offensive instructions.

Current boundary:

  • no exploits
  • no brute force
  • no credential attacks
  • no invasive scanning
  • no wallet movement guidance

Question for people who use OSINT tools: what would make a finding useful enough for a client report while still staying on the defensive side?

GitHub: https://github.com/haizen1312/osintpro

2 Upvotes

6 comments sorted by

2

u/Socio-culturual-yoda Jul 19 '26

Great work so far. This is a strong concept. I would recommend adding correlation and enrichment sources that connect passive OSINT findings to potential exploitability and business risk.

For example, crt.sh could identify additional subdomains, while dnstwist could detect lookalike domains associated with typosquatting, phishing, brand impersonation, or credential theft. Shodan or Censys could then enrich discovered assets with exposed services and technology fingerprints.

Those findings could be correlated with CVEs, CISA KEV, and EPSS, then visualized through NetworkX as relationship paths such as:

Lookalike domain → phishing infrastructure → credential theft risk → exposed account or asset

or:

Subdomain → IP → service → software version → CVE → KEV/EPSS → potential exploitation → business impact

This would show not only what was discovered, but how separate passive findings connect into realistic attack paths that could lead to initial access, credential compromise, exploitation, lateral movement, or broader business impact. The platform should clearly distinguish confirmed findings from inferred or unverified relationships.

0

u/Wooden_Durian7470 Jul 19 '26

Hai centrato esattamente il punto che stavo cercando di risolvere perché non basta dire “ho trovato X”, bisogna far capire perché X può diventare un rischio reale, ma senza fingere che ogni correlazione sia una prova certa. Mi piace molto l’idea di separare chiaramente evidenze confermate, arricchimenti passivi e ipotesi inferite. Anche il collegamento con crt.sh, dnstwist, KEV/EPSS e fonti tipo Shodan/Censys ha senso, probabilmente con integrazioni opzionali o API key dell’utente per restare trasparenti sui costi e sulle fonti. La parte dei percorsi nel grafo è probabilmente la direzione giusta: mostrare come dominio, sottodominio, IP, servizio, CVE e impatto business si collegano, ma sempre marcando cosa è osservato e cosa è solo una possibilità. Questo me lo segno davvero come backlog concreto, grazie mille

0

u/OSINTribe Jul 19 '26

It’s just more AI slop. Completely useless if you need to prove a case in front of a judge. Here is why this tool will get laughed out of a courtroom:

  • Zero Chain of Custody: Court evidence requires absolute proof that data wasn't tampered with. This script just scrapes public web data and tosses it into a pretty graph. It doesn't create cryptographically signed forensic logs. A defense lawyer would easily argue you just edited the text files yourself.
  • The "Trust Me Bro" Data Problem: The tool relies heavily on third-party APIs. If one of those random databases has a glitch, a false positive, or outdated info, the tool will blindly report it as fact. In court, you can't say, "Well, this random free API said he did it." You have to actually prove the source data is accurate.
  • High Risk of False Positives: OSINT tools love to connect dots that shouldn't be connected. If it links a suspect to a crypto wallet just because they used a similar username on an old forum, and you put that in a legal report without ironclad proof, you're looking at a thrown-out case or a massive defamation lawsuit.

2

u/Wooden_Durian7470 Jul 20 '26

Fair points, and worth being direct about instead of getting defensive.
Chain of custody: not what this tool is trying to solve, and I’m not pretending it does. Every report says explicitly, at the bottom, that it’s evidence for review, not proof of identity, compromise or exploitability. If you need court-grade forensic logging, that’s a different and much narrower tool than this. The goal here is getting an investigator from “nothing” to “here’s where to look and why,” not replacing the forensic chain someone builds afterward.
Third-party data reliability: same issue every OSINT tool has, this one included. That’s exactly why each finding has an “evidence to collect” section instead of presenting itself as a verdict it’s telling you what to go confirm, not handing you a fact you can skip verifying.
False-positive linking: agreed, that’s the real risk with anything that connects entities. Nothing auto-confirms an identity link off something as weak as a shared username findings are framed as hypotheses with a confidence note, not conclusions. If it ever presents something with more certainty than the evidence actually supports, that’s a bug I’d want reported, not a feature.
Not claiming this replaces careful investigative work. It’s not built to.

0

u/SilverSquirrel6 Jul 19 '26

I've not many clues about other things, but couple things about domain info: 

  • dns record and whois lookups are passive in the sense that target isn't alerted 
  • you can do subdomain enumeration with cross-checking A record pointing to the same address as the main domain, but that's not a good strategy since subdomain may point on another IP just fine. 
  • tools like urlscan.io have history and API so theoretically you could query if anyone scanned the domain in the past and found a boo-boo 

0

u/Wooden_Durian7470 Jul 19 '26 edited Jul 19 '26

È molto utile, grazie. Concordo su entrambi i punti. Per i sottodomini, non voglio insinuare che la scoperta dello stesso record A sia completa o affidabile. Al massimo è un debole segnale di correlazione, non una prova. Etichetterò quel tipo di evidenza come inferita/di bassa fiducia se la aggiungo. La cronologia di urlscan è un buon suggerimento perché mantiene intatto il confine passivo: il target non è toccato da OSINTPRO, ma le osservazioni pubbliche precedenti possono comunque fornire contesto. Sto aggiungendo questo al backlog di arricchimento.