We closed Module 1 with the full framework of the TechNova S.L. engagement in place: we know what kind of pentest we are running (external + web + gray box with an internal extension), under which ethical and legal rules, and with which methodology (PTES as the backbone). It is time to take the first real step of the cycle: reconnaissance. And within reconnaissance, we begin with its most discreet, lowest-risk flavor: passive reconnaissance.

Passive reconnaissance means gathering information about the target without interacting directly with its systems. We do not send a single packet to tienda.technova.lab: every piece of information comes from third-party public sources (whois records, public DNS, search engines, certificates, historical archives, document metadata). From TechNova's point of view, it is as if we had never shown up in their logs, because technically we haven't. In this lesson you will learn which sources exist, how to read them, and how to start building the reconnaissance file that will feed the whole module, always respecting the scope and the Rules of Engagement (RoE) we signed.

1. Passive vs. active: the line you must not cross
2. Whois: who is behind the domain
3. Public DNS records
4. TLS certificates and certificate transparency (crt.sh)
5. Search engines and Google dorks
6. The web's past: archive.org
7. Metadata in public documents
8. Social media and corporate footprint
9. Ethical and scope framing
10. Common mistakes and tips
11. Exercises
12. Conclusion

This distinction is the foundation of the whole module, so it is worth nailing down from the start:

The mental rule is simple: if your action generates traffic that reaches one of the target's systems, it is already active. Querying TechNova's whois on a public whois server is passive. Running a zone transfer against their DNS server is active. In this lesson we stay strictly on the passive side.

An important warning to avoid overlapping modules: here we do not scan ports or enumerate services. That is active reconnaissance (02-02) and, in depth, Module 3. Passive reconnaissance draws the "who and what exists"; active reconnaissance confirms "what is alive and responding".

The whois protocol queries public databases of domain and IP registrations. It tells us who registered a domain, when, with which registrar and, sometimes, administrative and technical contact details. Because the query goes to a whois server (a third party), it is passive.

Sample output (fictional):

What we pull from here, line by line:

• Registrant Organization / Country: confirms the domain belongs to TechNova (Spain). Useful for validating that we are within scope.
• Admin Email: [email protected] reveals the corporate email pattern and a technical contact. This is gold for OSINT (lesson 02-04).
• Name Server: NS1 and NS2.technova.lab are its DNS servers. We note them down for active reconnaissance.
• Creation Date: the age of the domain sometimes hints at the maturity of the infrastructure.

For IP addresses there is the query to the RIRs (regional registries; in Europe, RIPE). If we know a public IP associated with TechNova, whois 203.0.113.10 will tell us which range and organization it belongs to, which helps delimit which IPs fall within the contracted scope.

Defensive counterpart: organizations reduce this exposure by using whois privacy (anonymized registrar contact) and generic contact emails instead of employee names.

DNS (Domain Name System) translates names into IP addresses and stores other configuration records. Querying DNS records is a gray area: asking a public resolver (such as 1.1.1.1 or 8.8.8.8) is passive, because we are talking to a third party that either already has the information cached or resolves it on our behalf. Querying TechNova's authoritative server directly would be closer to active. Here we use public resolvers.

The most useful record types in reconnaissance:

Example with dig (or nslookup/host) using a public resolver:

Reading: the SPF record reveals that TechNova uses an external mail provider (correo-pro.example). That provider is outside our scope: we cannot attack it even though it technically forms part of TechNova's mail chain. We note the fact but respect the scope. The google-site-verification entry suggests the use of Google services (for example Google Workspace or Search Console).

Every time an organization issues a TLS (HTTPS) certificate, it gets logged in public Certificate Transparency (CT) logs. Those logs are queryable and are a goldmine of subdomains, because they reveal every name a certificate has been issued for, even ones that appear in no public link.

The crt.sh web service queries those logs. Since we are querying crt.sh (a third party), it remains passive:

Sample output:

This result is very telling. In addition to the store, some interesting subdomains show up:

• dev. and staging-tienda. → development/pre-production environments, which tend to be less protected than production.
• intranet. and vpn. → access points into the internal network.
• correo. → a webmail or mail server.

We note all of them as candidates for the attack surface. Careful: appearing in CT does not confirm they are alive or reachable; we will verify that with active reconnaissance (02-02) and scanning (Module 3). And we will only work on the ones that fall within the contracted scope.

Defensive counterpart: CT logs are public by design (they improve overall security), but a security-conscious organization avoids putting obvious hints such as admin- or test- in certificate names, and protects staging environments just as well as production ones.

Search engines have indexed parts of websites for years. With advanced search operators (known as Google dorks) we can find exposed information without ever touching TechNova's server: everything comes from Google's index.

Useful operators:

Example reconnaissance queries:

Finds public PDF documents (manuals, catalogs, price lists) that we will later analyze for their metadata.

Discovers login pages (panels, intranets) that reveal technologies and entry points.

Looks for open directory listings, a classic accidental exposure of files.

Dorks are passive because we are interrogating the search engine's index, not TechNova. There are public collections of dorks (the best known being Exploit-DB's Google Hacking Database) that systematize these searches.

The Wayback Machine at archive.org keeps historical copies of web pages. It is enormously useful because an organization may have removed a link, a panel, or a code comment from its current site, yet the old version is still archived. We are querying the archive (a third party), so it is passive.

Here we see historical paths that may no longer be linked but could still exist: /backup/, /old-panel/. They are leads for later phases. It also lets us reconstruct how the site's technology has evolved (for example, deducing that it once used WordPress from the /wp-content/ path).

Office files (PDF, Word, Excel, images) carry metadata that can leak sensitive information: internal usernames, software and versions, network paths, machine names. Downloading a public document that is already indexed and analyzing it locally is passive (we do not interact with the target's internal infrastructure).

Using the exiftool tool on a PDF downloaded from the search engine:

Reading the finding:

• Author: jlopez → a likely internal username (pattern "first initial + last name"). Combined with the [email protected] from whois, we start deducing the company's naming convention.
• Creator/Producer → office software in use (Office 2016), which gives a sense of the technology ecosystem.

These data are seeds for people-focused OSINT and for future credential attacks (Module 4), always within scope.

Corporate pages on professional networks, the company blog, press releases, and employee profiles unwittingly publish technical and organizational information: technologies they use ("we are looking for a developer with experience in Laravel and MySQL"), names and job titles, emails, and even office photos showing screens or whiteboards.

All of this is passive (we read public content) and very valuable for the people map. But it is also the most delicate ground ethically: we are working with personal data. Here we only introduce it; the full discipline of OSINT on people, with its privacy and GDPR framework, is covered in lesson 02-04.

Example passive reconnaissance flow for TechNova:

Even though passive reconnaissance does not touch the target's systems, it is not a blank check. Remember TechNova's RoE:

• Respect the scope. You may find third-party infrastructure (the mail provider correo-pro.example, a CDN, a hosting provider), but you cannot attack it. In passive terms this translates to documenting without exploiting.
• Do not pivot to third parties or to employees outside the contract. Discovering an employee's professional profile is different from harassing them or social-engineering them if that is not authorized in scope.
• Handle personal data in accordance with GDPR. Collect only what is needed for the audit's objective, store it securely, and delete it as agreed.
• Document every source. Note where each piece of data came from: it is essential for the report's traceability and so TechNova can reproduce and remediate.

• Accidentally crossing into active. Typing a subdomain's URL into the browser already sends a request to the target: that is active. Keep the discipline of third-party sources while you do passive work.
• Confusing "exists in a certificate" with "is alive". crt.sh and archive.org show what was or might have been; they do not confirm availability. Verify it afterwards.
• Ignoring the scope when you find third parties. It is easy to get excited about the provider's mail server; remember it is outside the contract.
• Not documenting provenance. Data without a source is useless in a professional report. Always record origin and date.
• Tip: do passive reconnaissance before active. The more you know from public sources, the more surgical and less noisy your subsequent active reconnaissance will be.

Exercise 1. Classify each action as passive or active and justify: (a) querying whois technova.lab; (b) opening https://intranet.technova.lab in the browser; (c) searching site:technova.lab filetype:pdf on Google; (d) running dig @1.1.1.1 tienda.technova.lab.

Exercise 2. From the crt.sh output in section 4, indicate which three subdomains you would prioritize as interesting for the scanning phase and why. Remember to mention the caveat "exists ≠ is alive".

Exercise 3. You analyze the metadata of a public TechNova PDF and find Author: mgarcia and Company: TechNova S.L.. Together with the Admin Email: [email protected] from whois, what corporate username pattern can you deduce and for which future phase will it be useful? Mention the ethical limit.

Solution 1. (a) Passive: the query goes to a third-party whois server, not to TechNova. (b) Active: opening the subdomain sends a direct HTTP request to the target's server. (c) Passive: we are interrogating Google's index, not TechNova's site. (d) It is passive/borderline: we ask a public resolver (1.1.1.1), not the target's authoritative server; the traffic goes to the third party. Had we used dig @ns1.technova.lab, it would clearly be active.

Solution 2. I would prioritize staging-tienda.technova.lab and dev.technova.lab (pre-production/development environments, typically worse secured and sometimes holding real data), and vpn.technova.lab or intranet.technova.lab (gateways into the internal network, high value). The key caveat: appearing in a certificate (crt.sh) only proves that a certificate was issued for that name; it does not guarantee the host is alive, reachable, or in scope. We will have to confirm it in 02-02 and in Module 3.

Solution 3. The deducible pattern is "first initial + last name": mgarcia = M. García, consistent with jlopez = J. López from the example. The sistemas@... email is a generic account, but the username pattern will let us build lists of likely users/emails (e.g. [email protected]). It will be useful in lesson 02-04 (OSINT on people and emails) and, later, in Module 4 (password attacks). Ethical limit: these are personal data; they are only used within the authorized scope, in accordance with GDPR, and without harassing or contacting the individuals beyond what was agreed.

Passive reconnaissance has let us start TechNova's file without sending a single packet to its systems: we have identified the organization and contacts (whois), its DNS and mail infrastructure (public records), a good handful of candidate subdomains (crt.sh), exposed files and panels (dorks and archive.org), internal usernames (metadata), and a first footprint of people and technologies (social media). All of it with a practically nonexistent trace and scrupulously respecting the scope and GDPR.

But passive work has a limit: it tells us what could exist, not what is alive and responding. To confirm it, we must interact with the target. In the next lesson, 02-02 Active Reconnaissance, we will begin to "touch" TechNova's infrastructure in a controlled way -DNS resolution and zone transfer, live host discovery, basic banner grabbing, traceroute, and active subdomain enumeration- while clearly marking the boundary with deep port scanning, which we reserve for Module 3.