Network cameras with default credentials on open ports are one of the easiest footholds an attacker can find on the internet today. If your organization runs IP cameras, NVRs or DVRs, and any of them can be reached from a public IP address, this article explains which ports give them away, why default and hardcoded credentials stay a problem years after Mirai, and how to find and close the exposure before someone else logs in.
The payoff is easy to see. A single exposed camera can leak footage of a server room, a reception desk or a cash register. It can also become a bot that floods someone else’s network from your address, and at worst it gives an attacker a Linux box sitting on your internal network.
Why Cameras Are Different from Other Exposed Services
Most camera firmware is an embedded Linux build running BusyBox, a stripped-down web server and a proprietary streaming daemon. Updates are rare and usually manual. The device sits in a ceiling for 5-10 years, installed by a contractor who has long since moved on.
Credentials are the core problem. For years, vendors shipped admin/admin, admin/12345, root/vizxv or a blank password. Mirai’s original 2016 source code contained around 60 hardcoded username and password pairs, and many of them belonged to cameras and DVRs. That short list was enough to recruit hundreds of thousands of devices.
Regulation has caught up partly. California’s SB-327 took effect on 1 January 2020, and the UK’s PSTI regime has banned universal default passwords on consumer connectable products since 29 April 2024. ETSI EN 303 645 sets the same baseline in Europe. None of these laws reach back to the millions of older units still in service, and many commercial cameras bought through integrators fall outside consumer-focused rules anyway.
The Ports That Give Network Cameras Away
An external port scan against a typical camera or NVR finds a familiar set of ports. HTTP on 80 or 8080 serves the web interface, and 443 is there if someone enabled TLS. RTSP on 554 delivers the video stream. ONVIF discovery and control usually runs over the web port. Then come the vendor-specific ports: Hikvision devices commonly listen on 8000 for their SDK protocol, and Dahua devices on 37777 TCP and 37778 UDP. Older units often still expose Telnet on 23, or 2323 when it’s been remapped.
Service detection matters here because the banner often names the vendor outright. Proper version detection turns “port 80 open” into “Hikvision web server, firmware branch affected by CVE-2021-36260”, which is a critical unauthenticated command injection that was patched in September 2021. Many devices still run firmware from before that patch.
Exposure also comes from vendor features. UPnP on the NVR quietly asks the router to forward ports, and “P2P cloud” options punch outbound tunnels. The firewall team never wrote a rule for either, so neither shows up in a firewall review.
A Familiar Scenario: The Contractor-Installed NVR
The pattern shows up again and again in external assessments. A mid-sized warehouse has 16 cameras installed by a security integrator. The integrator wants remote support access, so they forward port 80 and port 37777 on the site router to the NVR. The ticket gets closed and nobody documents the change.
Eighteen months later, a quarterly external scan flags two new open ports on a branch office IP. The web interface accepts admin with the integrator’s standard password, which is the same one used at a dozen other customer sites. The NVR is also on the same flat VLAN as the warehouse management system.
The camera itself was never the real target. It was a pivot point.
Busting the Myth: “We Changed the Admin Password, So We’re Fine”
This is the misconception that does the most damage. Changing the web admin password often leaves other ways in untouched. Many cameras keep separate accounts for ONVIF, which may still use defaults or no authentication at all. RTSP streams on 554 are sometimes served without authentication, depending on a setting buried three menus deep. Some firmware also contains undocumented service or debug accounts that the web interface doesn’t manage at all.
CVE-2017-7921 in older Hikvision firmware is the textbook case. It allowed an authentication bypass that made the admin password irrelevant. Strong passwords don’t protect a device whose authentication logic is broken. Only patching and removing the exposure fixes that.
How to Audit Network Cameras for Default Credentials
An experienced penetration tester working through camera exposure follows roughly this sequence:
1. Scan the public ranges. Run a full TCP scan plus a targeted UDP scan of every public IP address, including branch offices and sites whose internet line was set up by a contractor.
2. Fingerprint the services. Use Nmap with -sV and scripts such as http-default-accounts and rtsp-url-brute to identify the vendor and test known default logins, but only on assets you are authorized to test.
3. Find every forwarding path. Check router UPnP tables and NAT rules. Remove any forward pointing at a camera or NVR.
4. Reset credentials everywhere. Set unique credentials on the web, ONVIF and RTSP accounts, and disable Telnet, UPnP and P2P cloud features.
5. Rescan from outside. Verify every change with an external scan rather than trusting the configuration screen.
Remote viewing should go through a VPN or a properly segmented gateway, never a direct port forward. The broader category of printer and IoT ports deserves the same treatment, because the same contractors and the same habits create the same gaps.
Common Mistakes When Securing Camera Ports
The first mistake is moving the web interface from 80 to something like 8081 and calling it hardened. Mass scanners such as Masscan and ZMap sweep all 65,535 ports, and the banner still says exactly what the device is. The reasoning behind changing default ports applies here too: it cuts down log noise, but it is not access control.
The second is trusting the vendor’s “secure” setup wizard. Many wizards force a new admin password and then leave RTSP anonymous or UPnP enabled.
The third is scanning only the head-office IP. Cameras live at satellite sites, construction trailers and retail branches, often on consumer-grade 4G routers with their own public addresses.
There are edge cases. Fully air-gapped CCTV networks with no route to the internet carry far lower external risk, though the internal default credential problem remains. Very small teams with fewer than 10 cameras may find that one cloud-managed system with forced MFA beats a self-hosted NVR they can’t patch.
FAQ
Which port on an IP camera is most dangerous to expose?
The web management port, usually 80, 8080 or 443, is the most dangerous because it typically allows both credential attacks and exploitation of firmware bugs. Telnet on 23 is just as bad wherever it still exists.
Is it safe to expose RTSP port 554 if the stream requires a password?
It’s safer, but still not recommended. RTSP implementations on cameras have had their own parsing vulnerabilities, and stream credentials are often weak or shared across devices.
How often should camera exposure be checked?
Check continuously, or at least weekly. Integrators, UPnP and firmware resets can reopen ports with no change ticket, so an annual audit misses most of the window an attacker would use.
Summary
Default credentials on network cameras persist because the devices outlive the people who installed them, and because the web admin password is only one of several ways in. Scan every public IP from the outside, identify vendors through service detection, and take cameras off the internet entirely, putting remote access behind a VPN. After every change, rescan rather than assuming the router did what the configuration page says.