Table of Contents Link to heading
- What the Night Guard Saw
- The First Two Theories Were Wrong
- What the Access Log Actually Said
- The Real Attack: No Sophistication Required
- Why “Behind the Firewall” Is Not a Defence
- The Attack Surface: What an Unsecured Camera System Exposes
- Technical Remediation: What a Proper Camera Security Hardening Looks Like
- Network Topology: Exposed vs Hardened
- The Commissioning Checklist That Should Be Non-Negotiable
- How to Check Your Own System Right Now
What the Night Guard Saw Link to heading
At some point past midnight, the security guard on night duty noticed one of the office PTZ cameras rotating on its own — panning slowly across the room as if someone were operating it remotely. No one was at the control workstation. No one was supposed to be accessing the system.
He noted the time and reported it to management the next morning.
The initial reaction from most people in that meeting was predictable: hardware fault, or someone on the IT team running a test they forgot to mention. Both explanations were comfortable. Neither required thinking about the alternative.
The alternative was worse.
The First Two Theories Were Wrong Link to heading
Theory 1 — Hardware fault: A PTZ camera that spontaneously pans on its own without a control signal is extraordinarily rare. The mechanics of a PTZ motor require an active command to move. A hardware fault typically manifests as a stuck motor, a camera that will not move on command, or a camera that constantly drifts in one direction due to a calibration issue. Purposeful, directional movement at midnight does not fit any known hardware failure mode.
Theory 2 — Internal test: Possible, but the first question is always: check the access log. If someone on the team ran a remote test at midnight, there will be a login event with their account credentials and a known internal IP address.
The access log answered both theories at once.
What the Access Log Actually Said Link to heading
The NVR (Network Video Recorder) and camera management platform both maintain access logs — timestamped records of every login attempt, successful authentication, and control command issued to the system.
What the log showed:
Date Time Event Account Source IP Country
──────────────────────────────────────────────────────────────────────────────
2025-07-28 23:41:03 Login SUCCESS admin 103.xx.xx.xx Vietnam (ISP)
2025-07-28 23:41:08 PTZ Command admin 103.xx.xx.xx —
2025-07-28 23:41:22 PTZ Command admin 103.xx.xx.xx —
2025-07-28 00:12:47 Login SUCCESS admin 185.xx.xx.xx Netherlands
2025-07-29 01:33:11 Login SUCCESS admin 45.xx.xx.xx Russia
2025-07-29 02:05:44 Login SUCCESS admin 91.xx.xx.xx Germany
admin account — with no corresponding internal staff session — is an unambiguous indicator of unauthorised access. The account credentials were valid. The attacker was not bypassing authentication; they were authenticating correctly.No brute force. No zero-day exploit. No sophisticated attack tooling. The attacker simply logged in.
The Real Attack: No Sophistication Required Link to heading
The camera system was still using the manufacturer’s default credentials — the username and password that ships on every unit of that model from the factory. Default credentials are not secret. They are published in the product manual, on the manufacturer’s support website, and aggregated in publicly available default credential databases.
An attacker who knows the camera brand and model needs nothing more than:
- The camera’s IP address or hostname (reachable from the internet)
- The default username (typically
admin) - The default password (one Google search away)
That is the entire attack. No technical sophistication required. No specialised tools. The barrier was not technical — it was the assumption that no one would bother.
How Attackers Find Your Camera Without Knowing Your Address Link to heading
Most businesses assume their camera system is obscure enough to not be worth targeting. This assumption is incorrect.
Shodan (shodan.io) is a search engine for internet-connected devices. It continuously scans the entire IPv4 address space, identifies device types from their HTTP banners, open ports, and SSL certificates, and makes the results searchable. A query for a specific camera brand or model returns thousands of results — with IP addresses, open ports, and in many cases, partial firmware version information.
Shodan query example:
product:"Hikvision IP Camera" → 2,400,000+ results
product:"Dahua IP Camera" → 800,000+ results
http.title:"Network Camera" → millions of results
Each result includes:
→ IP address
→ Open ports (80, 443, 554/RTSP, 8080)
→ Device model (from HTTP headers)
→ Geographic location
→ ISP / organisation name
An attacker does not need to know your company exists. They query Shodan for cameras of a specific model with default firmware, get a list of thousands of IP addresses, and run an automated script that tries the default credentials against each one. The script does not care which company owns the camera — it just tries credentials until something works.
The Remote Access Feature Is the Exposure Vector Link to heading
Most IP camera systems are configured to allow remote viewing — this is a legitimate and useful feature. Operations managers want to check the office from their phone. Security teams want to monitor multiple sites from a central NOC. The feature works exactly as designed.
The problem is that “accessible from the internet for authorised remote viewing” and “accessible from the internet by anyone with the right credentials” are the same configuration. If the credentials are the manufacturer’s defaults, the access control is effectively open.
What the business intends:
Manager's phone (authenticated) → Internet → Camera system
What the configuration actually allows:
Anyone in the world (with default credentials) → Internet → Camera system
Why “Behind the Firewall” Is Not a Defence Link to heading
The most common objection when raising this issue is: “But our cameras are behind the company firewall. You can’t access them from outside.”
This is usually incorrect for one of three reasons:
Reason 1 — Port forwarding: The installation technician configured port forwarding on the router to enable remote viewing. Ports 80, 443, 8080, or 554 (RTSP) are forwarded directly to the NVR or cameras. The firewall is present but has a deliberate hole in it for the camera system.
Reason 2 — DDNS and P2P cloud relay: Many consumer and SMB camera systems use a peer-to-peer cloud relay (built into the camera firmware) that establishes an outbound connection to the manufacturer’s cloud server. This bypasses firewall restrictions entirely because the connection originates from inside the network. The camera is reachable from the internet through this relay without any port forwarding configuration.
Reason 3 — Misconfigured DMZ: Some businesses place their NVR in a DMZ for remote access, intending to protect the internal network while exposing the NVR. If the NVR itself is compromised through default credentials, it becomes a foothold inside the network perimeter.
The Attack Surface: What an Unsecured Camera System Exposes Link to heading
A compromised camera system is not just a privacy violation. Depending on the camera placement and network configuration, it can be significantly worse:
| What the attacker gains | Business impact |
|---|---|
| Live and recorded video feed | Corporate espionage, theft of intellectual property, blackmail material |
| PTZ control | Active reconnaissance — pan to read documents, whiteboards, screens |
| NVR storage access | Delete or overwrite footage covering a physical incident |
| Network foothold (if NVR is on corporate LAN) | Lateral movement to internal systems — file servers, workstations |
| Knowledge of physical security procedures | Timing physical attacks to avoid coverage |
| Employee movement patterns | Personal safety risk, executive tracking |
The midnight camera rotation in this incident was almost certainly an attacker testing PTZ control — verifying that they had full access and exploring what the camera could see.
Technical Remediation: What a Proper Camera Security Hardening Looks Like Link to heading
Step 1 — Credential Audit and Reset Link to heading
# On Hikvision NVR via SSH (if enabled):
# Check current user accounts
show users
# On camera web interface — check active sessions:
# Configuration → Security → Security Service → Online Users
# Force password change on all devices
# Minimum requirements:
# Length: 12+ characters
# Complexity: uppercase + lowercase + digits + special characters
# Unique per device (not the same password across all cameras)
# Document credentials in a password manager (not a spreadsheet)
# Recommended: Bitwarden, 1Password, or KeePass with encrypted vault
Step 2 — Network Isolation: VLAN Segmentation Link to heading
Place all cameras and NVRs on a dedicated VLAN that is isolated from the corporate LAN. This limits the blast radius if a camera is compromised — the attacker gains access to the camera network, not the entire corporate environment.
! Create dedicated VLAN for surveillance system
vlan 50
name CCTV-SURVEILLANCE
! Assign camera switch ports to surveillance VLAN
interface range GigabitEthernet0/1 - 22
switchport mode access
switchport access vlan 50
spanning-tree portfast
description "IP Camera"
! NVR port
interface GigabitEthernet0/23
switchport mode access
switchport access vlan 50
description "NVR-Primary"
! ACL: cameras can only talk to NVR, not to corporate LAN
ip access-list extended CCTV-ISOLATION
permit ip 10.50.0.0 0.0.0.255 host 10.50.0.10 ! cameras → NVR only
deny ip 10.50.0.0 0.0.0.255 10.0.0.0 0.255.255.255 ! block corp LAN
permit ip 10.50.0.0 0.0.0.255 any ! allow internet (NTP, updates)
interface Vlan50
ip address 10.50.0.1 255.255.255.0
ip access-group CCTV-ISOLATION in
Step 3 — Remote Access Hardening Link to heading
Option A — VPN-only access (recommended):
Disable direct internet exposure entirely
Remote viewing only via company VPN
VPN authenticates the user before granting any camera access
No camera ports exposed to internet
Option B — If direct remote access is required:
Restrict by source IP (whitelist known management IPs)
Enable HTTPS only — disable HTTP
Disable Telnet and unencrypted RTSP
Change management port from default (80/8080 → non-standard)
Enable account lockout after 5 failed attempts
Disable P2P cloud relay if not needed
! Firewall ACL — restrict camera management to VPN subnet only
ip access-list extended CAMERA-REMOTE-ACCESS
permit tcp 10.200.0.0 0.0.0.255 10.50.0.0 0.0.0.255 eq 443
! 10.200.0.0/24 = VPN client pool
deny tcp any 10.50.0.0 0.0.0.255 eq 80
deny tcp any 10.50.0.0 0.0.0.255 eq 8080
deny tcp any 10.50.0.0 0.0.0.255 eq 443
Step 4 — Firmware and Patch Management Link to heading
Default credential vulnerabilities are not the only risk. Camera firmware contains the same classes of vulnerabilities as any other networked software — buffer overflows, authentication bypasses, and command injection flaws. Manufacturers release patches; most deployed cameras never receive them.
Quarterly firmware audit process:
1. Inventory all camera models and current firmware versions
2. Check manufacturer security advisory pages for each model
3. Download and test firmware in a non-production environment first
4. Schedule maintenance window for production firmware updates
5. Document version and date of each update per device
Step 5 — Access Logging and Alerting Link to heading
The incident in this case was discovered by a human who happened to notice the camera moving. A properly configured system should have generated an automated alert within minutes of the first unauthorised login.
Minimum logging configuration:
✓ All login attempts (success and failure) with source IP and timestamp
✓ PTZ control commands with operator account and source IP
✓ Configuration changes
✓ User account creation or modification
✓ Remote access session start and end times
Alerting thresholds:
✓ Login failure > 3 times from same IP → alert security team
✓ Successful login from IP outside known ranges → immediate alert
✓ Login during outside business hours → alert on-call
✓ PTZ command from non-operator account → alert immediately
Network Topology: Exposed vs Hardened Link to heading
Exposed Configuration (What Most Businesses Run) Link to heading
Internet
│
│ Port forwarding: 80, 8080, 554 → NVR
▼
[Router/Firewall]
│
├── Corporate LAN (10.0.0.0/24)
│ Workstations, Servers, Printers
│
└── Cameras + NVR (same subnet as corporate LAN)
├── Camera-01 (admin/admin123) ← default credentials
├── Camera-02 (admin/admin123) ← default credentials
├── Camera-03 (admin/admin123) ← default credentials
└── NVR (admin/admin123) ← default credentials
Attack path:
Internet → Port forward → NVR/Camera (default creds) → FULL ACCESS
→ Corporate LAN pivot
Hardened Configuration (What It Should Look Like) Link to heading
Internet
│
│ Only VPN port open (UDP 1194 / TCP 443)
▼
[Next-Gen Firewall]
│
├── Corporate LAN VLAN 10 (10.0.0.0/24)
│ Workstations, Servers
│ NO direct path to CCTV VLAN
│
├── CCTV VLAN 50 (10.50.0.0/24) ← ISOLATED
│ ├── Camera-01 (unique strong password)
│ ├── Camera-02 (unique strong password)
│ └── NVR (unique strong password)
│ ACL: cameras → NVR only, no corp LAN access
│
└── VPN Pool VLAN 200 (10.200.0.0/24)
Authenticated remote users only
VPN users can reach CCTV VLAN for viewing
All access logged with user identity
Attack path:
Internet → VPN (requires valid certificate + credentials) → CCTV VLAN
No direct camera exposure. No default credentials. Full audit trail.
The Commissioning Checklist That Should Be Non-Negotiable Link to heading
Every camera system deployment should complete this checklist before handover — not as optional documentation, but as a condition of sign-off.
Credentials:
- All cameras: default password changed to unique, complex password
- NVR/VMS: default password changed, default
adminaccount renamed or disabled - Remote access accounts: individual named accounts per operator (no shared
admin) - Credentials stored in a password manager, not a spreadsheet
Network:
- Cameras on dedicated VLAN, isolated from corporate LAN
- ACL in place: cameras can reach NVR, cannot reach corporate LAN
- No direct port forwarding of camera management ports to internet
- P2P cloud relay disabled if remote access via VPN is used instead
Remote access:
- Remote viewing via VPN only (preferred) or restricted source IP whitelist
- HTTPS enforced, HTTP disabled
- Telnet disabled, SSH with key authentication if CLI access needed
- Account lockout configured (5 failed attempts → 30-minute lockout)
Firmware:
- All devices on latest stable firmware at commissioning
- Firmware update schedule documented (quarterly review minimum)
- Manufacturer security advisory RSS feed or notification subscribed
Logging:
- Access logging enabled on NVR and all cameras
- Log retention: minimum 90 days
- Alert configured for login from unknown IP
- Alert configured for after-hours access
How to Check Your Own System Right Now Link to heading
If you manage or oversee a camera system, three checks take less than ten minutes:
Check 1 — Are you using default credentials?
Try logging into your NVR or camera management interface with the manufacturer’s default username and password. If it works, you have an open door. The default credentials for every major brand are one search away:
Hikvision: admin / 12345 (older firmware)
Dahua: admin / admin
Axis: root / pass
Bosch: service / (no password)
Hanwha: admin / no password (first login)
Check 2 — Are your cameras reachable from the internet?
Go to shodan.io and search for your organisation’s public IP range or your company name. If your cameras appear in Shodan results, they are discoverable by anyone running the same search.
Alternatively: disconnect from your office Wi-Fi, use your phone’s mobile data, and try accessing your camera system’s remote viewing URL. If it loads without a VPN, it is directly internet-exposed.
Check 3 — When was the last access log reviewed?
Open your NVR or VMS, navigate to the access log or audit trail, and look at the last 30 days of login events. Look for logins outside business hours, logins from unfamiliar IP addresses, or login failures followed by a successful login from the same IP.
A surveillance system that can be accessed by an attacker in the Netherlands at 2 AM using a password printed in the product manual is not a surveillance system — it is a liability. Camera resolution, IR range, and frame rate are secondary specifications. The primary specification of any security system is: who can access it, and how do you know?
Changing the default password is not a technical task. It takes two minutes per device. It is the single most effective security control available for IP camera systems, and the most consistently skipped step at commissioning.