Your live camera is already indexed: IoT devices and your digital footprint
Geert WarmenbolApril 29, 2026
Key takeaways
An internet-connected camera or sensor node appears in Shodan or Censys within 24 to 72 hours of first connection — no active scanning by the attacker required.
Hardcoded credentials in a public GitHub repository remain exploitable years after the commit, even if the repo is later made private or the file is deleted — git history persists.
Wayback Machine snapshots of old API endpoints have been used in real assessments to reconstruct authentication flows that were never formally decommissioned.
In Vulnox digital footprint assessments of small businesses running IoT-connected hardware, over 60 percent had at least one device reachable on a public IP that the owner believed was on a private network.
The threat model for a live-streaming camera is not someone watching your plants — it is the device becoming a pivot point into the same network segment as your point-of-sale system, inventory database, or payment processor.
Default credentials on ESP32 or similar microcontroller web interfaces are indexed and tested automatically by bots within hours of a device appearing in Shodan results.
TL;DR
Running a live camera or sensor dashboard for your farm, store, or workspace feels like a feature. From a reconnaissance perspective, it is a published advertisement for your internal network configuration. Shodan indexes it. Bots test the default credentials. If a developer ever pushed a config file to a public repo, the Wi-Fi password and API key are probably still findable. This article explains exactly how that chain works — and what to do about it before someone else finds it first.
The camera went live on a Tuesday
Plant Mood runs a hydroponic microgreen operation out of Bangkok. Like a growing number of small urban farms, they built a live stream using an ESP32-CAM so customers could watch the sunflower trays grow in real time. The stream ran off their business Wi-Fi. The device got a public IP through their router''s port forwarding. The founder thought of it as a marketing feature — proof of freshness, proof of process. It was live for four days before we ran a passive footprint check as part of a consultation.
The device was already in Shodan. The default web interface was reachable on port 80. The module was identified as an AI-Thinker ESP32-CAM running a stock firmware build. No authentication on the stream endpoint. A second result showed the same IP appeared in a Censys scan three days earlier. The business owner had no idea any of this was visible. She thought the stream was just a URL she shared with customers.
How passive reconnaissance actually works on an IoT device
Shodan and Censys are not attacker tools in the conventional sense. They are search engines that continuously scan the public IPv4 space — all 3.7 billion addresses — and store banners, headers, TLS certificates, and service fingerprints. They do this without targeting anyone. The moment a device gets a routable IP and a listening port, it will be catalogued. The average time from first connection to first Shodan index entry, based on documented honeypot research published by Palo Alto Unit 42, is under 24 hours for common ports like 80, 8080, and 554 (RTSP, the protocol many camera modules default to).
Example
An ESP32-CAM running the default AI-Thinker firmware exposes a web server on port 80 with an endpoint at /capture for still images and /stream for the MJPEG feed. Neither requires authentication by default. The HTTP response headers identify the firmware version. Shodan stores that banner. Anyone searching Shodan for ''ESP32'' or ''AI-Thinker'' and filtering by country or city gets a list of reachable devices — including exact IPs, open ports, and identified firmware. That search takes about 11 seconds.
RTSP streams on port 554 are a separate exposure vector. Many camera firmwares expose both an HTTP interface and an RTSP feed. RTSP streams often accept anonymous connections by default. Tools like VLC or ffplay can connect directly to rtsp://[IP]:554/stream without any credentials. This is not a theoretical attack — it is how consumer IP cameras have been scraped and rebroadcast on sites like Insecam for years.
What the data showed across small business assessments
Assessment base: Vulnox digital footprint assessments, 2023 to 2024, small business and maker-operated IoT environments across Southeast Asia and Europe
Devices believed to be on private networks were publicly reachable
In digital footprint assessments covering small businesses running IoT hardware — point-of-sale environments, small farms, retail operations with smart sensors — more than 60 percent had at least one device with a public-facing IP the owner did not know existed. The most common cause was automatic UPnP port mapping. The router opened the port on the device''s behalf because UPnP was enabled by default and the firmware requested it. Nobody configured this deliberately.
The owner''s mental model was ''the camera is on my local network.'' The actual state was ''the camera is on my local network AND reachable at a public IP via port 8081.'' These are not the same thing. The risk is not just the camera — it is what else lives on that same network segment.
GitHub commit history exposed credentials long after repos were cleaned up
In two separate assessments involving maker-built or freelancer-built IoT setups, we found hardcoded Wi-Fi SSIDs, passwords, and API keys in public GitHub repositories. In one case, the repository had been made private six months earlier. The credentials were still indexed by GitHub''s own search cache and by third-party tools that mirror public commit history. In the other case, the developer had deleted the file containing the secrets but had not purged the git history. The credentials were recoverable in under three minutes using standard git log commands on a cloned copy taken before the deletion.
''I deleted the file'' does not mean the credentials are gone. Git is an append-only ledger by design. Once a secret is committed to a public repository — even briefly — it should be treated as permanently compromised and rotated immediately. The window between a commit and a bot harvesting it is measured in minutes, not days.
Wayback Machine surfaced decommissioned API endpoints that still accepted requests
During one footprint assessment for a small e-commerce operation that had added IoT inventory sensors, we queried the Wayback Machine for archived versions of their domain. A snapshot from 14 months earlier showed a /api/sensor/push endpoint documented in an old setup guide they had posted publicly. The endpoint was no longer linked anywhere on the live site. It still worked. It accepted POST requests with no authentication and wrote directly to their inventory database.
Decommissioning a feature from your frontend is not the same as removing it from your backend. Old API endpoints referenced in public documentation, cached in search engines, or archived by the Wayback Machine are fair game for anyone running a standard reconnaissance pass. If the endpoint still resolves and still responds, it is still an attack surface regardless of whether anyone on the current team remembers it exists.
Network segmentation assumptions were wrong in most setups
The most dangerous configuration we see in small business IoT setups is not the exposed camera itself — it is the flat network. The camera, the point-of-sale terminal, the back-office PC, and the guest Wi-Fi all sit on the same subnet. An attacker who reaches the camera via a public IP and pivots through it has line-of-sight to everything else on that network. In the Plant Mood consultation, the ESP32-CAM shared a /24 subnet with the laptop used to place supplier orders. That laptop had saved credentials for the supplier portal in a browser profile.
The threat model for a compromised IoT device is not ''someone watched the plants.'' It is ''someone used the camera as an entry point, scanned the local subnet, found the order-management laptop, extracted the browser credential store, and logged into the supplier account.'' That is a realistic attack chain from a single misconfigured port forward.
The private stream URL does not protect you
Common belief
Many small business owners running live cameras believe that because they have not publicized the stream URL, it is effectively private. The logic is: if no one knows the address, no one can access it. This feels reasonable. It is wrong in a specific and important way.
What we found
In the Plant Mood assessment, the founder had shared the stream URL with customers via a newsletter link. She believed this was fine because ''the URL is long and hard to guess.'' The URL was /stream — the default path for AI-Thinker ESP32-CAM firmware. It appeared in the first Shodan result alongside the device''s IP. The URL offered no meaningful protection.
Security through obscurity fails the moment a device is indexed. Once a Shodan or Censys crawler hits your IP and identifies the camera firmware, the stream URL path is already known — it is part of the firmware''s documented default configuration, not something unique to your device. An attacker does not need to guess your URL. They query Shodan for your firmware type, get your IP, and append /stream or /video or whatever path that firmware version exposes by default. The URL was never secret. Only the IP was, and that stopped being secret within 48 hours of first connection. The correct model is: assume the URL is known and require authentication regardless.
What small business operators consistently miss
UPnP automatic port mapping
Universal Plug and Play is enabled by default on most consumer and small business routers. IoT devices — including ESP32 modules running certain firmware builds — can request that the router open a port on their behalf without any user action. The device asks, the router agrees, the port is open, and no one in the business knows. Disabling UPnP on the router closes this vector entirely. Checking whether it is currently enabled takes about 90 seconds in the router admin panel.
Firmware default credentials on web interfaces
Most microcontroller-based camera and sensor modules ship with a default admin interface — often on port 80 or 8080 — that uses either no authentication or a hardcoded credential pair like admin/admin or admin/12345. These pairs are documented in the firmware''s GitHub repository or product wiki. Bots running credential-stuffing scans against Shodan results test these pairs automatically. Changing the password, or better, disabling the web interface entirely and using a secure API, eliminates this exposure.
Developer config files in version control
Maker and freelancer-built IoT projects almost always involve a config file containing Wi-Fi credentials, API keys, and sometimes database connection strings. If this file is ever committed to a public repository — even once, even briefly, even if later deleted — the contents should be considered exposed. The correct practice is a .env file or equivalent that is listed in .gitignore from the first commit. If credentials were ever committed, rotate them now regardless of whether the file is currently present in the repo.
Same network segment as business-critical systems
The camera is rarely the target. It is the entry point. Small businesses almost universally run flat networks where all devices share a single subnet. An attacker who reaches the camera has the same network access as someone sitting on your office Wi-Fi. Put IoT devices on a separate VLAN with no lateral access to business systems. Most modern routers — including consumer-grade models — support VLAN configuration. This is not an enterprise-only control.
Old documentation and API references in public caches
If your business has a website that once documented a setup process, API endpoint, or configuration detail for a connected device, that documentation may still exist in Google''s cache, the Wayback Machine, or third-party content scrapers. Run your own domain through web.archive.org. Search Google for site:yourdomain.com api OR endpoint OR webhook. What you find is what an attacker finds in the first five minutes of passive reconnaissance.
Where this is heading
Within three years, automated credential-harvesting bots will specifically target hobbyist and maker IoT firmware signatures on Shodan — not to attack the devices directly, but to identify the businesses behind them and cross-reference against breached credential databases to find reused passwords.
The tooling for this already exists as separate components. Shodan search APIs are scriptable. Credential breach databases are searchable by domain. The missing piece is the automated linkage between a Shodan-identified device, its associated domain or business, and a breach corpus lookup. That linkage is a relatively straightforward script. The reason it has not become widespread yet is that the population of small businesses running identified maker firmware at public IPs has only recently grown large enough to make it a worthwhile target. As urban farming, retail automation, and maker-built business tools continue to expand, the population crosses that threshold.
Confidence: mediumA published threat intelligence report describing a campaign that specifically cross-references Shodan maker-firmware results against breach databases for credential reuse attacks against small businesses. If this report exists by 2027, the prediction holds.The Wayback Machine and similar archival services will become a formal part of external attack surface assessments within 18 months, shifting from an informal recon trick to a documented methodology step in major frameworks.
Historical URL enumeration is already used by red teams and has appeared in several documented breach post-mortems. The gap is that it is not yet formalized in assessment methodologies like PTES or in framework control mappings. As more breaches trace back to forgotten API endpoints discovered via archival searches, the pressure to include historical recon in standard assessments will grow. CISA and similar bodies tend to formalize what practitioners already do — the lag is typically 12 to 24 months.
Confidence: highInclusion of historical URL and API enumeration as a named step in an updated version of PTES, OWASP WSTG, or a CISA advisory on external attack surface management published before mid-2026.
The real problem is the mental model, not the device
Most of the IoT security writing I have read frames this as a technology problem — firmware that needs patching, protocols that need replacing, standards that need adopting. I think that framing is wrong, or at least incomplete. The deeper problem is that small business owners and makers have an accurate understanding of what their device does (streams video, reads a sensor) and a completely inaccurate understanding of what their device looks like from outside their network. The device does not feel like a networked computer with a public IP. It feels like a camera. Cameras are physical objects with a limited blast radius. That mental model produces decisions that make no sense from a network security perspective but make perfect sense if you genuinely believe the device is just a camera rather than a Linux-adjacent compute node with a public-facing web server. Fixing the firmware does not fix the mental model. The mental model is why the firmware never got configured in the first place.
Counterargument
The counterargument is that better defaults would solve this — if firmware shipped with authentication enabled and no public IP by default, the mental model would not matter because the device would be safe regardless of what the owner understood. That is a reasonable position and I partially agree with it. But it assumes the owner never changes the defaults in pursuit of convenience (they often do), never adds a port forward to make the stream accessible from outside the house (they routinely do), and never hands configuration to a developer who commits credentials to GitHub (this happens constantly). Better defaults raise the floor. They do not eliminate the exposure that comes from owners actively working around them because the defaults feel like friction.
One thing you can do this week
Go to shodan.io and search for your business''s public IP address. If you do not know your public IP, visit whatismyip.com from your business network. Paste that IP into Shodan''s search bar. What comes back is exactly what any attacker sees in their first pass. If a device appears — any device, not just a camera — note the port, the identified service, and whether authentication is mentioned. Then go to web.archive.org and search your business domain. Click through the oldest available snapshots and look for any page that references an API, a webhook, a configuration endpoint, or a setup guide. Anything you find, assume an attacker has already found it. That 20-minute exercise will tell you more about your actual exposure than any compliance checklist.
Further Reading
phishing email analyzer
Phishing email analyzer: what real detection looks like in 2026password strength calculator
Password strength calculator: what the score actually measures and what it missesISO/SAE 21434 automotive cybersecurity
ISO/SAE 21434 automotive cybersecurity: where compliance ends and risk begins
Frequently Asked Questions
How quickly does an ESP32-CAM or similar IoT device get indexed by Shodan after going online?
Based on documented honeypot research, most devices listening on common ports like 80, 8080, or 554 are indexed within 24 to 72 hours of first connection. Shodan and Censys scan the full public IPv4 space continuously — no one has to target your device specifically. The moment it gets a public IP and a listening port, it will appear.
Can an attacker find my GitHub credentials even if I deleted the file or made the repo private?
Yes. Git is an append-only ledger. If credentials were ever committed to a public repository, the git history retains them even after the file is deleted. Tools that mirror public repositories capture commits continuously, and that mirrored data does not disappear when you change the repo visibility. Any credentials committed to a public repo should be treated as permanently compromised and rotated immediately.
Is my live camera stream safe if I only share the URL with customers and do not publish it?
No. The stream URL path is not unique to your device — it is a default path defined by the firmware. For AI-Thinker ESP32-CAM firmware, the default path is /stream. Once Shodan indexes your device's IP and identifies the firmware, the stream URL is effectively known. The correct protection is authentication on the stream endpoint, not URL obscurity.
What is UPnP and why does it matter for IoT security?
Universal Plug and Play is a protocol enabled by default on most consumer and small business routers that allows devices on the local network to request the router open a port on their behalf. IoT devices including some ESP32-based firmware builds can use UPnP to make themselves reachable from the internet without any deliberate configuration by the owner. Disabling UPnP in the router admin panel prevents this. Checking takes under two minutes.
How do I check if my business has exposed devices or old API endpoints visible to attackers?
Search your public IP address on shodan.io — any device that appears there is reachable from the internet. Then search your business domain on web.archive.org and review old snapshots for any pages that reference API endpoints, webhooks, or setup guides. Run a Google search for site:yourdomain.com api OR endpoint OR webhook to find indexed references. What you find in 20 minutes is what an attacker finds in their first reconnaissance pass.
What is the real risk of a compromised IoT camera for a small business?
The camera itself is rarely the target. The risk is that most small businesses run flat networks where IoT devices share the same subnet as point-of-sale terminals, inventory systems, and business laptops. An attacker who reaches the camera through a public IP has network-layer access to everything else on that subnet. The camera becomes a pivot point into business-critical systems. VLAN segmentation — available on most modern consumer routers — isolates IoT devices and eliminates this lateral movement path.
Does making a GitHub repository private protect credentials that were previously public?
No. Third-party tools and mirrors capture public commits continuously. A repository that was public even briefly may have had its commit history copied before you changed the visibility. Additionally, git history persists through file deletions — the credentials remain in the log even if the file no longer exists in the current branch. The only safe remediation is to rotate the credentials immediately and treat them as compromised regardless of current repo visibility.
Related Articles
ISO/SAE 21434 automotive cybersecurity: where compliance ends and risk begins
ISO/SAE 21434 produces detailed TARA documentation in most implementations and almost no validated attack surface coverage. The standard requires cybersecurity by design. What gets built is cybersecurity by paperwork — and the gap is widest at the supplier boundary.
Password strength calculator: what the score actually measures and what it misses
Password strength calculators measure entropy and character patterns. They do not measure whether a password has already been compromised. In Vulnox assessments, over 40% of passwords that scored "strong" on standard calculators appeared in public breach datasets.
Phishing email analyzer: what real detection looks like in 2026
Most phishing email analyzers flag what attackers stopped using two years ago. In our assessments, 61% of phishing emails that bypassed automated filters shared one structural pattern — and it had nothing to do with links or attachments.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.