osint.sh

What is OSINT.SH?

OSINT.SH is a browser-based collection of reconnaissance and information-gathering tools, grouped into network, website, and "others" categories. It is aimed at people doing OSINT, bug bounty recon, or security assessments who want quick lookups without installing separate utilities for each task.

What it covers

Network and DNS

• Subdomain Finder for enumerating subdomains
• DNS Lookup and DNS History for current and past records
• Reverse IP, Reverse Name Server, and Reverse MX Record to find other domains sharing an IP, nameserver, or mail server
• NMAP Scanner for port scanning

Website and domain research

• Technology Lookup for identifying a site's stack
• Certificate Search for finding assets via SSL certificate data
• Public Buckets for locating exposed AWS S3 and Azure Blob storage by keyword
• Reverse Google Analytics and Reverse Google AdSense to find domains sharing the same tracking IDs
• Whois History and Reverse Whois for ownership and historical registration data
• Reverse Domain to find domains matching a keyword

Utilities

• SSL Checker, IP GEO Location Lookup, OCR Text Extractor, Guess MD5 Hash, plus Poodle and Heartbleed checks

How it fits a workflow

A typical use: you have one domain and want to widen the picture. Run Subdomain Finder, then Reverse IP on the resolved address, then Reverse Google Analytics on the site's tracking ID. Each result becomes a new seed for the next lookup. For a bug bounty hunter, that chain often surfaces forgotten staging hosts or sibling domains that share infrastructure.

The trade-off is the usual one for aggregated web tools: convenience and a single interface, versus depth and rate limits. Purpose-built or command-line equivalents generally give more control and scripting options, while this kind of site is faster for a first pass or when you are on a machine where you cannot install anything.

Next step

Start with DNS Lookup and Subdomain Finder on your target, then pivot using Reverse IP or Reverse Google Analytics on whatever you find. For broader context on the discipline itself, see OSINT Framework.

How do I use OSINT.SH for subdomain discovery during a bug bounty reconnaissance?

Start with the OSINT.SH Subdomain Finder, then pivot to DNS History and Certificate Search to catch names the first pass misses. Those three tools work on different data sources, so running only one gives you an incomplete picture of the target's attack surface.

A practical recon flow

1. Subdomain Finder — enter the root domain (e.g. example.com). This is your baseline list of live-ish hostnames.
2. DNS History — look up the same domain. Historical records often reveal hosts that existed before a migration or were retired but still resolve internally or on forgotten infrastructure.
3. Certificate Search — search the domain to pull hostnames embedded in SSL certificates. Wildcard and SAN certificates frequently expose staging, admin or partner subdomains that never appear in current DNS.
4. Reverse IP — take an interesting IP from your results and reverse it to find other domains hosted on the same server. Shared hosting and misconfigured virtual hosts are common bug bounty findings.
5. DNS Lookup — confirm which records are live now, so you can separate active hosts from stale ones before scanning.

What each tool is actually good for

How to triage the output

Deduplicate everything into one list, then prioritise hosts that look like dev, staging, internal, admin, api or jenkins. Those names suggest weaker controls than the production site. Resolve each one with DNS Lookup and note which return live A records.

Once you have a shortlist, the related tools on the same site extend the workflow: Technology Lookup tells you what stack a host runs, Public Buckets checks for exposed cloud storage, and Whois History and Reverse Whois help map ownership across domains. For broader infrastructure mapping, Shodan and crt.sh are well-known complements, though the certificate data overlaps with what OSINT.SH already provides.

As a rule, treat any single tool's list as a starting point, not a result. The value in bug bounty recon comes from correlating sources: a hostname that appears in DNS history and on a certificate and shares an IP with another domain is worth far more attention than one that shows up once.

What steps should I take to find public AWS S3 and Azure Blob buckets using OSINT.SH?

Use OSINT.SH's Public Buckets tool as a keyword-driven search: you supply a keyword (a company name, product name, or brand fragment), and it looks for matching AWS S3 and Azure Blob storage containers. It is a discovery aid, not a guarantee — a keyword search finds buckets whose names contain that term, so your results depend heavily on how well you guess naming conventions.

A practical workflow

1. Collect candidate keywords first. Pull terms from the target's website copy, job postings, GitHub org names, mobile app strings, and subdomain labels. Bucket names often mirror internal project or environment names (acme-prod-assets, acme-backups).
2. Run each keyword separately. Broad terms return noise; short, distinctive tokens (a coined product name) return cleaner hits. Try variants: hyphenated, concatenated, and with suffixes like -dev, -staging, -backup, -logs.
3. Triage what comes back. For each hit, note whether it is publicly listable, whether objects are readable, and whether the content is sensitive. A bucket that resolves but denies listing is a different finding from one exposing files.
4. Cross-check with adjacent tools. OSINT.SH's Subdomain Finder, Certificate Search, and Technology Lookup can surface hostnames and asset names that feed better keywords back into the bucket search.
5. Document and stop there. Record the bucket URL, hostname, and observed exposure. Do not download, modify, or delete anything — unauthorized access or tampering can create legal exposure for you.

Where this fits

This kind of reconnaissance suits bug bounty hunters, penetration testers working under a defined scope, and security teams auditing their own cloud footprint. If you are testing someone else's assets, confirm the program scope and its rules on cloud storage before you probe. For general cloud-security background, the official documentation at Amazon Web Services and Microsoft covers S3 and Blob access controls, though neither replaces the scope rules of the engagement you are on.

A useful decision criterion: if a keyword returns dozens of unrelated buckets, tighten the keyword rather than widening the scan. Precision beats volume here, because every hit you cannot attribute to the target costs review time.

How can I investigate the technology stack and SSL certificate details of a target website with OSINT.SH?

Use two separate OSINT.SH modules for these jobs: Technology Lookup for the stack, and Certificate Search for SSL certificate data. They answer different questions and are best run in sequence rather than treated as one scan.

Investigating the technology stack

Technology Lookup is described as a technology stack checker: you supply a website and it reports the technologies it detects on it. In practice, that means a single lookup gives you a starting inventory of frameworks, CMS, analytics and similar components, which you can then verify manually.

A realistic workflow for a bug bounty or pre-engagement recon pass:

1. Run Technology Lookup on the primary domain and note every detected component.
2. Cross-check version claims by hand — open the page source, response headers and any public asset paths.
3. Pivot to Reverse Google Analytics and Reverse Google Adsense to find other domains sharing the same tracking IDs, which often exposes staging or sibling sites running the same stack.
4. Use Public Buckets if the stack suggests cloud storage, to check for exposed AWS S3 or Azure Blob containers tied to a keyword.

The trade-off: fingerprinting is inference, not proof. A detected framework may be outdated, patched, or only present on a cached page. Treat the output as leads for manual confirmation, not as an authoritative inventory.

Reading SSL certificate details

Certificate Search is the module for "finding information about the target assets from their SSL certificate." Certificates are useful because they frequently list hostnames the organisation did not intend to publish — SAN entries, internal naming patterns, and legacy subdomains.

Pair it with the DNS-oriented tools:

Certificate Search and SSL Checker are not the same thing. The first is reconnaissance — extracting names and assets from certificate records. The second is validation — confirming the certificate on a live server is properly installed and trusted. If your goal is attack surface mapping, start with Certificate Search; if you are auditing a deployment, use SSL Checker.

A concrete example

Suppose you are scoping an engagement against example.com. Run Certificate Search first and collect every hostname in the certificate transparency records. Feed those hostnames into DNS Lookup to see which are live, then run Technology Lookup on each live host. You will often find that a forgotten subdomain runs an older stack than the main site — a far more productive finding than the primary domain. Finish with Reverse Whois and Whois History to see whether the domain ownership records changed recently, which can indicate a transfer or acquisition worth understanding before you report.

For broader context on the discipline, OSINT Framework organises tooling by category, and Shodan covers internet-facing service discovery that complements certificate and DNS recon.

What methods does OSINT.SH offer to uncover related domains through shared identifiers like Google Analytics, AdSense, or WHOIS records?

OSINT.SH groups these techniques under "reverse" lookups: instead of starting from a domain and listing its details, you start from a shared identifier and ask which other domains use it. The site's page_evidence lists four relevant tools.

The shared-identifier lookups

Two related tools extend the same idea beyond identifiers: Reverse MX Record finds domains using the same mail server, and Reverse IP finds all A records pointing to a given IP address.

How to use them together

A practical workflow: run OSINT.SH Reverse Google Analytics or Reverse AdSense on the tracking ID from one site you already know, then pivot to Reverse Whois on the registrant email those results expose, and finally check Reverse Name Server to see whether the hosting footprint matches. Each pivot is a hypothesis — shared infrastructure can mean common ownership, but it can also mean a shared agency, a reseller, or a CDN. Treat overlap as a lead to corroborate, not proof.

Choosing between them

Analytics and AdSense IDs are the strongest signals because they are tied to a specific account holder and are hard to share accidentally. WHOIS email is useful but often redacted or a privacy proxy. Name servers and MX records are the weakest, since large hosting and mail providers serve thousands of unrelated customers. If you need the most reliable starting point, begin with a tracking ID; use the others to widen the net afterward.

For related certificate and historical records on the same site, see Certificate Search, DNS History, and Whois History.

How does the OSINT.SH API allow me to automate information gathering tasks?

OSINT.SH presents itself as a collection of information-gathering tools, and its API is the part meant for automation: instead of running each lookup by hand in the browser, you send a request from a script and get the result back for storage, comparison or alerting.

What the API is for

The site's toolset covers network and domain reconnaissance — subdomain discovery, DNS lookup and DNS history, reverse IP, reverse name server, reverse MX, certificate search, technology lookup, reverse Google Analytics and AdSense, WHOIS history, reverse WHOIS, reverse domain search, SSL checking, IP geolocation, public-bucket search and an OCR text extractor. An API in this context is the programmatic route to those same lookups, so the practical use is chaining them: one lookup's output becomes the next lookup's input without a human copying values between pages.

Typical automation patterns

• Scheduled discovery: run subdomain, certificate and DNS-history checks on a fixed schedule and diff the results, so you see new hosts rather than re-reading the same list.
• Pivot chains: resolve an IP, then run reverse IP to find co-hosted domains; take a mail server from MX records and run reverse MX to find other domains using it.
• Asset correlation: use certificate search and reverse Analytics/AdSense IDs to group domains that appear related to one organisation.
• Enrichment in a pipeline: feed an IP into geolocation or an image/PDF into the OCR extractor as a step inside a larger workflow.

What to check before you build on it

This is the deciding factor rather than any single feature. Confirm the current request format, authentication method, rate limits, response format (JSON or otherwise) and any usage or licensing terms on the site's own API and Terms of Service pages — those pages, not the marketing copy, define what you can automate and how often. Free community tools of this kind commonly impose per-key quotas or fair-use limits, so design for throttling and retries from the start.

A concrete scenario: a small security team wants a weekly report of new subdomains for a set of owned domains. A script calls the subdomain and DNS-history tools for each domain, stores results, compares against last week's snapshot and posts only the additions. If the API returns structured data and the limits allow a weekly batch of that size, this replaces hours of manual clicking; if limits are tight, keep the API for the highest-value pivots and do the rest interactively.

For background on the underlying techniques, see OWASP on reconnaissance and MITRE for how external asset data feeds threat intelligence.