Technical Intelligence (TECHINT) Infrastructure Auditing in OSINT

Public infrastructure auditing connects domains, addresses, certificates, and routing observations to a clearly scoped research question. It can reveal useful relationships and changes, but it does not produce a complete map of an organization or prove who operates a site from a shared IP address. Every relationship needs a source, a time reference, and an explanation of what it means.

This guide explains a practical OSINT workflow for technical infrastructure research using registration data, Certificate Transparency, passive DNS, and routing resources. It includes a worked example, a relationship log, related tools, and checks that prevent technical correlations from becoming unsupported ownership or attribution claims.

Expanded November 5, 2026 with AI assistance and linked documentation review. The earlier article disclosed Gemini assistance. Examples are hypothetical. “TECHINT” is used here as a broad editorial label for technical public-source research, not as a universal professional classification.

Define the question and the access boundary

Start with a question such as “Which public records support this domain’s relationship to our organization?” or “What documented infrastructure changes occurred during the incident period?” A bounded question makes it easier to distinguish relevant evidence from an expanding list of unrelated hosts.

Record the starting domains, identifiers, date range, permitted sources, and decision the work will support. For an organization auditing its own assets, identify the internal owner who can confirm uncertain relationships. Public evidence can then be compared with authoritative internal records.

Separate third-party database research from direct interaction with infrastructure. A lookup in an existing dataset can avoid contacting the subject’s website, while the dataset provider still receives the query. A live DNS query, page visit, or technical test has a different collection path.

A public-source assignment does not automatically authorize scanning, exploitation, or access to nonpublic systems. If the investigation needs an active test, define that activity and its permission separately rather than quietly expanding the OSINT scope.

Know the roles of the main data types

Source type	Useful question	Limit to preserve
Domain registration data	What registration details are publicly available?	Fields may be redacted; registration is not a complete business history.
Certificate Transparency	Which certificates or precertificates were logged for these names?	A log entry does not establish that a service was live or identify its business owner.
Passive DNS	What resolutions did this provider observe?	Observation coverage is incomplete and provider-specific.
Number-resource and routing records	What allocation or route information relates to an address or network?	Routing, registration, service operation, and physical location are different claims.
Public website material	What did the site publish or link to at collection?	Templates, copied content, and third-party services can create misleading similarities.

Do not combine these into a single “ownership confirmed” field. Give each observed relationship an explicit type and retain its limits.

Use RDAP for current domain-registration research

ICANN’s January 2025 update identifies RDAP as the definitive registration-information service for generic top-level domains from January 28, 2025. Its Lookup service is a practical starting point for publicly available records.

Record the exact domain, query time, relevant fields, and source. Distinguish creation, update, expiry, and other dates rather than treating every timestamp as the beginning of the business or website.

Redacted contact information is not evidence of wrongdoing. A registrar is not the registrant, and a privacy service is not necessarily the business operating the site. Preserve those role distinctions in both the working notes and the report.

Historical registration datasets can add context, but inspect their dates and coverage. A former contact does not establish current control. An absent historical record does not prove the domain had no activity before the provider’s first observation.

Read Certificate Transparency as certificate evidence

Certificate Transparency’s documentation explains public, append-only logs and the role of monitors. They make certificate-related records inspectable and can help domain owners notice unexpected issuance.

A logged name can be a useful lead for asset review. Record the certificate identity, relevant names, validity information, and log context. Distinguish a certificate’s validity interval from proof that a site operated throughout that interval.

Do not describe CT as a record of every certificate in every environment. Private certificates and services outside the relevant ecosystem are not made universally visible by this mechanism. A missing result is therefore limited evidence.

Certificates also do not establish ultimate corporate ownership. Shared certificates, managed services, delegated administration, and historical arrangements require contextual review. Verify the business relationship through appropriate organizational or corporate evidence.

Use passive DNS without assuming complete history

Passive DNS datasets organize observed DNS information. DNSDB’s official documentation describes a related service and its query interfaces. Consult the current service documentation for coverage, record semantics, access, and limits before interpreting a result.

The key word is observed. A provider’s earliest or latest observation should not automatically become the exact start or end of a real-world relationship. Collection coverage, caching, and source availability affect what appears in the dataset.

Preserve record type and direction. A domain resolving to an address is different from a mail-routing record or an alias relationship. The interpretation depends on what the record actually says and when it was observed.

Compare historical and current questions explicitly. A domain may have used an address during the incident period but no longer use it today. Conversely, a current co-hosting relationship may have no bearing on an older event.

Keep allocation, routing, and service ownership separate

RIPEstat provides resources for examining internet number and routing information. Its data-source documentation helps explain where the displayed information comes from.

A resource-registration record can identify an allocation-related organization. A routing observation can identify an announced prefix or network path within the observer’s view. Neither alone establishes the end customer operating a particular application.

Cloud hosting and content-delivery networks make this distinction especially important. A service provider’s address space can support many unrelated customers. Drawing all of it as one company’s own infrastructure greatly overstates the evidence.

Physical location needs its own support. An address’s registry country, an inferred geolocation, and the location of a server or user are not interchangeable. State which field or method produced the location label.

Build a relationship log before drawing a graph

Create one row per observed relationship. Useful fields include source identifier, subject, relationship type, object, observation period, retrieval time, provider, source reference, confidence rationale, and unresolved alternatives.

Use precise relationship names such as “resolved to,” “appeared in certificate,” “registered through,” “announced by,” or “linked from.” Avoid a generic “connected to” edge that hides the distinction between technical association and organizational control.

Retain the underlying response or permitted export. A graph alone can lose timestamps, record types, and provider caveats. Reviewers should be able to open the source record behind the relationship that matters.

Use separate statuses for confirmed internal assets, public associations awaiting confirmation, third-party services, historical relationships, and rejected matches. This makes the graph useful for action rather than merely visually impressive.

Quality-check the records before interpreting the map

Distinguish a completed query with no matching records from a failed or incomplete request. Authentication errors, quota limits, pagination, and source outages can all produce an apparently small result set. Keep the query outcome and coverage information with the exported records.

Normalize names conservatively. Preserve the original value alongside any standardized form, and distinguish a domain from a hostname, URL path, or email address. A normalization rule that collapses different resources can manufacture a connection that the source never reported.

Check time alignment before joining datasets. A certificate observation from one year and a DNS observation from another do not establish a simultaneous relationship. Record the period each source can support and mark overlaps as known, possible, or unresolved.

For an internal asset audit, test the workflow against a small set of known resources and inspect what was missed or misclassified. This can reveal local processing defects. It does not establish completeness across the public internet, but it makes the audit’s actual performance easier to assess.

Worked example: two domains share an address

A fictional organization discovers that its public domain and an unfamiliar domain appeared at the same address in a historical dataset. The initial observation is a possible hosting association during the provider’s observed period.

The researcher checks the dates and record types, then examines relevant number-resource context. The address belongs to a shared hosting provider. That ordinary explanation weakens any claim that the two domains must have the same owner.

A certificate search provides a name related to the organization’s own service. The researcher sends the candidate asset to the internal system owner, who checks the approved service inventory. The record can now be classified based on both public evidence and authorized organizational confirmation.

Suppose no reliable evidence connects the unfamiliar domain to the organization. The report retains the observed hosting association and rejects an ownership inference. It does not label the unfamiliar operator a hidden subsidiary or an attacker.

The decision value comes from identifying what needs confirmation and avoiding false expansion of the asset list. The method remains useful even when the most interesting-looking connection has a routine explanation.

Evaluate fingerprints and repeated identifiers as clues

A favicon, analytics identifier, header, or TLS-related feature can help group observations. Similarity does not establish uniqueness. Templates, agencies, shared software, copied pages, and managed infrastructure can create matches between unrelated sites.

Before using a fingerprint as a pivot, ask what generated it, whether the value can be reused, and whether it was observed in the relevant period. Record the matching method and any normalization applied.

Do not let a graph of repeated identifiers become an ownership claim without additional evidence. Seek a different source type that can address the actual organizational question. The corporate entity and control guide explains why technical similarity and legal control must be distinguished.

Preserve rejected explanations as part of the record. If a repeated identifier was traced to a public template, that finding helps future reviewers avoid rediscovering the same false lead.

Protect research queries and collection credentials

Third-party data providers can receive your searches and account activity. Assess whether a query reveals confidential investigation details. Use approved accounts, protect API credentials, and check the provider’s terms and data-handling arrangements.

Adding random queries does not provide a reliable privacy guarantee and can waste quota or breach usage expectations. Choose a collection arrangement that fits the task and document its exposure rather than describing a proxy or API as non-attributable.

Separate source responses from workflow instructions if AI is used to summarize results. A record returned by a service should not change collection permissions, reveal keys, or authorize unrelated requests.

Use the OSINT operational-security guide to plan assets, observers, accounts, and file handling. Privacy controls should match the actual research path.

Related tools and a manageable first audit

Start with ICANN Lookup for relevant domain-registration data, CT resources for certificate observations, and RIPEstat for number-resource and routing context. Add a passive-DNS provider only when historical resolution information answers a defined question.

A spreadsheet can manage a small audit. Use a graph tool when it improves comparison, while preserving relationship types and dates. The tool should expose uncertainty rather than draw every candidate with the same visual authority.

For an organization’s own inventory, begin with a small set of known domains and compare public candidates with the internal owners’ records. Track confirmed assets, dependencies, historical entries, and unresolved leads separately.

For continuing review, the automated monitoring guide explains source health, deduplication, and analyst feedback. An alert about a new certificate or resolution is a review event, not automatic proof of a new asset or incident.

Report coverage and conclusions precisely

Lead with the question, period, and finding. List the sources and their coverage, then explain the relationships that support the conclusion. Keep observation dates distinct from retrieval dates and any estimated operational dates.

Describe missing results narrowly. “No matching record was located in these sources during this query” is different from “The infrastructure does not exist.” Public datasets cannot prove universal absence.

State the next action for each unresolved lead. An internal owner may need to confirm a service, a historical record may need corroboration, or a different source may be required for ownership. Avoid a broad definitive-attribution label unsupported by those checks.

Frequently asked questions

Does a shared IP address prove common ownership?

No. Shared hosting and service providers can explain the relationship. Record the observed association and seek evidence appropriate to the ownership question.

Is a CT entry proof that a website was live?

No. It documents a certificate-related record in the log. Service operation and content require additional evidence.

Can passive sources provide a complete infrastructure map?

No general completeness guarantee is justified. Document the sources, date range, and confirmation method, and treat the result as the observed and reviewed scope.

Sources and related learning

The primary infrastructure references and official service documentation are linked beside their descriptions. The shared-hosting example and relationship log are editorial teaching material, not claims of original network testing.

Explore the OSINT Research Hub, Free Research Library, and Start Here guide. Keep each technical observation connected to its source and time, and make the step from correlation to conclusion explicit.