OSINT on yourself: your external attack surface for free

The first three parts of this series pointed OSINT at strangers: an unknown IP, a reported link, a suspicious file. This part points the same tools at your own organization. Before anyone targets you, they look you up — which subdomains have certificates, which services answer on your addresses, whose email appeared in a breach, which lookalike domains are free to register. Every one of those lookups is free, and you can run them first.

The result is a list of things you did not know were public: a staging server with a certificate that names it, a VPN appliance two firmware versions behind, a mailbox that appeared in a breach under a password someone may still use.

This is the last part of the OSINT series. Part one has the ground rules; parts two, three and four cover the tools for IPs, domains and files.

Scope: what is yours, and what is passive

Two rules keep this exercise on the right side of the line.

Only your own assets. Domains you have registered, address space allocated to you, accounts in your tenant. A cloud or hosting provider’s infrastructure is not yours even when your site runs on it.
Passive sources only. Everything below reads databases that others built. Actively scanning, even your own public addresses, belongs in a planned test with written approval, notice to your providers where their terms require it, and someone ready to answer when the firewall alerts.

Write down the starting list before you begin: every registered domain (check the registrar account, not memory), every public IP range, and the cloud tenants your organization uses. The gaps in that list are often the first finding.

Host names you published without meaning to

Certificate transparency logs record every publicly trusted TLS certificate, and every name on it. That makes them the best free subdomain inventory there is — and a leak of names your organization never meant to publish. Search all of your domains on crt.sh:

https://crt.sh/?q=%25.corp.example&output=json

Pull the unique names out of the JSON:

curl -s 'https://crt.sh/?q=%25.corp.example&output=json' \
  | jq -r '.[].name_value' | tr '[:upper:]' '[:lower:]' | sort -u

Read the list for:

Names that reveal internal structure: vpn, citrix, owa, adfs, jenkins, grafana, dev, staging, test. Each tells an attacker what to try next.
Names nobody recognizes. A certificate issued means someone stood up a service. Find out who and whether it still runs.
Certificates you did not request. Issuance for your domain by a certificate authority you do not use deserves a call to whoever manages DNS.

Wildcard certificates (*.corp.example) hide individual names in the logs. That is a reasonable choice for internal host names; the trade-off is that one stolen private key covers every host.

Services the internet can see

Internet scanning services already know which of your addresses answer and what they run. Shodan and Censys are the two with useful free access.

Shodan. Host pages for individual addresses show open ports, service banners, TLS certificates and when each was seen. Searches that use filters — such as net:198.51.100.0/24 for your range or ssl.cert.subject.cn:corp.example for your certificates — consume query credits, per Shodan’s credit documentation. The one-time Membership ($49) adds 100 query credits per month and Shodan Monitor for 16 IPs, which alerts when something new appears on those addresses. For a small organization, that is a continuous external watch for a one-time fee.
Censys. The free tier gives 100 credits per month in the web interface, no API. A direct host lookup costs one credit, so checking a dozen addresses monthly fits; broad searches do not.

What to look for:

Finding	Why it matters
Remote access on the internet: RDP (3389), SSH (22), VNC, Telnet	Constant brute-force targets. RDP in particular should sit behind a VPN or gateway.
Management interfaces: firewall, hypervisor, storage, printer web UIs	Rarely meant to be public, often unpatched.
VPN and remote-access appliances with a visible version	Edge appliances are a recurring initial-access route. Compare the version with the vendor’s advisories.
Databases and caches: 1433, 3306, 5432, 6379, 9200, 27017	Should essentially never be internet-facing.
Services on addresses you did not know you had	The inventory is wrong, which is a bigger problem than the port.

Remember that scan data is a snapshot from the last time the scanner passed by. Verify a finding from your own firewall configuration before acting on it, and recheck after you fix it.

Breached accounts

Have I Been Pwned can list every address on your domain that appears in its breach corpus, once you prove you control the domain. According to its support pages, domain searches are free when the domain has up to 10 breached addresses; larger totals need a paid subscription. Breach notifications for a verified domain are free regardless of size.

What to do with the results:

Map addresses to current accounts. Many will belong to people who left years ago. Make sure those accounts are disabled, not just unlicensed.
Look at which breaches. A breach that included plaintext or weakly hashed passwords is a credential-stuffing risk for anyone who reused that password at work. How long should a passphrase be? covers why the hash format matters.
Check for shared and service mailboxes. info@, invoices@ or a service account registered on a third-party site that was breached is easy to miss and often has a shared password.

Do not ask users for their old passwords or test them against your systems. Enforce multi-factor authentication and a banned-password list, and let the breach list guide where you check first.

Lookalike domains

Typosquats and lookalikes of your domain are the raw material for phishing aimed at your users and your customers. dnstwist generates permutations of a domain and shows the registered ones:

dnstwist --registered --mxcheck corp.example

For each registered lookalike, note who registered it and when (RDAP, see part three), whether it has MX records (it can receive email meant for you), and whether its website imitates yours. Some will be harmless — parked domains, unrelated businesses, your own defensive registrations. The rest go on a watch list, and the worst into a takedown request through the registrar’s abuse contact.

dnstwist resolves every permutation it generates, so it does make DNS queries to other people’s name servers. Run it from a machine outside your corporate network, or use the web version at dnstwist.it.

Your email domain’s defenses

While you are looking at your domains from the outside, check whether someone else can send email as you. These are lookups of your own public DNS records:

dig +short TXT corp.example | grep -i spf
dig +short TXT _dmarc.corp.example

No SPF record, or one ending in +all, means any server may claim to send for you.
No DMARC record, or p=none indefinitely, means receivers are told not to act on failures. p=none is a starting point for collecting reports, not a destination.
Domains you own but never send from should publish v=spf1 -all and a DMARC policy of p=reject, so nobody can use them for spoofing.

Code and documents in public

Organizations leak through their own repositories and file shares more than through their firewalls. Two passive checks:

Public code search. Search GitHub (code search requires being signed in) and other public code hosts for your domain names, internal host names from the crt.sh list, and distinctive internal project names. Configuration files with connection strings, tokens or internal addresses turn up more often than anyone expects.
Search engines. A site:corp.example search restricted to document types (filetype:pdf, filetype:xlsx) shows what your own websites publish. Check the documents’ metadata too: author names and internal paths are a gift to a phishing campaign.

Any secret you find in public is compromised, even if you delete it. Rotate it first, then remove it.

Make it a routine

A one-off look finds the backlog. The value comes from repeating it:

Check	How often
crt.sh for all your domains	Monthly, or continuously with a CT monitoring service
Shodan / Censys for your ranges	Monthly, or continuously with Shodan Monitor
Have I Been Pwned domain notifications	Continuous (free)
dnstwist on your domains	Monthly
SPF and DMARC	After every mail platform change, and quarterly
Public code search	Quarterly

Record each finding with a date, an owner and what was done about it. A short spreadsheet is enough; what matters is that the next run compares against it instead of starting over. The same inventory discipline applies inside the network — see Which logs do you actually have?.

Limitations

Passive data is always behind. A service exposed this morning may not appear in any scanner until next week.
Certificate logs show only names on publicly trusted certificates. Internal CAs, plain HTTP and wildcard certificates leave gaps.
Breach data covers known, published breaches. Credentials stolen by infostealer malware and sold privately are a growing source of account takeover and will not appear here.
None of this replaces an authorized external penetration test. It shows what is visible, not what is exploitable.

Adapting this to your environment

ADAPT the starting list to every domain and range you own, including acquisitions, marketing microsites and domains held only for email.
ADAPT the cadence to how fast your environment changes: a team that deploys weekly needs continuous CT and port monitoring, not a monthly look.
ADAPT ownership: each finding type needs a named owner (DNS, network, identity, development) before the first run, or the list will just grow.

That closes the series. If a tool here changed its terms, or you rely on one we did not cover, write to hello@entropywatch.dev.