OSINT for defenders: the ground rules before the tools
An alert fires on an outbound connection to an address nobody recognizes. A user forwards an email with a link that “looks off”. A file turns up in a temp folder with a name like invoice_0921.exe. In each case the first question is the same: what does the rest of the internet already know about this thing? Open-source intelligence (OSINT) answers that question for free, often in a few minutes.
“Best free OSINT tools” lists usually stop at a long list of links. The tools matter less than how you use them: some lookups are invisible to anyone, some hand your data to a vendor’s paying customers, and a few tell the attacker that you have found them. This article sets the ground rules. The next four parts of the series go through the tools for one kind of indicator each.
What we mean by defensive OSINT
In this series, OSINT means using public data to answer defensive questions:
- Enrichment during triage. Who owns this IP address, has anyone reported it, is it a known scanner or a cloud service?
- Investigation. When was this domain registered, what else is hosted with it, what did the page look like when the user clicked?
- Self-assessment. What does the internet see when it looks at your organization: exposed services, certificates that list internal host names, breached email addresses, lookalike domains?
It does not mean researching people. Profiling individuals, finding home addresses or mapping someone’s social accounts is a different discipline with different legal and ethical rules, and it is out of scope here.
Passive, semi-passive and active lookups
Every lookup sits somewhere on a scale of how much it touches the thing you are investigating. Know where a tool sits before you use it.
| Type | What happens | Examples |
|---|---|---|
| Passive | You query a database someone else built. Nothing reaches the indicator’s infrastructure. | Searching a hash on VirusTotal, an IP on AbuseIPDB, a domain in certificate transparency logs |
| Semi-passive | A third party touches the infrastructure for you, from its own addresses. | Submitting a URL to urlscan.io or a file to a public sandbox |
| Active | Your own systems touch the infrastructure. | Opening the URL in a browser, ping, curl, a port scan |
Passive lookups are the default. Semi-passive ones are fine when you have thought about what you are sharing (next section). Active lookups from your corporate network are almost never needed for triage: they put your egress IP in the attacker’s logs, may trigger the payload, and can confirm to a phishing operator that the lure reached a real target. If you must look, do it from an isolated analysis machine with its own internet connection, never from the network you are defending.
Every submission is a disclosure
The free tiers of most OSINT services are paid for with data. What you submit is usually shared, and the terms say so.
- VirusTotal. Searching for a hash shares nothing new. Uploading a file is different: VirusTotal’s How it works page states that the contents of submitted files “may also be shared with premium VirusTotal customers”, and the Terms of Service ask you to upload only samples you are willing to share publicly and not to submit confidential or personal data without permission. A contract with a malicious macro is still a contract.
- urlscan.io. Scans have three visibility levels: public (listed on the front page and in search), unlisted (hidden from public search but visible to vetted urlscan Pro customers) and private (only you and people you share the scan with). A password-reset link or a SharePoint URL with a sharing token, scanned as public, is readable by anyone.
- Public sandboxes. Free sandbox plans are often public by design. ANY.RUN’s plans page lists private analyses only for paid tiers, so assume a free-plan analysis can be seen by others.
There is a second reason not to upload by reflex. A sample built for your organization, uploaded to a public service, can tell its author that you found it: people who write targeted malware can watch for their own files appearing in public repositories. A hash search does not disclose who searched. An upload is a public event.
The rule we follow: search first, submit only when the search comes back empty, and never submit anything that contains your own data — documents, internal URLs with tokens, emails with recipient addresses.
Handle indicators so nobody clicks them
Indicators travel through tickets, chat and email, and every one of those renders links. Defang them before you paste them anywhere:
| Raw | Defanged |
|---|---|
https://login-portal.example/reset |
hxxps://login-portal[.]example/reset |
203.0.113.45 |
203.0.113[.]45 |
user@phish.example |
user[@]phish[.]example |
CyberChef has Defang URL and Defang IP Addresses operations and runs entirely in the browser. The page can also be downloaded and run offline, which is the version to use for anything sensitive.
A five-minute triage workflow
For a single unknown indicator during an alert, this order keeps lookups passive for as long as possible:
- Write down the question. “Is this IP malicious?” is too vague. “Is this a known scanner, a cloud service our users talk to, or a reported attacker?” tells you which tool to open.
- Check your own data first. Your SIEM knows things no OSINT service does: how many hosts talked to this address, since when, and how much data moved. The article Which logs do you actually have? covers making sure those logs exist.
- Run passive lookups. Ownership (RDAP, ASN), reputation (abuse reports, scanner databases) and history (certificates, earlier scans).
- Decide whether you need more. Most triage ends here: the address belongs to a CDN, or the domain was registered yesterday and is already on three blocklists.
- Only then, semi-passive. Submit the URL as a private or unlisted scan, or detonate a file in a sandbox whose visibility rules you have checked.
- Record what you found and where. Note each source and the time of the lookup. Reputation changes, and the verdict that was right at 09:00 may be wrong by Friday.
Free tiers have terms, not just limits
Free plans come with rate limits, and some come with conditions that matter more. VirusTotal’s public API allows 500 requests per day at four per minute and “must not be used in commercial products or services”. GreyNoise does not issue Community API keys to accounts registered with free email providers. Several services forbid using a free account inside an automated business workflow.
For an analyst checking a handful of indicators by hand, none of this is a problem. For a SOAR playbook that enriches every alert, it is: read the terms before you wire a free API into production, and budget for a paid tier or a service that allows it.
The rest of this series
Each part covers one indicator type, with the free tools we would reach for, what each one is good at and what it leaks:
- OSINT for defenders: the ground rules (this article)
- Enriching an IP address with free tools — ownership, abuse reports, scanner noise and exposed services
- Investigating a domain or URL with free tools — RDAP, certificate transparency, page scans and blocklists
- Checking a file hash without leaking the file — malware repositories, sandboxes and what an upload costs you
- OSINT on yourself — your own external attack surface, found with the same free tools
All tool limits and terms in the series come from vendor documentation as of October 2026. They change often; every figure links to its source so you can check it on the day you rely on it.
Limitations
- OSINT tells you what others have seen. An empty result is not a clean bill of health: targeted infrastructure is often new and unreported.
- Reputation data is noisy. Shared hosting, cloud addresses and CDNs carry reports that have nothing to do with your alert.
- Free tools change ownership, limits and terms without notice. Keep two sources for every question so one disappearing does not stop your triage.
If you think something here is wrong or out of date, write to hello@entropywatch.dev and we will correct it in the open.