Ten years after Mirai, factory-default logins still expose IP cameras

Mirai's method has not gone stale

A post on dev.to marking ten years since the Mirai botnet argues that the attack that made it famous still works unchanged: logging into cameras with the usernames and passwords they shipped with. In September 2016, Mirai conscripted hundreds of thousands of IP cameras and DVRs by cycling through a list of roughly 60 manufacturer-default credential pairs, then used that fleet in denial-of-service attacks that disrupted large portions of the internet. No zero-day exploit was needed then, and according to the author, none is needed now — default or weak logins remain the most common way attackers get into camera fleets.

The post opens with a blunt question for anyone running a network with cameras attached: which device is the biggest risk right now? Most organisations cannot answer it, the author writes, and not because of carelessness. Cameras tend to sit in an ownership gap — facilities bought them, an installer configured them, IT carries their traffic, and the security team assumes someone else is tracking them.

Why cameras stay exposed

The post frames each camera as a compact Linux machine with a web interface, a video streaming service and often a vendor SDK port, running firmware that was never updated after installation and sitting in a ceiling for seven to ten years. The recurring problems it identifies are:

• Internet exposure through a port forward for remote viewing, or a UPnP rule opened quietly, with search engines such as Shodan indexing the results continuously.
• Default or weak credentials, the same vector Mirai abused.
• Unencrypted RTSP streaming on port 554, which exposes video — and often the login credentials — to anyone who can observe the traffic.
• End-of-life firmware, where the vendor has stopped shipping patches but the camera keeps working, leaving known CVEs permanently open.
• Hardware that may be prohibited: Section 889 of the US NDAA bars federal agencies and contractors from video surveillance equipment from certain vendors, and because that hardware is widely OEM-rebranded, the name on the label frequently does not reveal the actual manufacturer.

ONVIF discovery misses a lot of devices

The obvious way to inventory cameras — ONVIF WS-Discovery multicast probes — has real blind spots, the author notes. Multicast traffic typically stops at subnet or VLAN boundaries, many cameras ship with ONVIF disabled or have it switched off by installers, and older or cheaper devices may not support it at all. A camera that ignores ONVIF still has to expose ports to be useful: RTSP on 554 or 8554, HTTP or HTTPS for the web UI, and vendor SDK ports such as 8000, 37777 or 34567. Scanning for those ports and fingerprinting the services behind them, the post argues, identifies cameras far more reliably than waiting for multicast replies.

Practical first steps

For small networks — and only ones you own or are authorised to test — the post suggests an afternoon's work: run an nmap service scan across the common camera ports on your own subnet, check your public IP on Shodan for exposed camera or NVR pages, disable UPnP on the router or firewall in front of the camera network, place cameras on a VLAN with no default internet egress, and write down each device's make, model, firmware version and end-of-support date. The author warns that the first firmware inventory is usually a surprise.

The author's product: OpenNVR Scout

The post is also promotional. Its author is behind OpenNVR Scout, a read-only assessment tool for camera estates too large to audit by hand. According to the post, it discovers cameras through port and service fingerprints rather than ONVIF alone, runs 50 checks across 14 risk categories including exposure, credentials, transport encryption, firmware age and known CVEs, and assigns an A–F grade to each camera and to the estate as a whole. Findings are mapped to US, EU, UK and Indian regulations, with specific support for identifying NDAA §889-covered hardware including rebranded units, and the output is a prioritised migration plan delivered as an HTML and PDF report. The tool is passive by design: it does not exploit anything, changes no configuration, and tests credentials only when explicitly authorised.

Why it matters

Mirai showed that humble embedded devices can be hijacked at scale with nothing more exotic than a shared password list, and a decade later the enabling conditions are still standard practice. Cameras routinely outlive vendor support, live on networks nobody segments, and answer to credentials nobody changed — while the NDAA has turned knowing what is on your wall into a procurement and compliance question, not just a security one. Until default logins and camera network isolation are treated as lifecycle obligations rather than installation-time details, the cheapest attack of 2016 remains fully viable.