Ten years after Mirai, can you name your riskiest camera?

In September 2016, a botnet called Mirai took over hundreds of thousands of IP cameras and DVRs. It didn't need a zero-day. It logged in with a list of about 60 factory-default usernames and passwords, then used those devices to knock large parts of the internet offline.

That was ten years ago. So here's a question for anyone who runs a network with cameras on it:

Which of your cameras is the biggest risk right now?

Most organisations can't answer that. Usually it isn't negligence. Cameras just fall between teams. Facilities bought them, an installer set them up, IT routes their traffic, and security assumes someone else is looking after them. Nobody owns the full list.

Why cameras are still the soft target

Treat a camera as what it really is: a small Linux computer with a network port, a web server, a video streaming server and a vendor SDK port. It usually runs firmware nobody has updated since the day it went in, and it sits in a ceiling for 7–10 years.

The same problems turn up on almost every site:

• Internet exposure. A port forward for "remote viewing", or UPnP opening one quietly. Search engines like Shodan index these devices continuously.
• Default or weak credentials. Still the number one way in. It's exactly what Mirai used.
• Plaintext RTSP. Most cameras stream video over RTSP on port 554 with no encryption. If someone can see the traffic, they can see the video, and often the credentials too.
• End-of-life firmware. Vendors stop shipping patches, but the camera keeps working, so nobody replaces it. Its known CVEs stay open for good.
• Hardware you may not be allowed to run any more. Section 889 of the US NDAA bans federal agencies and their contractors from using video surveillance equipment from certain vendors. The catch is that this hardware is widely OEM-rebranded, so the name on the label often isn't the company that made it.

None of this is exotic. The hard part is seeing all of it, across every camera, at once.

The discovery problem: ONVIF isn't enough

The obvious way to find cameras is ONVIF WS-Discovery: send a multicast probe and list whatever replies. It's a good start, but it misses a lot:

• Multicast usually stops at the subnet or VLAN boundary, so cameras on other segments never hear the probe.
• Many cameras ship with ONVIF disabled, or the installer turned it off.
• Older and cheaper devices may not support ONVIF at all.

A camera that ignores ONVIF still has to expose something to be useful: RTSP (554, 8554), HTTP/HTTPS for its web UI, and often a vendor SDK port such as 8000, 37777 or 34567. Those open ports, together with what the services report when you connect, identify a camera far more reliably than waiting for it to answer a multicast probe.

What you can check yourself this afternoon

You don't need any product for a first pass. Only scan networks you own or are authorised to test.

1. Find what's listening on camera ports on your own subnet:

   nmap -sV -p 80,443,554,8000,8554,37777,34567 192.168.1.0/24

Every host with 554 open deserves a closer look.

1. Check your public IP on Shodan (or a similar service). If a camera or NVR web page shows up, you have an exposure problem.
2. Turn off UPnP on the router or firewall that sits in front of the camera network.
3. Put cameras on their own VLAN with no internet egress by default. Cameras rarely need to call out, and blocking egress also cuts off a lot of botnet traffic.
4. Write down the make, model and firmware version of each camera and look up its end-of-support date. The first time you do this, it's usually a surprise.

That covers the basics for a home lab or a small office. For an estate of hundreds or thousands of cameras across many sites, doing it by hand doesn't scale. You also need output an auditor will accept.

So we built OpenNVR Scout

OpenNVR Scout is a read-only security assessment for a whole camera estate. It works in four stages:

🔍 Discover

It finds cameras by their open ports and service fingerprints, not only the ones that answer ONVIF. Cameras on other segments, cameras with ONVIF switched off, and old devices all end up in the inventory.

📊 Grade

It runs 50 checks across 14 risk categories, including exposure, credentials, transport encryption, firmware age and known CVEs. Each camera gets an A–F grade, and so does the estate as a whole. A letter grade is blunt on purpose: everyone, including people outside security, understands it in a meeting.

⚖️ Comply

Each finding is mapped to the relevant US, EU, UK and India regulations. When Scout finds NDAA §889-covered hardware, including OEM-rebranded units, it produces the evidence a procurement or compliance team needs.

🛠️ Fix

It produces a prioritised migration plan, not another flat list of patches. Some cameras need a firmware update. Some need a firewall rule. Some will never be safe and should be replaced first. The plan says which is which and in what order.

The output is a posture report in HTML and PDF that you can hand straight to your security team or auditor.

Read-only by design

A security tool that can break the thing it checks is a hard sell in production, particularly on a 10-year-old camera that falls over if you look at it the wrong way. So Scout is passive and read-only by default:

• It doesn't exploit anything.
• It doesn't change any configuration on the cameras.
• It only tests credentials when you explicitly authorise it.

That last point matters. Credential checks give the most useful results, and they're also the ones that need clear permission. Scout makes that an explicit opt-in, never a default.

See it in action

Here's a two-minute walkthrough:

👉 https://www.youtube.com/watch?v=RVPSaiNYGlg

Over to you

How does your organisation track camera security today? A spreadsheet, the VMS inventory, or nobody at all? I'd like to hear in the comments, especially from anyone who has tried to answer the §889 question for real.

If you'd like to know how your cameras would score, you can book a camera security assessment at opennvr.org or email [e-mail].