By Xhield Team · July 1, 2026 · 12 min read
Tags: Shodan OSINT Attack Surface Infrastructure Security Pre-VAPT Penetration Testing
Five minutes. No access required.
An attacker goes to shodan.io. They type your organisation's name into the search bar.
Within five minutes — without sending a single packet to your network, without any credentials, without triggering a single alert in your SIEM — they have a complete inventory of every internet-facing service you run. Open ports. Software versions. TLS certificate details. Misconfigured dashboards. Databases with no authentication. Devices with default credentials still set from the factory.
This is not how a port scanner works. Tools like Nmap or Nessus require direct access and leave footprints. Shodan is different. It is a passive search engine that has already done the scanning for them — continuously, globally, and months before the attacker ever searched for you.
If your infrastructure is internet-facing, it is almost certainly already in Shodan's database. This post walks through exactly what an attacker finds, query by query, in five minutes — and what it means for how you scope your next VAPT engagement.
1. What Shodan actually is — and why it's different from a port scanner
Shodan is a search engine for internet-connected devices and services. It continuously crawls every routable IP address on the internet, connects to whatever ports respond, records the banners and response headers those services return, and indexes everything — making it searchable by anyone with a browser.
The critical distinction from active scanning: Shodan does not scan your infrastructure on demand. The data an attacker reads when they search for your organisation was collected days, weeks, or months ago, during one of Shodan's regular crawls. By the time a search happens, the reconnaissance is already done. The attacker is querying a historical record, not running a live probe.
What Shodan indexes covers a wide range of data points. Open ports and the services running on them. Software names and version numbers from service banner responses. TLS certificate details including all domains listed in the certificate. HTTP response headers and page titles. Device types and manufacturers — routers, IP cameras, industrial control systems, printers. Geographic location derived from IP geolocation. And ASN and organisation attribution, which maps IP ranges back to named companies.
It is also worth briefly distinguishing Shodan from its closest alternatives. Censys focuses more heavily on certificate and protocol data and has a cleaner API for programmatic queries — preferred by researchers. FOFA is widely used in Asia-Pacific threat intelligence circles and has different crawling coverage, making it a common secondary tool for attackers targeting regional infrastructure. Shodan has the widest general adoption, the richest dork query ecosystem, and the lowest barrier to entry — which is why it is almost always the first tool in a recon workflow.
2. Minute 1 — finding your organisation's footprint
The first query an attacker runs is an organisation lookup. Shodan's org: filter returns every IP address and service attributed to a named organisation through ASN data — the same registry that maps IP ranges to company names.
A single query like org:"Company Name" returns the total count of internet-facing hosts, their geographic distribution, the cloud providers in use (AWS, Azure, and GCP footprints appear separately and are identifiable), and a breakdown of which ports and services appear most frequently across the organisation's IP ranges.
A secondary query using the ssl.cert.subject.cn: filter against the primary domain surfaces all services with TLS certificates bearing the company's domain name — a reliable method for finding hosts that may not be attributed to the correct ASN in registry data, such as infrastructure hosted by third parties on the company's behalf.
What consistently surprises security teams when they run this against themselves: the total count of internet-facing hosts is almost always higher than the number recorded in their asset inventory. Cloud instances provisioned for short projects, load balancers, monitoring endpoints, staging environments, and partner-hosted services all surface in Shodan results — none of them in any scope document.
3. Minute 2 — exposed services and open ports
With the host list established, the attacker filters by port to identify the highest-value exposed services. These are the queries that produce immediately actionable findings:
org:"Company" port:3389 — Remote Desktop Protocol exposed to the internet. RDP is one of the most common ransomware entry points in enterprise breaches. An exposed RDP port with a software version banner is an invitation to credential stuffing, brute force, or known RDP exploit chains.
org:"Company" port:22 — SSH exposure. The software version is revealed in the banner. If password authentication is not disabled and key-only auth is not enforced, this is a brute-force target. If a known CVE applies to the indexed version, it is an exploit target.
org:"Company" port:6379 — Redis. Redis is designed for internal network use and frequently deployed without authentication, because the assumption is that it will never be internet-facing. When it is, an attacker can read, write, or delete the entire dataset with a single connection.
org:"Company" port:9200 — Elasticsearch. Unauthenticated Elasticsearch instances have been responsible for some of the largest data exposures in recent years. The entire index — potentially containing customer records, internal logs, or application data — is readable without credentials.
org:"Company" port:27017 — MongoDB. Like Redis, MongoDB was designed for internal use and is frequently misconfigured when exposed. Unauthenticated instances allow full database read and write access.
org:"Company" port:5432 — PostgreSQL. The database version is visible in the banner. Combined with a known CVE for that version, or weak credential policies, this becomes a direct database compromise path.
Each of these is a real finding with a direct exploitation path. A representative example of what this looks like in practice: an Elasticsearch instance exposed on port 9200, unauthenticated, with six months of customer transaction records indexed and readable — discovered during a pre-VAPT discovery exercise for a fintech client. The service was not in their VAPT scope. It had been running for eight months.
The version disclosure problem compounds every one of these findings. Even services that require authentication reveal their exact software version in the banner response. A known CVE for that precise version converts a hardened, authentication-protected service into an immediately actionable exploit target — no credentials required.
4. Minute 3 — software versions, CVEs, and the vulnerability filter
Shodan's banner collection captures software version strings from service responses as a matter of course. Apache 2.4.49. OpenSSH 7.4. nginx 1.14. IIS 8.5. Whatever the service announces when a connection is made gets stored in the index.
Shodan's vuln: filter then cross-references those indexed banners against the CVE database. A query like org:"Company" vuln:CVE-2021-44228 surfaces every host in the organisation running software that Shodan's data indicates is vulnerable to Log4Shell — instantly, without the attacker needing to know which systems the organisation uses.
The attacker does not even need to know which CVEs to look for. The has_vuln:true filter returns every host Shodan believes to be running vulnerable software across the entire organisation footprint. One query, complete vulnerability picture, no active scanning required.
This is particularly significant in the context of Indian enterprise infrastructure. Many organisations run legacy software stacks — older versions of Apache, Tomcat, JBoss, and IIS — that carry years of publicly known CVEs. The combination of Shodan's version indexing and its CVE cross-referencing makes those hosts findable in seconds, even without any other reconnaissance.
One additional feature worth noting: Shodan Monitor is a paid feature, available at low cost, that sends real-time alerts when new vulnerabilities are found in an organisation's indexed hosts. Attackers with Shodan subscriptions are notified of new exploit opportunities before most organisations know their software is affected — sometimes before patch releases are even widely announced.
5. Minute 4 — misconfigurations and default credentials
Beyond version disclosure, Shodan surfaces misconfigurations by indexing the full content of HTTP responses — page titles, login panel text, error messages, and server-generated content all get stored and become searchable.
The title: filter makes this particularly powerful. Common queries that surface misconfigured or unprotected services:
title:"Dashboard" org:"Company" returns admin dashboards indexed by Shodan. Grafana, Kibana, and Jenkins instances with default or absent authentication appear regularly in these results — dashboards that were intended for internal access only and ended up reachable from the internet during a cloud migration or network reconfiguration.
title:"Welcome to nginx" finds servers running a default nginx configuration — indicating a host that was provisioned and connected to the internet but never properly configured. These are frequently forgotten cloud instances still running and billable, with no monitoring and no security controls.
http.title:"Kibana" specifically surfaces Kibana log analysis dashboards. Kibana is routinely deployed without authentication in internal network environments where it is assumed to be unreachable from outside. When those networks expand into cloud, the assumption breaks — and the dashboard, containing potentially sensitive log data, becomes publicly accessible.
Default credential exposure is the final layer. Many network devices, IoT appliances, and older enterprise software products respond to Shodan's crawler with login pages that advertise the exact device model and firmware version in the page title or response headers. An attacker can look up the default credentials for that model from the manufacturer's public documentation and attempt login without any additional reconnaissance.
For organisations with operational technology — manufacturing facilities, utilities, building management systems — Shodan also indexes SCADA systems, human-machine interfaces, and industrial protocols including Modbus, BACnet, and MQTT. These systems were designed for isolated networks and frequently have no authentication at all. Shodan finds them when they are connected to the internet, and their presence in results is an immediate critical finding in any security assessment.
6. Minute 5 — TLS certificates, cloud misconfigurations, and the full picture
TLS certificate data stored in Shodan reveals more than domain names. Certificate Subject Alternative Names — the full list of domains and hostnames covered by a certificate — frequently include internal hostnames, development environment names, and occasionally internal IP addresses that were added to certificates issued for external services, then forgotten.
Expired certificates surface as a distinct signal. A TLS certificate that has lapsed on an internet-facing service indicates a host that is not being actively maintained or monitored — a strong signal that it may also be behind on patches, may have weaker access controls, or may have been forgotten entirely by the team responsible for it.
Cloud-specific misconfigurations extend Shodan's reach into storage and object access. A query for org:"Company" http.title:"Index of /" surfaces directory listings across the organisation's entire internet footprint — open S3 bucket listings, Azure Blob storage containers with public access enabled, and GCP storage endpoints with browsable contents, all indexable and searchable through the same interface.
By the end of minute five, an attacker has a prioritised attack list. Hosts with known CVEs sit at the top. Exposed databases and RDP services come second. Misconfigured dashboards and default-credential devices follow. Every item on the list has an IP address, a port, a software version, and in many cases a specific CVE or exploitation technique already identified.
The entire process was passive. It required no special access, no direct connection to any of the organisation's systems, and left no trace in any log file anywhere in the infrastructure.
7. What this means for your VAPT scope and pre-engagement process
Shodan is free to use at a basic level. It requires no special skills, no hacking tools, and no inside knowledge of the target. If your organisation's internet-facing infrastructure has not been reviewed through Shodan's lens, you are operating with a blind spot that any motivated attacker can see around.
The connection to VAPT scope is direct. Every host Shodan returns for your organisation is a testable surface. If it is not in your scope document, it is not being tested — regardless of how many open ports it has, what software version it is running, or which CVEs apply to it. A clean VAPT report that does not reflect Shodan's view of your infrastructure is a report built on incomplete data.
The pre-VAPT use case is straightforward: run Shodan against your own ASN and domain certificates before any scoping conversation with a vendor. The results tell you what the attacker's starting point looks like. That is the right foundation for building a scope document that reflects your actual risk, not the subset of your infrastructure that happened to make it into an asset inventory.
8. Defender checklist — running Shodan against yourself
Before your next VAPT engagement, run these five queries against your own organisation:
Step 1 — Establish the footprint. Query org:"Your Organisation Name" and note the total host count. Compare it against your asset inventory. The gap between those two numbers is your current blind spot.
Step 2 — Filter for high-risk ports. Check for port 3389, 22, 6379, 9200, 27017, and 5432 within your organisation's results. Any host that returns results for these ports is an immediate investigation priority — confirm whether exposure is intentional and whether authentication is properly enforced.
Step 3 — Check for known vulnerabilities. Filter your organisation's results by has_vuln:true. Cross-reference every host returned against your patch management records. Any host Shodan believes to be running vulnerable software that is not in your current patch cycle is a critical gap.
Step 4 — Search for misconfigurations. Query your organisation filtered by common misconfiguration page titles — Dashboard, Admin, Login, Index of. Flag anything that returns results and should not be publicly accessible.
Step 5 — Set up continuous monitoring. Shodan Monitor on your IP ranges and domain certificates provides passive, continuous alerting when new hosts appear in your footprint or when existing hosts acquire new vulnerability associations. At minimal cost, this is one of the highest-value passive security controls available to any organisation.
Every host discovered through this process belongs in your VAPT scope document. The scope should reflect what Shodan sees — not what was remembered when someone last updated a spreadsheet.
See your infrastructure the way an attacker does — before they do. Start with xhield →
Related reading: