What Is OSINT? Open-Source Intelligence for Beginners

OSINT stands for open-source intelligence. It is a method. You collect information from sources you can access lawfully, usually because they are public, and then analyze that information to answer one specific question. It is not a single program, and it is not the same as typing a person's name into a search box.

A useful OSINT result says what you found, where it came from, when you saw it, what you could verify, and what is still uncertain. Tools help with collection. Most of the work is judging the sources.

#What counts as an open source?

In security work, public sources include vendor advisories, DNS records, certificate transparency logs, a company's public code repositories, archived web pages, and published documentation. Being public does not mean you may use something however you like. Laws, terms of service, privacy rights, and any written permission you hold still apply.

The most common beginner use is defensive. You might list the domains your company owns, confirm whether a published advisory covers a product version you run, or record how a public website's technology changed over several months.

#OSINT and reconnaissance

Reconnaissance is the phase where an assessor learns about a target before testing it. OSINT often supplies the passive part of that phase. The two overlap, but they are separate ideas. Reconnaissance can include active steps, such as sending traffic to a server. OSINT can also serve research that has nothing to do with security.

For beginners, the line to learn is the one between passive and active collection. Reading a certificate transparency log is passive: you query records that someone already published. Scanning a server's ports is active: you send new traffic to a system and it responds. Only active work touches the target, so it needs written permission for any system you do not own.

#A beginner workflow

1. Write the question and the scope before you search. For example: "Which public subdomains belong to a domain I operate?"
2. Collect from sources that can answer that question, such as DNS records or certificate transparency logs. Record the URL, the time you looked, the query, and the raw result.
3. Validate each result. Check that the name is current and really belongs to the organization. Old certificates, parked domains, and unrelated names create false positives.
4. Analyze by grouping results by type and confidence. A name in a log is a lead. It does not show that a service is online or vulnerable. That is a separate claim, and it needs its own evidence.
5. Report the answer with sources, and label every assumption. Leave out personal data and infrastructure details the reader does not need.

#Your first exercise

Use a domain you own, or a domain reserved for documentation. RFC 2606 reserves example.com for that purpose, so a lookup against it touches no one's real infrastructure. Run a DNS lookup:

nslookup example.com

We ran this on a Windows 11 machine. The output looked like this:

Não é resposta autoritativa:
Servidor:  dns.google
Address:  8.8.8.8

Nome:    example.com
Addresses:  2606:4700:10::ac42:93f3
	  2606:4700:10::6814:179a
	  172.66.147.243
	  104.20.23.154

The labels are in Portuguese because that Windows install uses that language, and the order of the addresses can change between runs. The addresses may change too, and that is the point of the exercise. One lookup is a snapshot from one resolver at one moment, so write down when you ran it and which resolver answered.

Next, find a second, independent source. Certificate transparency logs are public, append-only records of issued certificates, described in RFC 6962. Search one through a public index and note the time of your observation. Then fill in this five-line report:

Research question:
Scope / permission:
Source 1 (URL + accessed date):
Source 2 (URL + accessed date):
Finding / confidence / uncertainty:

This habit separates three things: the claim, the evidence, and your interpretation. Weak OSINT reports blur all three together.

#Which tools to learn first

Start with a browser, a DNS lookup tool, and a notes file that records timestamps. Those three cover most beginner questions.

When you move on to asset mapping, look at OWASP Amass. The project describes itself as performing network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques. Read its options before you run it, and point it only at domains you own or have written permission to test.

A tool's output is a lead, not proof. An AI summary of that output is a second lead.

#Where AI fits

A language model can normalize a table of records, draft an outline for your report, suggest verification questions, or explain a term such as a wildcard DNS record. It can also be wrong. Never let a model invent a citation for a record it did not examine. Check every claim against the source it names.

If you send any data to a model API, send only what you are allowed to process, and keep the source URLs attached to each claim. That includes the NotHoly API. Practice in a lab you own.

#Common mistakes

Searching before writing the question, so the search drifts toward whatever looks interesting. Saving a link without a date, even though pages change. Treating a screenshot as proof, when the original page is what you need to keep. Matching a name to a person without independent evidence, since many people share the same name. Publishing personal data that the question never needed.

Keep each claim, its evidence, and your interpretation on separate lines. At the start, that habit matters more than any particular tool.