CVE-2026-107617, CVE-2026-97858, CVE-2026-105664: EseeCloud IP Camera Takeover — Detection and Remediation Guide

On the day CISA published ICS Advisory ICSA-26-288-02, every organization running Guangzhou Juan IoT Technology EseeCloud cameras or the companion EseeCloud App inherited a critical exposure. Three vulnerabilities — CVE-2026-107617, CVE-2026-97858, and CVE-2026-105664 — carry a CVSS v3 score of 9.8 (Critical). Successful exploitation allows a remote attacker to take full control of affected IP cameras without meaningful authentication barriers.

This is not a theoretical consumer-IoT problem. CISA flags these products as deployed across Energy, Communications, Transportation Systems, Financial Services, and Government Services and Facilities. EseeCloud-based cameras are white-labeled and rebadged by dozens of OEMs, which means your asset inventory may not even say "EseeCloud" on the label — the NVR in the warehouse, the cameras on the loading dock, the baby-monitor-grade camera a remote employee pointed at their home office may all run this stack.

If you operate any physical-security or OT-adjacent camera infrastructure, treat this as a drop-everything triage item this week.

What Happened

CISA ICS Advisory ICSA-26-288-02 discloses three vulnerabilities in Guangzhou Juan IoT Technology's EseeCloud platform — the cloud/P2P management layer and firmware used by a large family of low-cost IP cameras sold globally under many brand names.

Affected versions:

• EseeCloud App ≤ 4.9.6 — CVE-2026-107617, CVE-2026-97858, CVE-2026-105664
• EseeCloud Firmware ≤ 4.9.86.0 — CVE-2026-107617, CVE-2026-97858, CVE-2026-105664

CVSS v3: 9.8 (Critical) — network-exploitable, low complexity, no privileges or user interaction required.

Vulnerability classes (per CISA):

1. Use of Hard-coded Credentials (CWE-798) — The firmware/app ships with embedded credentials that cannot be changed by the end user. An attacker who extracts them (from firmware images, APK decompilation, or public research) gains authenticated access to any affected device fleet-wide. This is the single most dangerous pattern in IoT: one secret, every device.
2. Improperly Controlled Modification of Dynamically-Determined Object Attributes (CWE-915, "mass assignment") — The device API accepts object attributes the client should never be able to set, allowing an attacker to overwrite privileged properties (think: role, admin flag, configuration state) by injecting extra parameters into legitimate API requests.
3. Observable Response Discrepancy (CWE-203/204 family) — The service returns distinguishable responses that leak information — valid vs. invalid usernames, existing vs. non-existing device IDs — enabling enumeration that feeds directly into the first two attack paths.

The Attack Chain, From a Defender's Perspective

Chained together, these three weaknesses form a classic IoT takeover pattern:

1. Enumerate — The attacker uses the observable response discrepancy to identify valid device IDs/accounts exposed to the EseeCloud P2P or cloud API.
2. Authenticate — Hard-coded credentials grant an authenticated session against the camera's local web/RTSP/API interface or its cloud relay.
3. Escalate/Modify — Mass assignment lets the attacker flip privileged object attributes — enabling admin functions, changing configuration, disabling recording, or planting modified settings.
4. Persist/Pivot — Full control of the camera means a foothold on whatever VLAN it sits on, a video/audio surveillance capability against your own facility, and — historically the most common monetization path — conscription into a botnet for DDoS or proxying further attacks.

Because these cameras are deployed in critical infrastructure sectors, the surveillance-pivot scenario is not hypothetical: a compromised camera watching a substation gate, a data center hallway, or a bank branch is a physical-security breach, not just an IT event.

Exploitation Status

At time of writing, the advisory is fresh and CISA has not added these CVEs to the Known Exploited Vulnerabilities (KEV) catalog. That is cold comfort. Hard-coded credential flaws in camera/NVR platforms are among the fastest-to-be-weaponized vulnerability classes in existence — the Mirai playbook proved that a decade ago, and botnet operators continuously scan for exactly this pattern. Assume weaponization timelines measured in days-to-weeks, not months. Treat unpatched, internet-exposed EseeCloud devices as pre-compromised until inventoried and validated.

Immediate Triage: Are You Exposed?

The hard part with white-label IoT is identification. Practical steps:

• Check the app: If anyone in your org manages cameras via the "EseeCloud" mobile or desktop app (or a rebranded variant — many OEM apps are thin skins over the same SDK), the backend is affected.
• Scan for the devices: EseeCloud-family cameras typically expose HTTP web interfaces, RTSP (554), and proprietary P2P/cloud connectivity. Banner-grab your camera VLANs and search for "EseeCloud", "Juan", or "JOOAN"-style identifiers in HTTP responses, login pages, and device MAC OUI ranges.
• Check outbound connections: These devices maintain persistent P2P/cloud tunnels to vendor infrastructure. Any camera-class device with persistent outbound sessions to unfamiliar Chinese cloud endpoints deserves scrutiny.
• Interview facilities/physical security: Camera systems are frequently procured and installed outside IT's visibility. Ask the facilities team directly what apps they use to view cameras.

Detection & Response

Cameras rarely run EDR, so detection leans on network telemetry: firewall/NGFW logs, NetFlow, Zeek/Suricata, and syslog ingested into your SIEM. The rules below assume you have camera-class subnets identified (if you don't, that discovery gap is itself a finding).

SIGMA Rules

The following Sigma rules target network-observable behaviors associated with exploitation of this class of flaw: enumeration-style authentication probing against camera interfaces, and cameras initiating unexpected outbound connections (post-compromise C2/botnet behavior). Tune the Camera_VLAN placeholders to your environment — deploy these as network-device/web-log detections, not endpoint rules.

---
title: EseeCloud Camera Authentication Enumeration via Observable Response Discrepancy
id: 3f8a1c2e-7b4d-4e6f-9a21-8c5d6e7f8091
status: experimental
description: Detects high-volume authentication probing against IP camera web/API interfaces consistent with username/device enumeration via observable response discrepancies (CVE-2026-105664). Fires when a single external source generates repeated auth or API requests to camera hosts in a short window.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-288-02
  - https://attack.mitre.org/techniques/T1110/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1110
  - attack.reconnaissance
logsource:
  category: webserver
  product: zeek
detection:
  selection:
    uri_path|contains:
      - '/login'
      - '/cgi-bin/'
      - '/api/'
      - '/onvif/'
    status_code:
      - 401
      - 403
      - 404
  condition: selection
falsepositives:
  - Legitimate NVR/VMS polling of camera APIs
  - Vulnerability scanners during authorized assessments
level: medium
---
title: IP Camera Outbound Connection to Unusual Destination
id: 6b2e9d41-3f5a-4c78-b1d2-9e4a5f607182
status: experimental
description: Detects IoT/IP camera devices initiating outbound connections to non-whitelisted external destinations, consistent with post-exploitation C2, botnet conscription, or payload retrieval following camera compromise (e.g., via hard-coded credentials CVE-2026-107617). Requires maintaining a whitelist of approved vendor cloud/P2P endpoints per camera subnet.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-288-02
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.exfiltration
logsource:
  category: firewall
  product: zeek
detection:
  selection:
    src_zone: 'camera_vlan'
    action: 'allowed'
  filter_known_vendor:
    dst_domain|endswith:
      - 'eseecloud.com'
      - 'juantech.com'
  condition: selection and not filter_known_vendor
falsepositives:
  - Firmware update servers not yet whitelisted
  - NTP/DNS to infrastructure servers (whitelist these explicitly)
level: high
---
title: Inbound Connection to Camera Management Interface from Internet-Range Source
id: 91c4d7e2-5a3b-48f6-c2e1-7d8a9b0c1234
status: experimental
description: Detects direct inbound connection attempts from untrusted sources to IP camera management ports (HTTP/HTTPS/RTSP/proprietary P2P). EseeCloud-class devices should never be directly internet-exposed; any such traffic indicates misconfiguration or active exploitation attempts against CVE-2026-107617/CVE-2026-97858.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-288-02
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.t1133
logsource:
  category: firewall
  product: zeek
detection:
  selection:
    dst_zone: 'camera_vlan'
    src_zone: 'internet'
    dst_port:
      - 80
      - 443
      - 554
      - 8080
      - 8000
      - 34567
  condition: selection
falsepositives:
  - Misconfigured port forwarding (investigate and remove regardless)
  - Vendor remote-support sessions (should be brokered, not direct)
level: critical

KQL — Microsoft Sentinel Hunt

This query hunts firewall/syslog telemetry (ingested via CEF/Syslog into CommonSecurityLog) for two behaviors: internet-sourced connection attempts toward camera subnets, and camera-sourced outbound traffic to rare destinations. Adjust the CameraSubnet prefix to your addressing scheme.

// Hunt: EseeCloud-class camera exposure and post-compromise behavior
// Requires: camera subnet CIDR defined; firewall logs via CEF (CommonSecurityLog)
let CameraSubnet = "10.60.";               // TODO: replace with your camera VLAN prefix
let ApprovedVendorDomains = dynamic(["eseecloud.com", "juantech.com"]); // whitelist per policy
let Lookback = 7d;
// Part 1: Inbound attempts from internet toward camera management ports
let InboundExposure = CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DestinationIP startswith CameraSubnet
    | where DestinationPort in (80, 443, 554, 8000, 8080, 34567)
    | where not(SourceIP startswith "10." or SourceIP startswith "192.168." or SourceIP startswith "172.16.")
    | summarize AttemptCount = count(), DistinctSources = dcount(SourceIP),
                SourceIPs = make_set(SourceIP, 10), Ports = make_set(DestinationPort)
            by DestinationIP, DeviceAction
    | extend Behavior = "Internet-to-Camera Inbound Attempt";
// Part 2: Cameras initiating outbound connections to rare/new destinations
let OutboundBeacon = CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where SourceIP startswith CameraSubnet
    | where DeviceAction =~ "Allow" or DeviceAction =~ "allow"
    | where not(DestinationIP startswith "10." or DestinationIP startswith "192.168." or DestinationIP startswith "172.16.")
    | summarize ConnCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
                BytesOut = sum(tolong(SentBytes))
            by SourceIP, DestinationIP, DestinationPort
    | where ConnCount > 100 or BytesOut > 10000000   // persistent sessions or bulk egress
    | extend Behavior = "Camera Outbound Persistence / Possible C2";
union InboundExposure, OutboundBeacon
| sort by TimeGenerated desc

Velociraptor VQL

Where the EseeCloud desktop client is installed on managed Windows endpoints, or where you need to validate which internal hosts are talking to camera infrastructure, this artifact maps active connections to camera-class ports and flags endpoint hosts with the EseeCloud client installed — giving you a pivot list for scoping.

-- Hunt: EseeCloud client presence and active camera/P2P connections on endpoints
-- Scope: all managed Windows endpoints
LET conns = SELECT Pid, Name, Pid AS ProcessId, Laddr, Raddr, Status
  FROM netstat()
  WHERE Raddr.IP AND (
       Raddr.Port in (554, 8000, 8080, 34567)          -- RTSP / camera mgmt / proprietary P2P
    OR Laddr.Port in (554, 8000, 8080, 34567))

LET installs = SELECT Name, InstallLocation, DisplayVersion, Publisher
  FROM Artifact.Windows.Registry.Uninstall()
  WHERE Name =~ '(?i)eseecloud|juan|jooan'

SELECT * FROM conns
UNION ALL
SELECT NULL AS Pid, Name, NULL AS ProcessId,
       InstallLocation AS Laddr, DisplayVersion AS Raddr,
       Publisher AS Status
FROM installs

Discovery & Validation Script

Use this Bash script from a management host with network reachability to camera segments. It discovers candidate EseeCloud-family devices by banner and reports firmware versions where exposed, so you can validate against the vulnerable threshold (firmware ≤ 4.9.86.0). Run read-only; it performs no exploitation.

#!/usr/bin/env bash
# eseecloud_triage.sh — Discover and fingerprint EseeCloud-family cameras for ICSA-26-288-02 triage
# Usage: ./eseecloud_triage.sh 10.60.0.0/24 [10.61.0.0/24 ...]
# Requires: nmap, curl. Run from a jump host with reachability to camera VLANs.

set -euo pipefail
OUT="eseecloud_triage_$(date +%Y%m%d_%H%M%S).csv"
echo "ip,http_banner,title_or_server,possible_eseecloud,notes" > "$OUT"

for SUBNET in "$@"; do
  echo "[*] Scanning $SUBNET for camera interfaces (80/443/554/8000/8080/34567)..."
  # Fast port discovery
  nmap -Pn -open -p 80,443,554,8000,8080,34567 --min-rate 1000 \
       -oG - "$SUBNET" 2>/dev/null | awk '/Ports:/{print $2}' | sort -u | while read -r IP; do

    BANNER=""; TITLE=""; FLAG="no"; NOTE=""

    # Grab HTTP banner + page title (read-only GET)
    BANNER=$(curl -sk --max-time 4 "http://$IP/" -D - -o /tmp/body_$$ 2>/dev/null | head -20 || true)
    TITLE=$(grep -ioP '<title>\K[^<]+' /tmp/body_$$ 2>/dev/null | head -1 || true)

    # Fingerprint: EseeCloud/Juan-family markers in headers, body, or login page
    if echo "$BANNER" | grep -iqE 'eseecloud|juan|jooan' || \
       grep -iqE 'eseecloud|juan tech|jooan|ipcamera' /tmp/body_$$ 2>/dev/null; then
      FLAG="yes"
      NOTE="Vendor marker found — check firmware version in web UI against <=4.9.86.0"
    fi

    # RTSP presence note
    if nc -z -w2 "$IP" 554 2>/dev/null; then NOTE="$NOTE; RTSP exposed"; fi
    # Proprietary P2P port note
    if nc -z -w2 "$IP" 34567 2>/dev/null; then FLAG="yes"; NOTE="$NOTE; P2P port 34567 open"; fi

    echo "$IP,\"$(echo "$BANNER" | tr '\n' ' ' | cut -c1-80)\",\"$TITLE\",$FLAG,\"$NOTE\"" >> "$OUT"
    rm -f /tmp/body_$$
  done
done

echo "[+] Triage complete. Results: $OUT"
echo "[+] Next: for each 'yes' row, log into the device UI, record firmware version, and flag <=4.9.86.0 for isolation/update."

Remediation

CISA's guidance for ICSA-26-288-02, combined with standard IoT hardening practice, gives a clear priority order. Do these in sequence — the network controls buy you time while you chase firmware.

1. Eliminate internet exposure immediately (today).

• Confirm no EseeCloud-family camera has a public IP, NAT port-forward, or UPnP-created mapping. These devices should never be directly reachable from the internet.
• Disable UPnP on perimeter equipment — consumer-grade cameras aggressively auto-punch holes.
• Block inbound firewall rules to camera VLANs on ports 80/443/554/8000/8080/34567.

2. Segment (this week).

• Place all cameras on a dedicated VLAN with no route to user workstations, servers, or OT networks unless explicitly required (NVR/VMS only).
• Restrict camera egress to an explicit whitelist: NTP, DNS, and the vendor P2P/cloud endpoints you have deliberately approved. Default-deny everything else.

3. Update firmware and app versions.

• EseeCloud App: update beyond 4.9.6 via official app stores only.
• Firmware: update beyond 4.9.86.0. Contact your camera's actual vendor/OEM for the corrected firmware image — because of white-labeling, the update path is through whoever's brand is on the device, not necessarily Juan IoT directly. Monitor the vendor channels and the CISA advisory page for updated remediation guidance.
• Caveat from the field: hard-coded credentials frequently persist across firmware updates because they are baked into the design, not the config. Patching closes the disclosed CVEs; it does not make a $30 camera trustworthy. Compensating network controls remain mandatory.

4. Rotate and replace what you can.

• Change all user-settable device passwords; disable default accounts where possible.
• If the device management plane (NVR/VMS) shares credentials with anything else in your environment, rotate those too — assume the camera config has been readable by anyone with the hard-coded keys.

5. Hunt for pre-patch compromise.

• Run the KQL hunt and network discovery above against historical logs (30+ days back). Look for: inbound auth probing, unexpected outbound persistence, and configuration changes you didn't make (recording disabled, motion zones altered, new user accounts on the device).
• Any camera showing signs of compromise: pull it offline, factory-reset, reflash with current firmware, and investigate what else on that segment was touched.

6. Strategic fix: procurement policy.

• Add firmware-CVE disclosure history, signed firmware, unique-per-device credentials, and no-UPnP requirements to your physical security procurement standard. The rebadged-camera supply chain guarantees this exact advisory will recur under a different brand name.

CISA's standard mitigations for ICS advisories apply: minimize network exposure for all control-system-adjacent devices, locate them behind firewalls isolated from business networks, and use secure remote access (VPN/managed jump hosts) rather than direct exposure when remote viewing is required.

The Bottom Line

Three CVEs, one 9.8 CVSS score, and a vulnerability class — hard-coded credentials — that botnet operators have industrialized. The window between disclosure and mass scanning for this category of bug is short. Inventory your camera estate (including the white-label devices that don't say "EseeCloud" on the box), kill internet exposure, segment aggressively, and patch through your OEM. If you find evidence of pre-patch probing or unexpected outbound traffic from camera segments, treat it as an incident, not a hygiene issue.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub