We reach the last lesson of Module 2. So far we have learned to gather information passively (02-01), to confirm and expand it actively (02-02), and to do so with the right tools orchestrated into a flow (02-03). The result is a long but disorganized inventory: subdomains, IPs, live hosts, versions, emails, users, technologies. A pile of data, yes, but not yet an attack surface.

This lesson does two things. First, it brings in the discipline of OSINT (Open Source Intelligence) in its richest and most delicate facet: the one revolving around people (emails, leaked credentials, digital footprint) and modern exposure (cloud, buckets, code repositories). Second, and above all, it consolidates everything gathered in the module into a prioritized attack surface map: the deliverable that tells the pentester -and Module 3- where to start. Since OSINT touches personal data, we will devote a central section to its ethical and legal framework (GDPR), consistent with TechNova's RoE.

1. What OSINT is and how it fits into reconnaissance
2. OSINT on people: emails, employees, and digital footprint
3. Leaked credentials in breaches
4. Cloud exposure: buckets and services
5. Code repositories and secrets
6. Ethical and GDPR framework of OSINT on people
7. Consolidate: the attack surface map
8. Prioritizing TechNova's attack surface
9. Common mistakes and tips
10. Exercises
11. Conclusion

OSINT is the discipline of obtaining and analyzing information from open (public) sources to produce intelligence: not loose data, but actionable knowledge. In pentesting, OSINT is the layer that gives human and organizational context to the infrastructure we already mapped.

It is worth placing the terms carefully:

• Everything we did in 02-01 is, in a broad sense, OSINT (open sources).
• But when we speak of "OSINT" as a discipline in its own right, we usually mean the part more oriented toward people and indirect exposure: who works at the company, what emails they have, whether their credentials appear in breaches, what they have inadvertently uploaded to the cloud or to GitHub.

It is information that rarely lives in DNS or in a certificate, but that opens very real vectors (targeted phishing, password reuse, access to exposed data). Almost all OSINT is passive; its risk is not technical but ethical and legal, because we work with individuals' data.

Organizations leave a footprint of people: professional profiles, article authors, event speakers, document signatories. From the email pattern we deduced in previous lessons ([email protected], seen in jlopez, mgarcia, sistemas@), we can build and validate lists of corporate emails.

From here we build a people map with role and email. What is it for, within scope?

• Phishing/social engineering vector (only if the scope authorizes it): the email of rrhh@ or of an administrator is a typical target.
• Seed for credential attacks (Module 4): likely users for authorized testing.
• Organizational understanding: knowing who administers what helps interpret the infrastructure.

Defensive counterpart: anti-phishing awareness training, not publishing detailed technical org charts, and using role aliases (soporte@) instead of personal names where possible.

Over time, countless services suffer data breaches and the credentials end up in public dumps. If an employee used their corporate email on a third-party service that was compromised, that email -and sometimes a password or its hash- appears in those dumps. Querying these sources is passive (we interrogate a third-party database such as Have I Been Pwned), but it is among the most sensitive parts of the module.

Reading: the email [email protected] appears in two breaches that include passwords. This matters because of password reuse: if jlopez used the same password on ForoTech2019 as on TechNova's VPN, an attacker gets in without exploiting any technical vulnerability.

Essential framing:

• We only verify exposure, we do not use the leaked passwords outside the scope or against third parties.
• Using specific credentials to attempt access (credential stuffing) belongs to Module 4 and only if the contract explicitly authorizes it.
• Handling real password dumps has serious legal implications; in a real audit it is handled with extreme care and legal counsel.

Defensive counterpart: MFA on all access, policies that prohibit reusing corporate passwords on external services, and monitoring of exposed credentials.

Modern infrastructure lives in the cloud, and a huge source of leaks is misconfigured storage buckets (AWS S3, Azure Blobs, GCS) left public. They tend to follow predictable naming conventions based on the company name: technova-backups, technova-dev, technova-assets.

A 200 code (instead of 403 Forbidden) suggests the bucket is accessible. If it also allows listing its contents, we could see exposed files:

A db_dump_2023.sql or a .env file (which usually contains database credentials and API keys) is a critical finding. Scope point: the bucket must belong to TechNova and be within the contract. Finding a bucket with its name does not authorize downloading its content if the scope does not include it; document the exposure and check before going further.

Defensive counterpart: block public access by default, review bucket policies periodically, and do not store secrets or dumps in accessible storage.

Developers sometimes publish code in repositories (GitHub, GitLab) that leaks information: API keys, passwords, tokens, internal paths, IP addresses. Recall that in 02-02 a git.technova.lab appeared. Searching public repositories by the organization name or the domain is very productive passive OSINT.

Example finding (fictional fragment found in an old commit):

Reading: a developer uploaded real credentials that, even if later "deleted", remain in the commit history. We see the internal host db-interno.technova.lab (matching the 10.10.10.40 from the 02-02 zone transfer), a DB user, and a password. Tools such as secret scanners automate the detection of these patterns in repos. All of this is documented as exposure; using it to gain access is Module 4 material and only within scope.

Defensive counterpart: secret scanning in CI/CD (pre-commit hooks), immediate rotation of any secret that reaches a repo, and a policy of never versioning configuration files with credentials.

OSINT on people is legal and powerful, but it steps onto personal data ground, regulated in the EU by the GDPR. That something is publicly accessible does not mean its use is free. Principles that must guide your work:

• Legitimate basis and purpose. The only reason to collect these data is the authorized audit of TechNova. Do not use them for anything else.
• Minimization. Collect only what is necessary for the objective. Do not accumulate personal data "just in case".
• Strict scope. OSINT on employees only of the target organization and only if the contract contemplates it. No relatives, third parties, or providers outside the scope.
• Do no harm. Finding an employee's private life does not authorize exposing it, contacting it, or using it beyond what was agreed. No harassment or unauthorized social engineering.
• Security and deletion. Store these data encrypted, with restricted access, and delete them as agreed when the project closes.
• Transparency in the report. Document what you collected and why; the client must be able to understand and justify the processing.

In short: the limit of OSINT is not technical (almost everything is reachable), it is ethical and legal. A professional is distinguished precisely by respecting that limit. When in doubt, consult the contract and, if needed, legal counsel.

The attack surface is the set of all the points through which an attacker could try to get in: every host, service, subdomain, account, credential, or exposed piece of data. Consolidating the module means gathering everything collected (02-01 to 02-04) into a single map.

The map distinguishes three layers: external (what is reachable from the Internet), internal (the 10.10.10.0/24 network), and human/data (people, credentials, cloud and code exposure). The red nodes mark the most critical items.

A map is not enough: we have to prioritize so Module 3 knows where to start. A simple criterion combines value (what is gained if it falls) and exposure/ease (how reachable and weak it looks). The following table ranks TechNova's surface:

How to read this prioritization:

• The critical items combine high value and strong evidence of weakness: a db-interno with already-leaked credentials and a public bucket with a DB dump.
• The store is high priority because it is the main target in scope, is on the Internet, and runs unsupported software (PHP 7.2).
• The staging/dev environments rise in priority because they are usually worse protected than production.

This prioritized table is the deliverable that connects reconnaissance with scanning. We have not exploited anything: we have drawn where to look first.

• Confusing "public" with "free to use". That a personal datum is accessible does not authorize any use; GDPR and the contract rule.
• Going out of scope with OSINT. Investigating an employee's relatives, a provider, or using leaked credentials against third-party services is crossing the line. Stick to the organization and the scope.
• Accumulating unnecessary personal data. Collect the minimum; store encrypted; delete on closing. Minimization protects you and the client.
• Delivering an unprioritized inventory. A list of 200 hosts does not help; a map with 5 priorities does. The value is in the analysis, not the volume.
• Using OSINT findings to exploit in this phase. Recon documents; exploitation (using those credentials or that secret) is for later modules and only within the contract.
• Tip: when prioritizing, always cross value and exposure. A serious flaw in an unreachable system weighs less than a medium one in a system exposed to the Internet.

Exercise 1. You find that [email protected] appears in a data breach with a password. List what you can do with that datum in the reconnaissance phase and what you cannot do (and in which module and under what condition the latter could be done).

Exercise 2. Rank these three findings by priority for Module 3 and justify with the value and exposure criteria: (a) an internal intranet only reachable from inside; (b) the store on the Internet with unsupported PHP 7.2; (c) a public technova-backups bucket with a db_dump.sql.

Exercise 3. A colleague proposes investigating the social media profiles of the systems administrator's partner "to have more context". Explain why this is unacceptable, citing at least two principles of the ethical/GDPR framework.

Solution 1. I can: document that the email appears in a breach, note the vector (possible password reuse), and reflect it in the surface map as a risk, informing TechNova. I cannot: use that password to attempt access to the VPN, the intranet, or any system. That attempt (credential stuffing) belongs to Module 4 and only if the contract explicitly authorizes it. In reconnaissance we only verify and document the exposure, never use the credential.

Solution 2. Order: 1st (c) the public bucket with db_dump.sql (very high value -a DB dump- and maximum exposure -reachable from the Internet without authentication-: critical and immediate). 2nd (b) the store with PHP 7.2 (high value -the main target in scope- and high exposure -Internet + unsupported software, prone to known vulnerabilities-). 3rd (a) the internal intranet (although its value is relevant, its exposure is low: only reachable from inside, so it first requires setting foot on the network). The criterion: at equal value, prioritize what is most exposed and easy to reach.

Solution 3. It is unacceptable because: (1) it violates the scope: the administrator's partner is a third party outside the target organization and is not in the contract; (2) it breaches GDPR minimization: it is not a datum necessary for the purpose of auditing TechNova's security; and (3) it violates the do-no-harm/no-harassment principle: investigating the private life of unrelated people is intrusive and potentially unlawful. OSINT on people is limited to employees of the target organization, only if the contract contemplates it, and only with data relevant to the technical objective.

With this lesson we close Module 2. We have completed reconnaissance by incorporating the OSINT dimension -people and emails, credentials leaked in breaches, cloud exposure, and secrets in repositories- always under a strict ethical and GDPR framework, and we have done the most important thing: consolidate and prioritize everything collected into an attack surface map. We no longer have a scattered inventory, but a reasoned list of targets with their priority, distinguishing external, internal, and human surface.

Recapping the module: we started from zero on TechNova and now we know its domain and contacts (02-01), which hosts are alive and which versions they run (02-02), which tools to orchestrate the recon with (02-03), and what its prioritized attack surface looks like -and where to start (02-04). Reconnaissance has done its job: it tells us where to look.

Now it is time to really look. In Module 3: Scanning and Enumeration, we will take that prioritized list -starting with the store, the exposed environments, and the live hosts of 10.10.10.0/24- and move from "what exists and where" to "which ports, services, and exact versions there are, and what vulnerabilities they present". The first lesson, 03-01 Port Scanning, picks up right where we left the nmap -sn: now, at last, we will open the ports in depth.