OSINT Techniques for SaaS Engineering Team Targeting

OSINT that targets SaaS engineering teams follows a chain that is easy to predict, from public profiles and repository histories to exposed services and leaked credentials. The strongest defense is to walk that chain before an attacker does. That means finding what outsiders can learn, connecting it to real assets and identities, and using the results to guide testing.

Why SaaS engineering teams are the highest-value OSINT target before an attack begins

LinkedIn profiles name technology stacks, GitHub commits show how teams develop software, and a few email addresses can reveal the pattern a company uses to name them. These clues connect people to systems and responsibilities. For an attacker, a developer is therefore more than a possible phishing recipient. That person’s public footprint can provide the starting point for a structured reconnaissance chain.

Lazarus Group’s Operation 99 makes that choice explicit. Fake recruiter profiles on LinkedIn target individual software developers with offers of freelance project tests and code reviews. The approach uses the developer’s professional role as its opening. Before any payload is crafted, passive research can draw on certificate transparency logs, paste sites, breach databases, document metadata, and archived pages without leaving logs on the target’s systems. An engineering leader looking only at the company’s website sees a much narrower picture than the attacker does.

How a structured four-phase OSINT workflow maps a SaaS team's attack surface before active scanning begins

A defender can organize this work into four phases, namely passive discovery, asset correlation, intelligence enrichment, and prioritized risk output. The first phase establishes what public sources already reveal. TheHarvester queries Google, Bing, certificate transparency logs, and more than 40 other sources for emails, subdomains, and IP addresses. At the same time, structured Google searches look for indexed files and exposed content without sending traffic to the target’s systems. Discovery begins outside the company’s own inventory.

In the second phase, Amass performs deep DNS enumeration, subdomain discovery, certificate transparency analysis, and ASN lookups, stitching the results into an asset graph. Maltego maps relationships among domains, email addresses, IP addresses, company names, and social profiles. Those connections explain who and what belong together. Shodan then uses banners, certificates, and OS fingerprints to build service profiles for the IP addresses found, with version numbers that can be checked against known CVEs.

The third phase adds context that a hostname or address cannot supply alone. Recon-ng supports modular deeper investigation, while Metagoofil downloads publicly indexed documents and extracts embedded metadata, including usernames, internal file paths, OS versions, and software names. Such details can expose internal conventions useful for social engineering. Context changes how a finding is interpreted. An email naming pattern, for example, can connect an address to a LinkedIn profile with job history, reported technology preferences, and organizational relationships.

The fourth phase produces an accurate asset inventory and a prioritized view of risk. It is not simply an export of everything collected. It shows which findings need active testing and why. A previously unknown service and an employee identity linked to that service offer more direction together than either does alone.

What theHarvester and Shodan reveal about a SaaS team's exposed infrastructure in practice

A representative theHarvester run can return jenkins.acmecorp.io and api-internal.acmecorp.io together with employee email addresses. Those names are early clues to internal tooling that needs a closer look. They do not, by themselves, prove a vulnerability. But they give the defender a concrete comparison to make against the internal asset inventory, and anything missing from that inventory becomes a shadow asset requiring attention. Unknown assets are especially risky because patching and monitoring cannot reliably cover systems no one knows exist.

Shodan adds a different kind of evidence. Where theHarvester supplies names and addresses, Shodan can supply service banners, certificates, OS fingerprints, and version details for discovered IPs. For a hostname linked to an internal tooling service, the name is the first clue, while the service data at hand helps show what is actually exposed. The distinction prevents a suggestive label from becoming an unsupported conclusion. Version information can then direct testing toward relevant known CVEs.

Structured Google searches can also show what is exposed. The useful operator families cover scoping, files and content, authentication surfaces, technology fingerprinting, and leak detection. A single .env file can expose APP_KEY, DB_PASSWORD, AWS_SECRET_ACCESS_KEY, and STRIPE_SECRET together, turning one search result into several possible routes to access. In a well-scoped external penetration test, this work can surface findings that active scanning would take days to reach. Infrastructure discovery is only one track, however, because credential exposure runs beside it.

How leaked credentials and GitHub commit history extend the attack surface from infrastructure to identity

An employee email address links infrastructure discovery to identity research. Breach databases and paste sites can associate that address with a breach source, a plaintext or hashed password, and an exposure date. If an exposed password follows a pattern that is easy to guess, a password reset may leave that pattern in place. That is why the consequence of a leak extends beyond whether the original credential still works.

The transition from research to access can be short. A matched credential used against a discovered VPN endpoint can provide authenticated entry if MFA is not enforced. No software exploit is required in that case. This is also the boundary between passive OSINT and active access. The infrastructure track identifies the door, while the identity track may supply a working means of entry.

GitHub commit history adds context independently of breach records. Public repositories can reveal API paths, environment names, internal naming conventions, CI/CD references, and sometimes live secrets. Revoking a secret removes its direct usefulness, but the surrounding code can still explain infrastructure topology. Document metadata can add usernames, internal paths, OS versions, and software names to what is known. Together, these sources form durable identity intelligence that can support a convincing pretext even after an individual credential has been replaced.

Why hardcoded secrets in repositories represent the sharpest single point of compounding risk

“Private” is an access boundary that can be misconfigured or breached, and internal repositories are significantly more likely to contain hardcoded secrets than public ones. Restricted visibility does not neutralize the credential itself. A key in code is still a risk if someone gets to that code and the key still works. Repository access and credential safety are different problems.

GitGuardian’s data shows that new hardcoded secrets detected in public GitHub commits recorded their largest single-year jump in 2025. Its data also shows an especially sharp surge in AI service credential leaks driven by ungoverned adoption of API keys for platforms including OpenAI, Supabase, DeepSeek, and OpenRouter. The risk grows with each integration cycle. Each service added brings another credential class, and older exposed secrets stay part of the attack surface until they are dealt with.

The remediation gap makes that growth compound. Many secrets that were confirmed valid years ago can still be exploited today, so new leaks leave the risk from old ones in place. They accumulate beside them. An attacker does not need to exploit an AI service when an exposed API key already provides access to the infrastructure that key touches. Rotation and auditing are what shrink this exposure, and understanding the chain becomes useful only when defenders can walk it against their own organization.

How to run this OSINT chain defensively — walking the attacker's path before they do

For defenders, the practical response is a sequenced self-assessment of their own domains and identities. Begin with theHarvester against the primary domain and every known subsidiary domain. Compare every returned hostname with the internal configuration management database, or CMDB, and flag missing entries for immediate triage.

Next, look up the IP addresses found in Shodan and check the service banners it has against known CVEs. This gives the hostname findings a service-level context. Lock exposed internal tooling, including CI/CD systems, admin panels, and staging environments, behind a VPN or zero-trust gateway. A familiar hostname is not proof of safe exposure. The review needs to connect what a system is called with what outsiders can learn about its running services.

Then run structured Google searches across the full web estate, including subdomains and affiliated domains. Look for exposed environment files, open directory listings, indexed credentials, and authentication surfaces. These searches cover exposure that an IP-focused review can miss. Throughout this work, keep track of what has been found and what there is permission to test. Even without direct testing, an out-of-scope asset can show risks through its naming conventions, shared infrastructure, authentication patterns, and references to old technology.

After that, run breach and paste lookups against every employee email in the directory on a recurring schedule. Any match should trigger a forced password reset and verification of MFA enrollment. The follow-up is essential to the search. A record of leaked credentials is not a defensive result unless the affected access is addressed. Recurring lookups also reflect the fact that identity exposure is not fixed at the moment of an annual review.

Next, audit public and internal repositories with automated secret scanning that runs in the CI/CD pipeline on every pull request. Rotate and audit exposed secrets to remove the access they allow, even when the code has been removed. Then use Metagoofil to extract metadata from publicly indexed documents and assess the internal naming conventions, software versions, and infrastructure details they reveal.

One unexpected relationship can change the understanding of the estate more than a large collection of unexplained results. The internal sweep reveals the gap between what the security team believes is exposed and what an outsider can see. Visibility alone cannot establish the full consequence of that gap. A rigorous penetration test is designed to measure and close it.

What a rigorous penetration test adds that a self-directed OSINT sweep cannot provide

Self-directed OSINT establishes what is visible, while a rigorous penetration test proves what is exploitable. A qualified external test goes further with whitebox access to source code, cloud configurations, and internal documentation. That access makes service interactions, authentication logic, privilege escalation chains, and the second-order effects of chained vulnerabilities available for examination. Passive research cannot reach all of those paths. Its findings supply entry points.

The documented Path to Compromise makes the difference concrete. It begins at a specific entry point exposed by OSINT, moves through specific findings in a defined order, and reaches an objective relevant to the business. Every finding in that path is supported by a working exploit. The sequence is the proof of consequence. It shows how separate weaknesses combine, rather than leaving the reader to infer the connection from a collection of findings.

That proof still reflects a point in time. Shadow assets can appear between annual tests, credentials can leak after the last scan, and new AI integrations can introduce credential classes absent from the previous scope. Continuous pull-request scanning therefore complements periodic deep testing. Compliance sets a minimum. The stronger standard is a test informed by what a capable outsider could learn without authorization, followed by authorized testing that proves what they could do with it.