In 2013, researchers at the University of Cambridge published a study demonstrating that Facebook "likes" alone could predict a user's IQ, sexuality, political affiliation, and personality type with startling accuracy — all without any direct contact with the individuals studied. No surveys. No interviews. No interaction. The data had already been deposited publicly. The intelligence was simply waiting to be read.
This is the foundational logic of passive OSINT: the target has already left the evidence. The investigator's only job is synthesis.
The intelligence community distinguishes passive collection from active collection by a single criterion: does the collection method generate a signal detectable by the target? Active reconnaissance — port scans, login attempts, direct contact — creates log entries, raises intrusion alerts, and may constitute unauthorized access under statutes like the Computer Fraud and Abuse Act (CFAA) or the UK Computer Misuse Act 1990.
Passive OSINT operates exclusively on data that has already been made public, cached, indexed, or otherwise placed into open repositories. The collector generates no new network traffic to the target's infrastructure and creates no artifacts on the target's systems.
LLMs extend passive OSINT in two ways. First, they act as synthesis engines — taking fragmented public data points and constructing coherent profiles far faster than a human analyst. Second, they act as query engines — helping analysts identify what types of public data exist and how to locate them without wasting time on active enumeration.
Before LLMs, passive OSINT was labor-intensive. An analyst gathering intelligence on a corporation might spend hours collating LinkedIn profiles, parsing WHOIS records, reading annual reports, and cross-referencing job postings — before producing a single structured assessment. The data existed; the bottleneck was human synthesis speed.
LLMs collapse that bottleneck. Given a set of raw passive data — a company's LinkedIn employee list, a set of job postings, a domain's DNS records, a GitHub repository's commit history — an LLM can synthesize a structured threat profile in seconds. It can infer technology stacks from job descriptions, map organizational hierarchies from LinkedIn data, and identify likely attack surfaces without a single packet being sent.
Researchers at IBM X-Force documented this pattern in 2023, noting that generative AI was being used by threat actors to accelerate the pre-exploitation "reconnaissance phase" — specifically the synthesis of public data into actionable intelligence packages.
Accessing data that is technically public but behind authentication barriers — even weak ones — may not qualify as "passive" under law. In hiQ Labs v. LinkedIn (9th Circuit, 2022), the court debated whether scraping publicly visible LinkedIn profiles constituted unauthorized access. Always verify the legal framework governing your jurisdiction before collection.
Passive OSINT draws from six primary data categories. Understanding these categories is essential for structuring effective LLM-assisted collection workflows:
An LLM does not collect passive OSINT — it synthesizes it. The analyst's job is to understand which data categories to collect and feed to the model. The model's job is to identify patterns, connections, and inferences the analyst might miss. Human judgment governs collection scope and legal compliance; the LLM governs synthesis speed and breadth.
You are conducting a passive reconnaissance engagement for a red team assessment against a hypothetical mid-sized financial services firm. Your objective is to use the AI assistant to help you structure a passive OSINT collection plan — identifying which data categories to target, which sources to use, and what intelligence gaps might remain.
The AI will not collect data for you — it will help you think through collection methodology, legal boundaries, and synthesis priorities.
In the aftermath of the SolarWinds SUNBURST breach, post-incident analysts reconstructed much of the attacker's initial reconnaissance from public data alone. Certificate Transparency logs showed that avsvmcloud.com — the attacker-controlled C2 domain — had been registered and certificated weeks before the supply chain compromise was activated. The domain's registration patterns, ASN assignments, and DNS configurations were all visible in public logs throughout the operation. An analyst monitoring Certificate Transparency feeds for SolarWinds-adjacent infrastructure could have flagged the anomaly before the breach succeeded.
The intelligence was passive, public, and free. The bottleneck was not collection — it was synthesis at scale.
Since 2013, the CA/Browser Forum has required all publicly trusted Certificate Authorities to log every issued TLS certificate to publicly auditable Certificate Transparency (CT) logs. Tools like crt.sh, Censys, and Facebook's CT Monitor expose the complete issuance history for any domain.
For an OSINT analyst, CT logs are extraordinarily valuable because they reveal subdomains that organizations have never publicly advertised. A company might expose internal staging environments, development servers, VPN gateways, and partner portals through certificate issuance alone. Every certificate is timestamped, so the log also reveals when new infrastructure was provisioned — a timeline of infrastructure growth that is invisible to the organization's security team but public to any analyst who knows where to look.
An LLM can help analysts interpret bulk CT log exports — identifying naming conventions, clustering subdomains by likely function, and flagging subdomains that suggest sensitive internal systems based on naming patterns.
Search crt.sh/?q=%.example.com to retrieve all certificates issued for any subdomain of a target domain. The results are public, free, and require no authentication. The wildcard operator reveals subdomains that have never been linked from any public-facing page.
DNS records are public by design. They must be — without them, email couldn't be delivered and websites couldn't be reached. But the information they contain extends well beyond simple resolution. Analysts use passive DNS lookups (via services like SecurityTrails, PassiveTotal, or VirusTotal) to access historical DNS data — revealing how a domain's infrastructure has changed over time without ever querying the live nameserver.
| Record Type | Intelligence Value | Example Finding |
|---|---|---|
| A / AAAA | Hosting provider, CDN usage, IP geolocation | Target moved from on-prem to AWS in Q3 2023 |
| MX | Email provider (Google Workspace, O365, Proofpoint) | Proofpoint MX suggests email security gateway |
| TXT / SPF | Third-party SaaS services explicitly authorized to send mail | SPF includes Salesforce, HubSpot, Zendesk |
| DMARC | Email security posture (p=none = no enforcement) | p=none indicates susceptibility to spoofing |
| NS | DNS hosting provider, potential for zone transfer | Cloudflare NS indicates CDN + DDoS protection |
| CNAME | Third-party service integrations (Zendesk, HubSpot subdomains) | support.example.com → zendesk.com |
WHOIS records — though increasingly privacy-redacted under GDPR — still reveal registrar, registration date, name servers, and sometimes registrant organization details. For corporate targets, ASN (Autonomous System Number) lookups via ARIN, RIPE, or BGP.he.net reveal the IP ranges an organization owns or operates — the foundation for understanding the full scope of internet-facing infrastructure without any active scanning.
In 2019, researchers at DomainTools published analysis showing that WHOIS registration patterns — registrar selection, registration timing, privacy protection choices — could be used to cluster domains operated by the same threat actor with high confidence. The same clustering logic applies when building a passive infrastructure map of a target organization: consistent ASN ownership, registrar choices, and certificate issuance patterns create a fingerprint that LLMs can help identify and describe.
Feed an LLM a bulk export of CT log results, passive DNS history, and WHOIS records for a target domain. Prompt it to: (1) identify likely internal vs. public-facing subdomains by naming convention, (2) map the third-party service dependencies visible in DNS TXT/CNAME records, (3) assess the email security posture from DMARC/SPF configuration, and (4) flag infrastructure changes that suggest recent migrations or new projects. This synthesis takes an LLM seconds; a human analyst hours.
You've gathered the following passive domain intelligence on a fictional target, Meridian Financial Group (meridianfg.example.com). Use the AI assistant to help you interpret these findings and identify intelligence value and potential attack surface implications.
Simulated findings: CT logs show 47 subdomains including staging.meridianfg.example.com, vpn.meridianfg.example.com, and dev-api.meridianfg.example.com. SPF record includes Salesforce, Proofpoint, and Workday. DMARC policy is p=none. MX records point to Proofpoint.
The 2013 Target Corporation breach — which exposed 40 million credit card records — was enabled in part by intelligence that was publicly available before the attack. Target's job postings in 2012 and 2013 prominently listed experience with HVAC and building management system vendors as desirable qualifications for facilities contractors. Fazio Mechanical Services, the third-party HVAC contractor through which the attackers gained initial access, was publicly listed as a Target vendor on Fazio's own website and in Target's sustainability reports.
The attackers did not need to interact with Target's network to identify the entry vector. The vendor relationship was public. The network integration was implied by the job postings. The intelligence was passive — and lethal.
Job postings are arguably the richest single passive OSINT source for technology intelligence. Organizations advertising for security engineers will specify the exact tools in their stack — SIEM platforms, EDR vendors, cloud environments, IAM solutions. A posting for a "Senior DevOps Engineer" listing "proficiency with HashiCorp Vault, AWS IAM, and Terraform" reveals secrets management architecture, cloud provider, and infrastructure-as-code tooling in a single sentence.
Brian Krebs documented this methodology in a 2014 analysis of the Target breach, noting that attackers could have mapped the vendor ecosystem entirely from public-facing documents before any network interaction occurred. Security researchers at RiskIQ formalized this into a methodology they called "Outside-In" attack surface mapping — using job postings as a primary data source.
LLMs are particularly effective at processing bulk job posting exports. An analyst can feed 50 job postings into an LLM and prompt it to extract: technology stack components, cloud providers, security tools, programming languages, compliance requirements (which reveal regulatory environment), and team structure hints from reporting relationships.
Public GitHub repositories are a frequently underestimated passive intelligence source. Organizations routinely expose infrastructure details, internal tooling, and occasionally credentials through public repositories — often unintentionally. Even repositories that contain no sensitive data reveal technology choices, coding conventions, and architectural decisions that inform attack surface analysis.
In 2019, researchers at GitGuardian reported that over 4 million secrets — including API keys, database passwords, and private keys — were exposed in public GitHub commits during that year alone. The vast majority of these exposures were inadvertent: developers committing configuration files, forgetting to add .gitignore entries for credential files, or pushing personal projects that contained work infrastructure details.
An LLM can assist with GitHub intelligence in several ways: analyzing repository README files and commit messages to infer infrastructure architecture, reviewing contributor lists to map personnel to technical roles, and identifying naming patterns in repository collections that suggest internal project structures.
Public repositories retain their full commit history even after sensitive files are deleted. The git log for a public repository may contain deleted credential files, internal IP addresses, and configuration details that were exposed for hours or days before removal. Tools like truffleHog and GitLeaks automate this analysis; an LLM can help interpret findings and prioritize high-value exposures.
Large organizations frequently publish academic papers, conference talks, and patent applications describing their internal systems in detail. Google's published research on Spanner, Bigtable, and Borg gave competitors — and attackers — a detailed understanding of their internal infrastructure architecture years before those systems were externally visible.
For security teams, conference talks at DEF CON, Black Hat, and RSA where company engineers describe their defensive architecture in detail are a double-edged sword: they demonstrate capability and recruit talent, but they also create detailed public documentation of defensive systems that attackers can use to identify gaps. An analyst with an LLM can process a speaker's published slides and extract architecture details in minutes.
Feed the LLM: "Here are 30 job postings from [Company X] collected over the past 12 months. Identify: (1) all named security tools and vendors, (2) all cloud platforms mentioned, (3) any compliance frameworks referenced, (4) changes in hiring focus that suggest new projects or strategic shifts, and (5) any gaps in the security team that suggest unmonitored attack surfaces." This single prompt produces a structured technology and personnel intelligence report from publicly available data.
Use the AI assistant to practice extracting structured technology and personnel intelligence from job posting and LinkedIn data. The assistant will simulate responses based on realistic fictional data for a target organization.
Work through at least three analysis prompts: one for technology stack extraction, one for personnel mapping, and one for identifying security posture gaps based on what the hiring data implies about what the organization does and doesn't have covered.
Since 2022, the open-source investigation collective Bellingcat has published detailed passive intelligence reports on Russian military activity using exclusively publicly available data — satellite imagery, social media geotagging, equipment photographed by soldiers, unit insignia visible in videos. Their reports have identified unit movements, equipment losses, and command structures that national intelligence agencies confirmed after the fact.
Bellingcat's methodology is the gold standard of passive OSINT synthesis: collect broadly, cross-reference rigorously, document sources completely, and acknowledge uncertainty explicitly. Their 2022 coverage of the Mariupol siege used no human sources and touched no Russian military systems. Every finding derived from data the subjects themselves had made public.
Professional passive OSINT workflows follow a structured sequence. LLMs accelerate specific phases dramatically while leaving others to human judgment and legal review.
The output of a passive OSINT engagement is a structured report. Professional threat intelligence reports — whether from commercial vendors like Recorded Future, Mandiant, or CrowdStrike, or from open-source investigators like Bellingcat — share a common structure that ensures findings are actionable and defensible.
| Report Section | Content | LLM Role |
|---|---|---|
| Executive Summary | Key findings, risk level, recommended actions | Draft from synthesized findings |
| Scope & Methodology | Target definition, collection sources, dates, legal authorization | Structure and format |
| Infrastructure Profile | Domain map, IP ranges, hosting providers, CDN/WAF presence | Synthesize from CT/DNS/ASN data |
| Technology Stack | Security tools, cloud providers, SaaS integrations, frameworks | Extract from job postings/LinkedIn/GitHub |
| Personnel Map | Key individuals, roles, contact surfaces, tenure analysis | Reconstruct from LinkedIn/conference data |
| Credential Exposure | Known breach appearances, exposed credentials, paste site findings | Summarize aggregated breach data |
| Attack Surface Assessment | Prioritized list of exposure areas with supporting evidence | Infer from synthesized findings |
| Confidence Levels | High/Medium/Low for each key finding, with source basis | Annotate each finding |
Professional intelligence analysis requires explicit confidence labeling. The Intelligence Community uses a structured confidence framework — High, Moderate, Low — based on source quality, corroboration, and recency. Passive OSINT reports must apply the same discipline. An LLM synthesizing public data will sometimes draw inferences that are plausible but unconfirmed; these must be explicitly labeled as analytical assessments rather than established facts.
The Bellingcat methodology is instructive here: they annotate every evidentiary claim with the source, the date, and an explicit statement of what can and cannot be concluded from that source alone. When LLMs assist in synthesis, the analyst must review outputs for overconfident assertions — LLMs can present inferences as conclusions if not carefully prompted to distinguish between confirmed evidence and analytical judgment.
When requesting synthesis from an LLM, append: "For each finding, label your confidence as HIGH (multiple independent sources confirm), MEDIUM (single source, consistent with other evidence), or LOW (inferred from indirect signals only). Clearly distinguish confirmed facts from analytical inferences." This single prompt addition significantly improves the analytical quality of LLM-generated intelligence outputs.
Understanding passive OSINT methodology also informs defensive practice. Organizations that conduct regular external attack surface assessments — essentially passive OSINT engagements against their own infrastructure — identify exposure before attackers do. This practice, formalized by vendors including Attack Surface Management (ASM) platforms like Tenable ASM, CyCognito, and Cortex Xpanse, is directly analogous to the offensive passive OSINT workflow.
Defensive countermeasures informed by this module include: enabling DMARC enforcement (p=reject), auditing job postings for technology over-disclosure, monitoring CT logs for unexpected certificate issuance (suggesting subdomain takeover or unauthorized certificate requests), and running periodic GitHub searches for organizational credentials or infrastructure details in public repositories.
Passive OSINT with LLM assistance is not about collecting more data — it is about synthesizing existing public data faster and with greater depth than any human analyst can manage manually. The legal and ethical boundaries are clear: collect only from genuinely public sources, document your methodology, label your confidence levels, and operate within your authorized scope. The LLM is a synthesis engine. The analyst is the judgment layer. Neither is optional.
Bring together all passive data categories from this module — domain intelligence, personnel, technology, credentials, and financial — to build a complete structured passive OSINT report on a fictional target using LLM-assisted synthesis.
Walk through the six-step workflow from this lesson with the AI assistant. Practice applying confidence labels to findings and distinguishing confirmed evidence from analytical inference. Your report should be suitable for delivery to a red team client.