484,956 Exposed Servers. SecurityClaw Found Them in Under 3 Seconds — Without Sending a Single Packet.

The Five Queries — 2.95 Seconds, 484,956 Exposed Systems

Every one of these counts represents a real service accessible on the public internet — indexed by Shodan's continuous global crawl, not by any probe this demo sent. From an attacker's perspective, each number is a candidate target list. 234,147 Redis instances means 234,147 potential starting points for session token theft, credential extraction, or remote code execution via Redis config abuse.

The Raw Output

Query 1: Jupyter Notebooks — 2,191 Exposed, Unauthenticated Code Execution

The Beijing host is the standout finding. A single Shodan lookup reveals a server running Jupyter Notebook 6.4.10 (unauthenticated, CVE-2022-29238 flagged) and an Ollama LLM server on port 11434 — also unauthenticated. An attacker reaching this server gets arbitrary Python execution on the host machine, plus free inference access to whatever LLM model the operator has loaded. The server owner was presumably running AI workloads and hadn't considered that both services were reachable from the public internet.

CVE-2022-29238 in Jupyter Notebook 6.4.10 is a path traversal vulnerability allowing authenticated users to read arbitrary files on the server. In a deployment with no token authentication, "authenticated users" means anyone who can reach port 8888.

Query 2: Redis — 234,147 Exposed Instances

The Microsoft Corporation entry isn't an error. It's an Azure-hosted instance with Redis publicly bound. Cloud providers aren't immune to the same default-configuration problem as any other hosting environment. A Redis instance on Azure infrastructure is still a Redis instance if it's bound to 0.0.0.0.

What an attacker can do with an unauthenticated Redis instance:

• Read: KEYS * → enumerate everything in memory. Session tokens, API keys, rate limit counters, job queues, cached user data — all readable in seconds
• Write: Inject arbitrary data. Poison session caches, insert malicious jobs, manipulate rate limit counters (effectively bypassing application-level rate limiting)
• Execute: CONFIG SET dir /root/.ssh + CONFIG SET dbfilename authorized_keys + SET payload "ssh-rsa ATTACKER_KEY" + BGSAVE → SSH key written to server. This technique dates to 2015 and remains effective against exposed Redis instances

For applications that use Redis to store JWT tokens or session identifiers, unauthenticated Redis access is effectively equivalent to account takeover at scale — read every active session token, use any of them. Hacking APIs by Corey Ball has a thorough chapter on token-based session attacks that puts this attack surface in full context.

The Host Deep-Dive — One Server, Complete Profile, Zero Packets

shodan-intel's host lookup command builds a complete target profile from Shodan's existing database. No connection to the target is made.

Single command. One second. Complete target profile. This is the reconnaissance picture an attacker has before they've done anything active. From this output they know:

• The OS (Ubuntu, inferring from OpenSSH 8.9p1 packaging)
• Two exploitable services with known vulnerabilities and no authentication
• The hosting provider (UCloud — useful for understanding network geography and potential IP blocks)
• When Shodan last confirmed the exposure was still live (March 14, 2026)

An attacker could walk into this server with a browser. No exploit required — open the Jupyter UI at http://117.50.162.9:8888, run code, read files, exfiltrate data, establish persistence. The Ollama endpoint at :11434 is a bonus: free inference access to whatever model is loaded, potentially revealing sensitive data the operator has fed through the LLM or enabling prompt injection attacks on downstream applications.

The Honest Misses — Three Things shodan-intel Gets Wrong

The Peng principle: document what didn't work. SecurityClaw's shodan-intel skill has three real limitations that anyone using it for security work needs to understand.

Miss 1: Data Freshness

Shodan re-crawls the internet continuously, but not in real time. The gap between a service being exposed and appearing in Shodan's results can be hours to days. Similarly, a server firewalled or patched yesterday may still appear as exposed in Shodan's index. Every Shodan result is a historical data point — some hours old, some days old, some weeks old for low-priority hosts.

What this means in practice: Shodan results are the right place to start reconnaissance, but not the right place to stop. Before acting on a finding (in an authorised assessment or against your own infrastructure), verify the service is still live and still accessible. A "clean" result from Shodan doesn't confirm you've remediated an issue — only a live probe does.

Miss 2: Authentication Confirmation

Shodan's banner grab records what a service presents on connection — not whether that service is secured behind authentication. A Redis instance showing 234,147 results includes instances where Shodan's crawler connected successfully (confirming the port is open), but where Redis may have AUTH configured at the application layer. Shodan doesn't attempt authentication; it just reports that the service responded.

What this means in practice: The 234,147 Redis count is an upper bound on exposed instances. The actual number with no authentication is lower — but without attempting a connection, you can't distinguish "accessible Redis with no auth" from "accessible Redis with auth enabled." Shodan gives you the candidate list. Verification gives you the confirmed list.

Miss 3: Kibana Query Syntax Gap in the SecurityClaw Script

This one's a process miss we're documenting openly. The Kibana query (product:Kibana http.status:200) returned 0 results via the SecurityClaw search script's internal query handler, while shodan count 'product:Kibana http.status:200' run directly confirmed 10,496 results exist. The issue: complex multi-filter Shodan queries require different quoting and encoding between the Python SDK's search() method and the CLI's count command. The SecurityClaw shodan-intel skill script needs a query normaliser for multi-filter syntax. We used the direct CLI count for the Kibana number — which is slightly outside the standard campaign pipeline.

The Kibana count is real; the script gap is real. Peng has queued a fix. This is exactly the kind of honesty that separates a useful security tool from a marketing tool — a result of 0 when 10,496 exist is the worst possible outcome, and it needs to be documented and fixed rather than buried.

The Attack Chain: Shodan Is the Start, Not the End

Shodan's power isn't the query results in isolation — it's what those results enable as Step 1 in a multi-stage attack chain. Here's the chain from D17 through D15 and D14:

No zero-days. No sophisticated exploits. The entire chain runs on default configurations, weak credentials, and a service that should never have been internet-accessible. Shodan is how an attacker finds the phpMyAdmin panel they didn't know existed. Before this demo, the server owner didn't know it was listed in Shodan's index. The attacker found it in the same query that found the other 45,523 exposed phpMyAdmin panels.

For a ground-up understanding of how attackers build these chains from passive recon to active exploitation, the reconnaissance and information gathering chapters in The Hacker Playbook 3 by Peter Kim cover this methodology in detail — including OSINT sources, target profiling, and attack chain construction from public data.

What Defenders Do About This

Every item in this section is a concrete action, not a generic recommendation.

1. Claim Your Own Shodan Exposure First

Go to shodan.io and search your organisation's IP ranges and domain. org:"Your Company Name" or hostname:.yourcompany.com will show everything Shodan has indexed about your externally visible infrastructure. What Shodan sees is what attackers see. If you haven't done this recently, do it before finishing this article.

SecurityClaw's shodan-intel skill can run this scan programmatically across your entire IP range — generating a prioritised list of every exposed service that appears in Shodan's index, with CVE correlation included.

2. Fix Redis in Two Lines

In redis.conf:

If Redis must be accessible from other hosts, bind to the specific internal IP only. Never 0.0.0.0 for a service storing session tokens or credentials. If you use Redis on a cloud VM, add a security group rule that allows port 6379 only from your application server's IP — not from 0.0.0.0/0.

3. Jupyter: Tokens Are Not Optional

Always start Jupyter with authentication:

Never bind to 0.0.0.0 unless running behind an authenticated reverse proxy. If you run Jupyter on a cloud instance for remote access, use SSH tunnelling (ssh -L 8888:localhost:8888 user@server) rather than exposing the port. JupyterHub with OAuth is the right solution for multi-user environments.

4. MongoDB: Enable Authentication, Restrict Binding

In mongod.conf:

MongoDB's 2019 data breach wave (hundreds of millions of records exposed and held for ransom) was almost entirely the result of default configurations without authentication. MongoDB now ships with --auth recommended in documentation, but existing deployments and some automated build pipelines still skip it.

5. phpMyAdmin: Should Not Be Internet-Accessible

phpMyAdmin is a database administration tool. It should be accessible from your internal network or via VPN — not from the public internet on port 8080. If you need remote database administration, use an SSH tunnel to the database host, not a web-based admin panel reachable from anywhere. If phpMyAdmin must be accessible externally, put it behind HTTP basic auth in addition to its login page, restrict access by IP, and enable two-factor authentication.

For YubiKey-based 2FA for SSH access to production servers (protecting the underlying infrastructure that hosts all of these services), YubiKey 5C NFC supports FIDO2/WebAuthn and works with most Linux PAM configurations — the same hardware key protects SSH, admin web interfaces, and cloud console access.

SecurityClaw Scorecard: D17

D17 opens a new category in SecurityClaw's demo series: OSINT & Recon. It's a different kind of demo than the active scanning campaigns — no target server was probed, no payload was sent, no port was opened. The skill queries public data that already exists. That's what makes passive OSINT both legally clean and practically powerful: the intelligence is already out there.

2.95 seconds. 484,956 results. Zero packets sent. This is the reconnaissance picture an attacker builds before they've done anything active. Every one of those 234,147 Redis instances is a server where the owner has no idea it's in Shodan's index — or had no idea until they ran this query against their own IP range.

The goal of running SecurityClaw's shodan-intel skill against your own infrastructure isn't to find things to exploit. It's to see your attack surface the same way an attacker would — before they do. What Shodan knows about you is your externally visible exposure. You should know it better than your adversaries.