Skip to content
Category: Pentest8 min read

OSINT and Recon for Defenders: Map Your Own Attack Surface

Por Lucas Andrade ·

How attackers profile you with OSINT, how to detect reconnaissance, and how to shrink your exposed attack surface with practical hardening.

In this article

Open-source intelligence (OSINT) is the practice of collecting and analyzing information that is already public: DNS records, code repositories, job postings, employee profiles, certificate transparency logs, cloud storage buckets, and countless other traces an organization leaves behind. Adversaries lean on OSINT because it is quiet, cheap, and rarely touches the target directly. For defenders the same discipline is a gift: if you look at your organization the way an outsider does, you can find the exposures before someone else weaponizes them. This article frames reconnaissance from the blue-team perspective — understanding how the profiling works so you can detect it, reduce what you leak, and continuously monitor your own footprint.

What OSINT reconnaissance actually is#

Reconnaissance is the first phase of almost every intrusion. Before touching a login form or sending a phishing email, an attacker builds a picture of the target: which domains and subdomains exist, which technologies power the web stack, who works there and in what roles, and which third parties are trusted. OSINT is the passive half of that effort. It relies on sources the organization published — deliberately or accidentally — and on aggregators that index the public internet. Because nothing is exploited yet, OSINT generates little or no traffic against your systems, which is exactly why it is hard to catch and why proactive self-assessment matters more than detection here.

How adversaries build the picture#

A typical profiling workflow starts from a single seed such as a company name or primary domain and expands outward. From the domain, an analyst enumerates DNS records and subdomains, pulls historical data from passive DNS providers, and reads certificate transparency logs, which publicly record every TLS certificate ever issued — including for internal-sounding hostnames like vpn-test or staging-admin. In parallel they harvest people: names, titles, and email patterns from professional networks, conference talks, and press releases, which reveal the email naming convention (for example first.last@company.com) and the org chart. Public code hosts are mined for leaked secrets, internal URLs, and dependency lists. Cloud storage and misconfigured object buckets are checked for readable files. The output is a map of your external surface and a target list of humans, all assembled without ever attacking you.

Your exposed attack surface#

The surface an attacker sees is broader than most teams assume. It includes forgotten subdomains pointing at decommissioned services (a classic subdomain-takeover risk), development and staging environments exposed to the internet, expired but still-resolving DNS entries, metadata embedded in published documents (author names, internal file paths, software versions), API endpoints referenced in client-side JavaScript, and technology fingerprints leaked through HTTP headers and error pages. Every one of these is a legitimate public fact — the defensive goal is not to make the internet forget, but to ensure that what is public is intentional, current, and non-sensitive.

Detection: spotting reconnaissance signals#

Passive OSINT is largely invisible, but the transition from passive to active recon — where an attacker starts probing your assets — leaves telemetry you can catch. Watch web and WAF logs for enumeration patterns: bursts of 404s across guessed paths, requests for common admin or backup files, and directory-brute-force user agents. Monitor DNS query logs for rapid subdomain guessing against your authoritative servers. Set up certificate transparency monitoring so you are alerted whenever a certificate is issued for a name under your domains — this catches both shadow IT and adversaries who provision look-alike domains for phishing. Deploy canary tokens: fake credentials, honeypot documents, or decoy subdomains that should never be touched; any interaction with them is a high-confidence signal. Correlate spikes in scanning from a single ASN or cloud range in your SIEM, and alert on access to endpoints that exist but are not linked anywhere.

Detection sources worth wiring up#

Concretely, feed these into your monitoring: certificate transparency feeds filtered to your registered domains; passive DNS change alerts; new-subdomain discovery from your own recurring scans; GitHub and paste-site monitoring for your domain names and internal identifiers; brand and typosquat monitoring for look-alike domains; and WAF/CDN analytics for scanning bursts. On the endpoint and network side, EDR and NDR telemetry will not usually see passive OSINT, but they are your safety net for the moment recon turns into interaction. The principle is defense in depth: you cannot detect the reading of public data, so you detect the moment that reading is put to use. It also helps to enrich these feeds with context — tag which assets are business-critical, which subdomains belong to which team, and which look-alike domains have already been reported — so that an alert arrives with enough information for an analyst to triage it quickly rather than as an isolated, ambiguous event that sits unactioned in a queue.

Mitigation and hardening#

Reducing OSINT exposure is mostly disciplined hygiene. Inventory every domain and subdomain and retire what you do not need; a smaller footprint is a smaller target. Remove DNS records that point at decommissioned resources to close subdomain-takeover paths. Keep non-production environments off the public internet or behind authentication and IP allowlists. Strip metadata from documents before publishing and standardize on templates that do not embed internal paths. Audit public code repositories for secrets and enforce pre-commit secret scanning plus server-side push protection so credentials never reach history. Generalize error pages and remove version-revealing headers to blunt technology fingerprinting. Because email conventions are trivially guessable, do not treat a valid address as any kind of secret — put the security budget into phishing-resistant authentication instead.

Reducing the human surface#

People are the richest OSINT source, and you cannot forbid employees from having public profiles. Instead, raise the cost of using that information. Train staff to recognize pretexting and targeted phishing that references real projects or colleagues. Enforce phishing-resistant multi-factor authentication (FIDO2 security keys or passkeys) so a harvested password plus a convincing lure is not enough. Limit how much operational detail appears in job postings — listing your exact security stack helps candidates and attackers equally. Establish a clear, well-known channel for reporting suspicious contact, and reward reports rather than punishing the reporter. Finally, remember that executives and privileged administrators are disproportionately targeted precisely because their public profiles are richer and their access is broader, so extend the strongest protections and the most attentive monitoring to exactly those accounts rather than treating every identity as equal.

Common pitfalls#

Teams stumble in predictable ways. They monitor production carefully while forgetting the sprawl of forgotten subdomains and old marketing microsites. They treat certificate transparency as noise instead of a free early-warning system. They scan their surface once during an audit and never again, so drift reintroduces exposures within weeks. They react to a leaked secret by deleting the file but forget to rotate the credential, leaving it valid in Git history and in attacker hands. And they conflate obscurity with security — hiding an endpoint is not protecting it. Assume everything public is already known and secure it accordingly.

Defender checklist#

Use this as a recurring routine. Maintain a live inventory of domains, subdomains, and public IP ranges. Run recurring external discovery and diff the results to catch new exposures. Subscribe to certificate transparency alerts for all your domains. Monitor code hosts and paste sites for your identifiers and rotate any exposed secret immediately. Deploy canary tokens across storage, credentials, and decoy hosts. Remove or authenticate every non-production environment. Strip document metadata and generalize error responses. Enforce phishing-resistant MFA everywhere. Run targeted phishing and pretexting awareness exercises. Review and prune public job postings and social exposure of sensitive roles. Re-run the whole cycle on a fixed schedule, because attack surface is never static.

FAQ: Is OSINT reconnaissance illegal?#

Collecting information that is publicly available is generally lawful, which is precisely why adversaries rely on it and why you cannot prevent it. What crosses legal and ethical lines is unauthorized access, exploitation, or social-engineering campaigns against your people. For defenders this reframes the goal: you are not trying to stop people from reading public data, you are trying to ensure the public data is not sensitive and to detect the moment reconnaissance turns into an attack.

FAQ: How often should we assess our own footprint?#

Continuously for high-signal sources and periodically for the full sweep. Certificate transparency, code-host, and paste-site monitoring should run in near real time because they surface fresh exposures. A comprehensive external discovery — subdomains, exposed services, metadata, cloud storage — should run at least monthly and after any major infrastructure change, since cloud environments and DNS drift quickly. Treat your attack surface as a living inventory, not a one-time report.

Conclusion#

OSINT reconnaissance is unavoidable because it uses information you already made public. The defensive answer is to look first: profile yourself the way an adversary would, shrink and curate what is exposed, wire up early-warning sources like certificate transparency and canary tokens, and detect the pivot from passive collection to active probing. Recon is quiet, but the exposures it finds are things you can fix. By turning the attacker's own methodology into a continuous self-assessment, you convert an intelligence advantage into a defensive one and make the first phase of every intrusion far less productive.

Related posts

No comments yet

Be the first to comment.

Leave a comment

Sign in with your Canverly account to comment. You can use the same account on any site in the network.

Sign in with Canverly