The importance of OSINT

At a time when cyber attacks are becoming more sophisticated and targeted every day, a holistic view of your own IT attack surface is essential. Many companies already invest in regular penetration tests to check their systems and applications for vulnerabilities.

However, what is often overlooked: The first step of a real attacker is usually not active scanning, but passive information gathering. Also known as Open Source Intelligence (OSINT) or Passive Reconnaissance.

This phase is not included at all or only insufficiently in many classic penetration tests, although it could be of central importance for the overall effectiveness of a test. In this article, we explain why companies should consider passive reconnaissance before an active penetration test and how this can reveal significant gaps in the security concept.

What is Passive Reconnaissance (OSINT)?

Passive reconnaissance describes the systematic collection of publicly accessible information about a target system or a company. Only passive techniques are used that do not require direct contact with the target infrastructure. This means that there is no active interaction with a company’s target systems. Neither port scans nor social engineering or technical requests to servers or services.

This purely observational approach is essential, as it is also preferred by real attackers. The aim is to obtain security-relevant information anonymously and unnoticed without alerting the potential target to an impending attack. SIEM systems or Security Operations Centers (SOC) in particular often raise the alarm in the event of suspicious network activity or active port scans.

Passive reconnaissance avoids such signals almost completely. It is a non-invasive method that relies on publicly accessible data sources, i.e. information that is already available on the internet and can be viewed by anyone. It simulates how a real attacker would use openly available tools and sources to scout out the target. The aim is to find out as many details as possible about IT systems, employees, subdomains and other potentially vulnerable components.

Why is OSINT so crucial for penetration testing?

Many companies rely on internal asset lists and use them to define the scope of a penetration test. However, the reality is often different. Attackers do not rely on internal asset lists, but use what they can obtain from the Internet. This results in a discrepancy between the actual attack vector and the officially tested scope.

A passive OSINT analysis can help to close this gap. It identifies systems and information that a company may not have on its radar as audit-relevant, but which are nevertheless vulnerable.

These often include:

• Obsolete or forgotten DNS entries and subdomains that still point to productive or test systems
• Active IT systems that are not recorded in internal asset lists, for example due to a lack of inventory, shadow IT or very large IP address ranges that have not been fully recorded
• Accessible TCP and UDP network services that have been unintentionally exposed, for example due to misconfigurations in the firewall or cloud security groups
• Test and development environments (UAT/DEV) that were published without authentication or hardening due to time constraints
• Unprotected interfaces and APIs, for example from partner agencies, marketing tools or external portals
• Leaks of employee data, including valid access data to productive IT services such as SSH, FTP, CMS systems (e.g. WordPress, Joomla) or admin backends
• Obsolete IP address ranges that are officially out of service but still contain systems that are accessible and vulnerable to attack

Only the combination of passive OSINT and active penetration testing provides a comprehensive picture of the real attack surface.

Which data sources are used?

As part of an OSINT analysis, numerous specialized sources and tools are used to create as complete a picture as possible of the publicly available information about a target organization.

The following is an overview of key techniques:

• Search engines and Google Dorking
  • Sensitive files, archived pages or development instances can often be tracked down using targeted search queries. Backups, outdated endpoints or unprotected websites can be identified.
• io and Censys.io
  • These search engines index publicly accessible hosts and services. This allows passive insight into known IP addresses, domains and open ports as well as the identification of software used, including versions and known security vulnerabilities (CVEs).
• Certificate Transparency Logs and DNS brute forcing
  • By analyzing publicly available SSL certificate logs and active DNS brute forcing, subdomains and hostnames that a company is actively using or has used in the past can be discovered. This information helps to identify hidden VHost applications through to internal web services.
• Social networks and business platforms (LinkedIn, Xing, GitHub)
  • Employee information can be obtained in various ways and then used during the active phase of a penetration test. Be it social engineering, phishing or the simple brute force attack on login interfaces (FTP, SSH, HTTP, etc.). The last point in particular is carried out inadequately by pentesting companies, as often only standard lists of known usernames are used. However, these are not or insufficiently adapted to the company to be tested and its employees.
• Leaked credentials and stealer logs
  • Publicly leaked access data can be found via leak platforms, special forums and the darknet. Often including passwords in plain text, which in the worst case can also be reused for company services such as VPN, FTP, SSH or other login interfaces.

Why pure IP scans alone are not enough

A common misconception about penetration testing is that scanning an IP address or subnet is enough to identify potential vulnerabilities. However, this approach often falls short in modern IT infrastructures.

Reverse proxies, load balancers or API gateways are used in many architectures today. These components do not route incoming requests across the board based on the IP address, but depending on the host name transmitted in the HTTP header. This principle is known as virtual host routing.

The consequence: if an IP address is addressed without the corresponding host name, the server often only returns a standard response, a redirect or even no application at all. The actual web service, such as a customer portal, an administration interface or an API, remains hidden, even though it is technically accessible. Without knowledge of the specific subdomains, relevant web applications or APIs cannot be identified and comprehensively tested. In practice, this means that critical vulnerabilities remain undetected, even though they could actually be attacked from the internet.

Passive reconnaissance is therefore of central importance in order to identify valid hostnames and subdomains before active tests are carried out. This is the only way to ensure that all relevant applications are checked. Regardless of whether they are listed in the company’s asset inventory or not.

Practical example: V-Host routing and forgotten subdomain

A company commissioned a penetration test for its public IT infrastructure. In addition to the /22 IP address range, an accessible Nextcloud instance under “cloud.firma-example.de” was also mentioned. This was an important application for exchanging documents with partners and customers and was to be analyzed in a focused manner.

During the tests, it was determined that the application was properly implemented, patched up to date, equipped with strong authentication including MFA and additionally protected by a WAF system. During the passive reconnaissance, however, it was noticed that a second subdomain was known – namely “cloudadm.firma-example.de”.

The subdomain could be resolved to the same IP address of the Nextcloud host via DNS. A targeted HTTP request with the corresponding host header revealed that there was an undocumented Apache Tomcat web application behind this subdomain. This instance was outdated and had default passwords. Remote code execution (RCE) allowed the Tomcat instance to be fully compromised. As both web applications were running on the same server, the attacker was able to access the entire server from the compromised Tomcat instance and therefore also completely take over the Nextcloud instance.

This fictitious example, based on potentially real incidents, illustrates the importance of passive reconnaissance (OSINT) in the run-up to a penetration test on external IT infrastructures.

Is an OSINT phase a mandatory part of a penetration test?

No. A comprehensive OSINT analysis is always optional and not a mandatory component of a classic penetration test. Each test can also be carried out solely on the basis of the scope provided by the customer.

In this case, however, the penetration testers rely entirely on the information provided to them by the client. This means that there is no independent validation or expansion of the scope by the testers. If a subdomain, system or IP address has not been named or overlooked by the customer, it will not be tested. Even if it is publicly accessible and would represent a realistic target for attack.

An upstream passive reconnaissance, on the other hand, ensures that the scope is validated from the perspective of an external attacker and, if necessary, expanded before the actual active penetration test with its fixed scope starts. This prevents outdated, forgotten or undocumented systems from falling under the radar.

Conclusion: OSINT as a strategic add-on for penetration tests

Passive reconnaissance is not just an add-on, but a crucial phase in the preparation of a thorough penetration test. Without this phase, there is a risk that companies will be left with a false sense of security, as key points of attack remain untested simply because they are not known or documented internally.

By using professional OSINT techniques, you get:

• A realistic view of your digital image
• An extended asset list for the active test
• Early indications of forgotten or unsafe systems
• The ability to react in front of real attackers

Whether as a stand-alone cyber security check or as an upstream add-on to a comprehensive penetration test. We recommend that every company plans this step proactively. The information gained is a crucial building block for a robust security strategy.

You can add our OSINT package as an optional add-on during your penetration test configuration. Preferably for penetration tests on your public and externally accessible IT infrastructure.