OSINT: Learning from Open Sources

Before a single packet reaches a target, a careful tester already knows a lot: company names, technologies, employee roles, public documents. This is OSINT, open source intelligence. In this lesson you will learn the principles of OSINT and practise them safely, without ever targeting a real organisation.

Chapter 1 gave you permission and a workshop. Project Lighthouse begins here, with the first phase every methodology agrees on: reconnaissance. The idea is simple and powerful: a huge amount of useful information about an organisation is already public, scattered across the web, and a tester's first job is to gather and connect it.

What OSINT is, and why it matters

OSINT stands for Open Source Intelligence: the discipline of collecting and analysing information that is legally and publicly available. It is used by journalists, researchers, recruiters, and also by attackers and defenders in security. For a penetration tester, OSINT answers questions such as: What does this organisation look like from the outside? What technologies does it use? Who works there, and what might they fall for in a phishing email? What has been accidentally leaked?

OSINT is attractive to attackers because it is invisible: reading a public web page or a public document never touches the target's systems, so there is nothing to detect. This is exactly why defenders should also think about what their own public footprint reveals, a theme you already met in the first course of this track.

Categories of open sources

Instead of a list of specific websites, which change constantly, learn the categories of information a tester looks for.

• Official company information: the organisation's own website, its "about" and "careers" pages, press releases, annual reports for public companies. These reveal structure, locations, partners and sometimes technology choices.
• Domain and infrastructure records: public domain registration records, which can show registration dates, organisation names and sometimes contact details, subject to privacy protections that vary by country and registrar.
• Technical metadata: public job postings often mention the exact technologies a company uses ("looking for a developer experienced with our cloud platform and our ticketing system"), which is a goldmine for understanding the target's stack without touching it.
• Code and configuration repositories: public code hosting platforms sometimes contain, by mistake, internal host names, comments describing internal systems, or even credentials committed by accident. This is one of the most common real-world sources of serious findings.
• Social media and professional profiles: employees often describe their role and tools in professional profiles, which helps understand the organisation chart and potential phishing angles.
• Public document metadata: PDFs and office documents published online sometimes contain author names, internal usernames, or software version numbers in their metadata.
• Breach and leak awareness: knowing whether an organisation's domain has appeared in known, publicly reported data breaches. This course does not use any specific lookup service; the key idea to remember is that compromised credentials from unrelated breaches are a common cause of account takeover, because people reuse passwords.

A simple method: question, source, note

A structured approach avoids both missing important clues and getting lost for hours. For every piece of information you look for, follow three steps:

1. Ask a precise question. Not "what can I find about this company" but "which technologies does it mention in its job postings" or "which email address format does it use".
2. Choose the right category of source from the list above.
3. Record the answer with its source in your journal, including the date you found it, since public information changes over time.

This turns OSINT from an endless browsing session into a checklist you can complete and hand to a colleague.

What good OSINT produces

At the end of a reconnaissance phase, a tester should be able to answer, for the organisation in scope:

• What are its public domain names and how are they organised (for example separate domains for marketing, support, and the product itself)?
• What technologies does it likely use (web framework, cloud provider, ticketing system), based on job postings and public mentions, stated cautiously as hypotheses to verify, never as certainties?
• Who are the people likely to be visible externally (press contacts, technical staff who speak at public conferences), useful to understand social engineering risk, never to actually contact them without authorisation?
• Are there any obviously exposed documents or repositories that should be flagged to the client immediately, even before the rest of the test is finished?

Notice the last point: if OSINT reveals an urgent exposure, such as credentials visible in a public repository, a professional tester reports it right away rather than waiting for the final report.

The limits of OSINT

OSINT is powerful but has blind spots. It reflects what is public, not what is true or current: job postings can be outdated, and employees change roles. It can also be slow and noisy if done without structure. Finally, OSINT never proves a vulnerability by itself; it only builds hypotheses that the later phases (scanning, vulnerability analysis, exploitation) will confirm or reject.

Your fil rouge: OSINT on Lighthouse Labs

For Project Lighthouse, your "open sources" are a short fictional dossier that your course instructor-self will imagine, since there is no real company to research. Write a one-page OSINT summary for Lighthouse Labs using your imagination, following the categories above: a plausible domain structure (for example lighthouse-labs.example for the main site and support.lighthouse-labs.example for a help desk), two or three plausible technologies based on a fictional job posting you write yourself, and one example of a document metadata finding. Save it in 01-recon in your engagement folder. This exercise builds the habit of structured notes even without a real target.

Your turn: practise the method, not the target

Pick a category from the list above and apply the "question, source, note" method to your own public footprint, with your consent as the subject. For example: "What does a public search of my own name reveal about my professional background?" or "What technologies do my own public code repositories reveal about my skills?"

1. Write one precise question.
2. Identify which category of source would answer it.
3. Write down what you find, with the source and the date.
4. Reflect: would this information be useful to someone trying to guess your passwords or craft a phishing message aimed at you?

See a solution

A typical finding: a public code repository under your own name reveals the programming languages and tools you commonly use, and perhaps an email address in commit history. Reflection: this is exactly the kind of detail that would let an attacker write a convincing message ("I saw your project using X, could you review this file?"), which is why professional organisations train employees to be cautious even with seemingly technical, low-risk-looking messages.

Next, you will turn a domain name into a detailed map of subdomains, the first step towards understanding the true size of a target.