Most OSINT work fails not because of a lack of tools, but because of a lack of structure. You can have access to every data source on the internet and still produce nothing useful if you do not have a methodology driving the collection.

This post outlines the framework I use for OSINT investigations. It is not the only approach, but it is one that has been refined through real-world engagements and scales from quick reconnaissance to deep-dive investigations.

The Problem with Tool-First Thinking

The security community has a habit of equating OSINT with tools. Someone asks how to get started with OSINT and the answer is invariably a list: Maltego, Shodan, SpiderFoot, theHarvester, and so on.

Tools are important. But a tool without a framework is just noise generation. You will collect data, not intelligence. There is a critical difference between the two.

Data is raw information. A list of subdomains. A collection of email addresses. A dump of social media posts.

Intelligence is data that has been analyzed, correlated, and placed in context to answer a specific question.

The goal of OSINT is intelligence, not data.

The Framework

I break OSINT work into five phases. This is not revolutionary; it maps loosely to the intelligence cycle used by military and government agencies, but the specifics matter.

Phase 1: Define the Objective

Before you touch a keyboard, answer one question: What am I trying to find out?

This sounds obvious. It is not. I have watched experienced analysts spend hours collecting data with no clear objective, then struggle to produce findings because they never defined what “findings” meant.

Good objectives are specific and bounded:

  • Identify the external attack surface of target organization X
  • Determine the key personnel in department Y and their digital footprint
  • Map the technology stack used by target application Z

Bad objectives are vague and open-ended:

  • “Find everything about Company X”
  • “Do OSINT on this person”
  • “See what’s out there”

Write the objective down. Refer back to it constantly. If you find yourself going down a rabbit hole, check whether it serves the objective.

Phase 2: Source Identification

With a clear objective, identify which sources are most likely to contain the information you need. Not all sources are created equal and time is always limited.

For organizational reconnaissance, I typically prioritize:

  1. DNS and infrastructure data: passive DNS, certificate transparency logs, WHOIS records
  2. Public code repositories: GitHub, GitLab, Bitbucket (search for the organization name, domain, internal tooling)
  3. Job postings: these reveal technology stacks, team structures, and internal projects
  4. Social media: LinkedIn for personnel and org structure, Twitter for informal disclosures
  5. Document metadata: PDFs, Office documents published on the target’s website
  6. Cached and archived content: Wayback Machine, Google cache, cached search results

The key is to match sources to objectives. If you are mapping an external attack surface, job postings are lower priority. If you are profiling an individual, DNS data is probably irrelevant.

Phase 3: Collection

Now you collect. This is where tools become relevant, but they serve the methodology, not the other way around.

A few principles I follow during collection:

Document everything. Every query, every source, every timestamp. You need to be able to reproduce your findings and explain your methodology. I keep a running log in a simple text file:

2026-02-06 09:15 - crt.sh query for %.target.com - 47 results
2026-02-06 09:22 - GitHub search "target.com" - 12 repositories found
2026-02-06 09:30 - LinkedIn search, engineering department - 23 profiles identified

Work in layers. Start broad, then narrow. Initial collection identifies areas of interest. Follow-up collection goes deep on those areas.

Respect scope. This is especially important in professional engagements. If the scope says passive only, stay passive. If the scope covers only a specific domain, do not pivot to personal accounts of employees. Scope discipline is not optional.

Phase 4: Analysis

Collection without analysis is just hoarding. This phase is where you turn data into intelligence.

Techniques I use regularly:

  • Correlation: Does the same email address appear across multiple platforms? Does a username pattern repeat?
  • Timeline construction: When were things published, modified, or removed? Timelines reveal patterns.
  • Link analysis: How do entities connect to each other? An employee’s GitHub commits might link to an internal tool name that appears in a job posting.
  • Gap analysis: What is missing? Sometimes the absence of expected data is more interesting than its presence.

This is the phase that separates good analysts from average ones. The tools can collect. Analysis requires a human who understands context.

Phase 5: Reporting

Intelligence that is not communicated is useless. The output format depends on the audience:

  • Technical audience: detailed findings with evidence, structured data, raw indicators
  • Executive audience: risk-focused summary, key findings, recommendations
  • Red team integration: actionable targeting data, attack paths identified, credentials or access vectors discovered

Regardless of audience, every finding should be traceable back to a source and a methodology step. “I found this email address” is not a finding. “This email address was identified via certificate transparency log analysis of *.target.com and confirmed active through LinkedIn profile correlation” is a finding.

Tooling That Supports the Framework

With the methodology in place, here are the tools I reach for most often, mapped to the phases where they are most useful:

Source Identification & Collection:
  - crt.sh, Censys, Shodan  → Infrastructure
  - GitHub/GitLab search     → Code repositories
  - theHarvester             → Email and subdomain enumeration
  - Wayback Machine          → Historical content

Analysis:
  - Maltego                  → Link analysis and visualization
  - Custom scripts           → Data normalization and correlation
  - Spreadsheets             → Timeline construction (simple but effective)

Reporting:
  - Markdown + static site   → Structured reports
  - Custom templates         → Client deliverables

The tools change. The methodology does not. That is the point.

Final Thought

OSINT is not a tool. It is not a Google search. It is a discipline, and like any discipline, it requires structure, patience, and the ability to think critically about what you are finding and why it matters.

Build your framework first. The tools will follow.