5.2 OSINT Sources and Techniques

Open-source intelligence (OSINT) is the named 2.1 bucket for collection from publicly available sources. CompTIA's list is specific: social media, job boards, scan code repositories, DNS lookups, reverse DNS lookups, cached pages, cryptographic flaws, and password dumps. DNS, reverse DNS, cached pages, and certificate-adjacent search get their own section next. This section is the human-and-leak layer: what employees and the company already published, and how that becomes information disclosure on a penetration-test report.

OSINT is almost always passive in the sense of the previous section — you are not SYN-scanning the client. It is not "anything on the internet." A live crawl of the production app is HTML scraping (active). A Shodan query of historical banners is OSINT-like third-party data (passive from your side). Keep the authorization question in view: public does not mean you may phish the people you found, paste full breach corpora into Slack, or treat a leaked AWS key as permission to use it against the account.

Social media

LinkedIn, corporate blogs, conference talks, YouTube architecture sessions, and even Instagram photos of badge lanyards or rack labels leak useful facts. Typical PenTest+ value:

• Org chart and titles — who runs IAM, who owns the Palo Alto estate, which vendor just finished a cloud migration.
• Tech stack in "About" and posts — "We moved the customer portal to EKS," "Our SOC is on Splunk," screenshots of Okta login pages in a how-we-work article.
• Personal GitHub linked from a profile — a developer's public gist that still contains a staging URL or an API token from a hackathon.
• Location and shift clues — helpful for physical or vishing scenarios only if RoE later allows social engineering; they are not a 2.1 exploit.

Exam trap: enumerating employees on LinkedIn is recon. Sending those people a credential-harvesting email is a Domain 4 social-engineering attack and needs explicit authorization. Do not jump domains in a 2.1 question.

Job boards

Job posts are one of the highest-yield OSINT sources on the exam because they are written for recruiters, not for a security reviewer. A listing for "Senior Palo Alto administrator, example.com" tells you the edge is likely PAN-OS, which later informs VPN and management-plane hypotheses. Other common leaks: Kubernetes, Terraform, specific SaaS IdPs, "legacy AS/400 still in use," "must know Cisco ISE," on-call tools, and even CIDR-sized hints ("experience with our /16 in us-east-1"). Contract roles often name the exact product being replaced, which is a map of the current and next stack.

Treat job-board data as stack and process intelligence, not as a target list. The Palo Alto is not in-scope until a selector (IP, CIDR, hostname, URL) and RoE say so. The finding, if you report it at all before testing, is that the company discloses internal architecture in public hiring ads — a low-severity information-disclosure note unless it names unpatched product versions.

Scan code repositories

"Scan code repositories" on PT0-003 means searching public GitHub, GitLab, Bitbucket, Gitea, Gists, CI logs, and package registries the client or its staff already published. You look for:

• Hard-coded cloud access keys, API tokens, and database passwords in old commits (history matters; deleting a file from HEAD does not erase the blob).
• SSH private keys, .pem files, and id_rsa committed "just for the pipeline."
• .env examples that were not examples, Terraform state, kubeconfigs, and mobile app google-services.json / Info.plist secrets.
• Internal hostnames, forgotten microservices, and comments that describe auth bypasses.

That is information disclosure and often a cryptographic flaw (a private key is cryptographic material that should never have left the HSM or secrets manager). Professional handling: stop, record the URL and commit, do not use the key to expand access unless RoE explicitly allows credential testing, and tell the client to rotate immediately through the escalation path. You do not brute-force GitHub accounts, you do not clone private repos you are not entitled to, and you do not paste the live secret into the PDF report — cite a redacted fingerprint and the location.

Cryptographic flaws found in OSINT

CompTIA lists cryptographic flaws next to password dumps because many of them are sitting in public artifacts before you ever run a scanner:

• Leaked certificates and private keys — a .key or PKCS#12 in a repo, a cert that CT shows was issued for an internal name, an expired cert that nobody renewed.
• Weak SSH keys — old 1024-bit RSA, reused keys across jump hosts, a key with no passphrase in a gist.
• Old TLS — Shodan/Censys historical rows showing TLS 1.0/1.1 or export-grade ciphers on a hostname. Historical data is a lead; proving the live service still speaks TLS 1.0 is an active handshake.

The exam wants the decision: OSINT can detect the leak; exploiting a weak cipher or using a stolen key is a later, authorized step.

Password dumps

Public breach corpora and lookup services (the exam-relevant pattern is Have I Been Pwned-style checks of a corporate domain, plus public paste sites) tell you whether @example.com addresses appeared in known incidents. That supports a professional finding: password reuse and missing MFA, especially if the same addresses are in LinkedIn and in a dump metadata list.

Teach this as an analyst, not as a dump trafficker. You do not buy stolen databases on criminal forums as a deliverable. You do not attach full dump files to the report. You do not spray every password against production SSO on day one because "it was already leaked." Credential stuffing and password spraying are Domain 4 attacks and need RoE, lockout-safe rates, and usually a test account window. 2.1 stops at: the domain is in public breach data; employees should assume those passwords are burned; recommend unique passwords, a secrets manager, and MFA.

If RoE later allows credential testing, you still start with the client's provided test users or with hashes you obtained from in-scope systems, not with a 50 GB stealer log.

Putting OSINT on the example.com engagement

Continue the worked scenario. Passive OSINT on example.com produces:

Every row is information disclosure or a cryptographic / credential-hygiene lead. Active confirmation (live TLS on vpn.dev.example.com, whether the AWS key still works) waits for the window and, for key use, for explicit credential-testing language.

Information disclosure as the finding name

Write the report language the exam expects. "We found a Palo Alto admin job post" is a recon note. "The organization publishes current edge-vendor and identity-stack details in public hiring ads, reducing attacker effort" is a disclosure finding. "A private SSH key and cloud access key were in a public repository" is a high-severity disclosure plus credential exposure. Severity follows what an attacker could do with the leak, not how clever the Google query was.

OSINT tools (theHarvester, Maltego, Recon-ng, SpiderFoot, OSINTframework.com, Hunter.io) automate collection; they do not change the ethics. The later tools chapter covers them. For 2.1, know the sources and the decision rules.