Slovakia's National Security Authority (Národný bezpečnostný úrad, NBÚ) has issued a formal warning that several models of road speed cameras deployed in the country represent a significant cyber threat. This is not a story about someone deleting a speeding ticket. According to the NBÚ, vulnerabilities in these devices could allow attackers to access vehicle registration and movement data, gain remote control of the cameras themselves, and — most critically — use the compromised devices as a pivot point into broader public administration networks.
This warning should be read as a case study in a systemic problem: municipal and national governments have spent a decade deploying IP-connected operational technology — cameras, traffic controllers, sensors, digital signage — with consumer-grade security assumptions. These devices sit physically exposed on roadsides, run embedded Linux with vendor firmware that is rarely patched, often ship with default or hardcoded credentials, and are frequently connected to networks that also carry administrative traffic.
If your organization operates, procures, or is adjacent to connected road infrastructure — municipalities, national traffic authorities, law enforcement, integrators, or any enterprise whose network shares segments with IoT/OT devices — this advisory applies to you. The NBÚ has done something relatively rare: a national security authority publicly naming deployed physical infrastructure as a cyber risk. Defenders should treat that as a signal to audit their own device populations now, not after an incident.
Technical Analysis
What the NBÚ Warning Actually Says
Based on the reporting of the NBÚ alert, the identified risks cluster into three categories that map directly onto well-understood IoT/OT failure modes:
- Exposure of vehicle and personal data. Speed cameras capture license plates, vehicle images, timestamps, and location metadata — data that constitutes a movement record. Under GDPR this is personal data; under any threat model it is valuable reconnaissance material for surveillance, stalking, or targeting. A vulnerable camera is a distributed surveillance sensor that an attacker can query.
- Remote access to the device. The cameras in question can be accessed remotely, implying weaknesses in authentication (default/hardcoded credentials, weak password enforcement), exposed management interfaces (web admin panels, Telnet/SSH, proprietary vendor protocols), or unpatched firmware vulnerabilities. Roadside devices are physically accessible, which compounds network weaknesses: an attacker with physical access can extract firmware, harvest credentials, or attach directly to the device.
- Foothold into public networks. This is the crown-jewel risk. A camera is rarely a target in itself — it is a beachhead. Cameras typically communicate back to central traffic management systems over VPN, cellular modems, or municipal WAN links. If segmentation is weak (and in municipal deployments it frequently is), a compromised camera becomes a pivot: it is a trusted, whitelisted device inside a network perimeter, with reachability to backend servers, and it is almost never monitored by endpoint security tooling.
No CVE identifiers were published in the NBÚ alert or the associated reporting, so there is no single patch-and-move-on fix here. The threat is architectural: a class of devices deployed at scale with weak default security posture, infrequent firmware update cycles, and privileged network positions.
Why Speed Cameras Are an Attractive Target
From an attacker's perspective, roadside camera infrastructure checks every box:
- Physical exposure. Devices are mounted on poles and gantries in public space. Cabinets are often protected only by low-grade locks. Physical access enables console/UART access, SD card extraction, or direct Ethernet attachment.
- Embedded, unmonitored operating systems. Most such devices run stripped-down Linux or RTOS builds. There is no EDR for a speed camera. Compromise is effectively invisible unless you are monitoring at the network layer.
- Stale firmware. Vendor support lifecycles for municipal hardware are notoriously poor. Firmware may be years out of date, and updating roadside devices at scale requires physical visits or fragile OTA mechanisms.
- Trusted network position. Cameras must communicate with central systems, so firewall rules permit their traffic. That trust is exactly what an attacker inherits after compromise.
- Data value. Plate and movement data has direct intelligence value, and bulk exfiltration from a camera management backend is far quieter than from an end-user network.
The Attack Chain (Defender's Model)
A realistic compromise path looks like this:
- Reconnaissance — Shodan/Censys exposure of the camera model's management interface, or physical inspection of the roadside unit.
- Initial access — Default or hardcoded credentials against the web admin panel, Telnet, or SSH; or exploitation of a known firmware flaw; or physical extraction of credentials/config from the device storage.
- Persistence — Modified startup scripts, added SSH authorized_keys, or a secondary account on the device. Firmware-level persistence survives reboots and is nearly undetectable without integrity checking.
- Collection — Local harvesting of captured plate/image data, or interception of data in transit if camera-to-backend communication is unencrypted or uses weak TLS.
- Pivot — From the camera's network segment, reconnaissance and lateral movement toward the traffic management backend, and from there potentially into wider municipal or government networks if segmentation boundaries are weak.
Exploitation Status
The NBÚ warning is a risk advisory, not a report of confirmed in-the-wild exploitation of a specific flaw. There is no published PoC, no CISA KEV entry, and no CVE attached to this story. However, the techniques involved — default credential abuse against embedded devices, exposed management interfaces, and IoT pivoting — are among the most heavily automated attack patterns on the internet. Any exposed camera management interface is being scanned continuously. Treat exposure as presumed compromise risk and hunt accordingly.
Detection & Response
Because these devices cannot host agents, detection must happen at the network and log layers: NetFlow/firewall logs from the camera VLAN, Syslog from the devices themselves (where supported), and VPN concentrator or backend authentication logs ingested into your SIEM. The detections below assume you have segmented camera infrastructure into a dedicated VLAN or subnet — if you have not, that is remediation step one, and the detections give you a strong reason to do it.
Sigma Rules
These rules target Syslog/firewall telemetry from camera segments. Tune the placeholder subnet to your actual camera VLAN CIDR before deployment.
---
title: Unexpected Outbound Connection from Speed Camera Segment
id: 3f8c2a91-6d44-4b7e-9c31-2a5f8e0d4b77
status: experimental
description: Detects outbound connections originating from the road camera VLAN to destinations other than the approved traffic management backend. Compromised cameras are commonly used for C2, exfiltration, or lateral scanning. Baseline approved destinations first.
references:
- https://securityaffairs.com/197764/hacking/slovakia-warns-of-cyber-risks-in-road-speed-cameras.html
- https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/02/11
tags:
- attack.command_and_control
- attack.exfiltration
- attack.t1071
logsource:
category: firewall
product: fortinet
detection:
selection_src:
src_ip|cidr: '10.60.0.0/16' # REPLACE with your camera VLAN CIDR
filter_approved_dst:
dst_ip|cidr:
- '10.10.5.0/24' # REPLACE with approved traffic management backend subnet
- '10.10.6.0/24' # REPLACE with NTP/DNS/management infrastructure as applicable
condition: selection_src and not filter_approved_dst
falsepositives:
- Misconfigured devices reaching vendor update servers (add vendor update FQDNs/IPs to the allowlist)
- Legitimate firmware update windows (suppress during change windows)
level: high
---
title: Inbound Remote Administration Attempt to Camera Device
id: 9d1e5b34-7c28-4a93-bf06-8e2c1a5d9f03
status: experimental
description: Detects SSH, Telnet, or web management connections targeting camera devices from sources outside the designated jump host or management station. Road cameras should accept administrative connections only from a hardened management bastion.
references:
- https://securityaffairs.com/197764/hacking/slovakia-warns-of-cyber-risks-in-road-speed-cameras.html
- https://attack.mitre.org/techniques/T1021/004/
author: Security Arsenal
date: 2026/02/11
tags:
- attack.lateral_movement
- attack.initial_access
- attack.t1021.004
- attack.t1078
logsource:
category: firewall
product: fortinet
detection:
selection_dst:
dst_ip|cidr: '10.60.0.0/16' # REPLACE with your camera VLAN CIDR
dst_port:
- 22
- 23
- 80
- 443
- 8080
- 554 # RTSP management/stream access
filter_mgmt_src:
src_ip|cidr:
- '10.10.1.10/32' # REPLACE with management jump host IP
condition: selection_dst and not filter_mgmt_src
falsepositives:
- Monitoring/scanner infrastructure performing authorized health checks (add scanner IPs to allowlist)
- Vendor maintenance sessions (require these to route through the jump host)
level: high
---
title: Repeated Authentication Failures Against Camera Management Interface
id: 5b7a4c06-2e91-4d58-a3c4-6f0d9b8e2a51
status: experimental
description: Detects brute-force or password-spraying behavior against camera SSH/web management interfaces via device Syslog. Multiple authentication failures from a single source against embedded devices indicate credential attacks exploiting default or weak passwords.
references:
- https://securityaffairs.com/197764/hacking/slovakia-warns-of-cyber-risks-in-road-speed-cameras.html
- https://attack.mitre.org/techniques/T1110/
author: Security Arsenal
date: 2026/02/11
tags:
- attack.credential_access
- attack.t1110
logsource:
product: linux
service: auth
detection:
selection:
- 'Failed password'
- 'authentication failure'
- 'Invalid user'
condition: selection
falsepositives:
- Misconfigured monitoring scripts with stale credentials
- Operator typo during legitimate maintenance
level: medium
KQL (Microsoft Sentinel / Defender)
Camera and firewall telemetry ingested via CEF/Syslog into Sentinel is the right hunting surface here. This query hunts for cameras talking where they shouldn't and for management-plane access attempts against the camera segment.
// Hunt: anomalous network activity involving the speed camera segment
// Prereq: firewall syslog/CEF ingestion into CommonSecurityLog.
// Replace the CIDRs below with your actual camera VLAN and approved backend subnets.
let CameraSegment = "10.60.0.0/16"; // camera VLAN
let ApprovedBackends = dynamic(["10.10.5.0/24", "10.10.6.0/24"]); // traffic mgmt backend, NTP/DNS
let MgmtJumpHost = "10.10.1.10"; // administrative bastion
let Lookback = 7d;
// 1) Outbound from cameras to non-approved destinations (C2 / exfil / scanning)
let SuspiciousOutbound =
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where ipv4_is_in_range(SourceIP, CameraSegment)
| where not(ipv4_is_in_range(DestinationIP, toscalar(ApprovedBackends[0]))
or ipv4_is_in_range(DestinationIP, toscalar(ApprovedBackends[1])))
| summarize Connections = count(), Destinations = make_set(DestinationIP, 25),
Ports = make_set(DestinationPort, 15), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, DeviceAction
| order by Connections desc;
// 2) Inbound admin-plane attempts to cameras from anything but the jump host
let AdminPorts = dynamic([22, 23, 80, 443, 8080, 554]);
let SuspiciousAdminAccess =
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where ipv4_is_in_range(DestinationIP, CameraSegment)
| where DestinationPort in (AdminPorts)
| where SourceIP != MgmtJumpHost
| summarize Attempts = count(), Sources = make_set(SourceIP, 25),
Ports = make_set(DestinationPort, 10), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by DestinationIP
| order by Attempts desc;
SuspiciousOutbound;
SuspiciousAdminAccess
Velociraptor VQL
If your traffic management backend or jump hosts are Windows or Linux endpoints, they are the most likely post-pivot target — a compromised camera leads to the backend, not the other way around. This artifact hunts the backend servers for connections to/from the camera segment and for suspicious service account usage patterns.
-- Hunt on traffic management backend hosts for connections involving the camera segment
-- and unexpected processes listening on admin ports (possible implant staging).
-- Adjust the camera CIDR regex to your environment.
LET camera_regex <= '10\\.60\\.'
SELECT Pid,
Name,
CommandLine,
LocalAddress.IP AS LocalIP,
LocalAddress.Port AS LocalPort,
RemoteAddress.IP AS RemoteIP,
RemoteAddress.Port AS RemotePort,
Status,
Family,
Type
FROM netstat()
WHERE (RemoteAddress.IP =~ camera_regex OR LocalAddress.IP =~ camera_regex)
AND Status =~ 'ESTABLISHED|LISTEN'
ORDER BY RemoteIP
For firmware- and file-integrity verification on Linux-based backend servers, this VQL flags recently modified binaries and new persistence artifacts — a reasonable follow-up if camera compromise is suspected:
-- Check Linux backend hosts for recently modified system binaries and new persistence
-- Run within 30 days of suspected camera-segment compromise window.
LET suspicious_paths <= glob('/etc/cron.d/*', '/etc/systemd/system/*.service',
'/root/.ssh/authorized_keys', '/home/*/.ssh/authorized_keys')
SELECT FullPath,
Size,
Mtime,
Mode
FROM glob(globs=suspicious_paths)
WHERE Mtime > (now() - 2592000) -- modified within last 30 days
ORDER BY Mtime DESC
Remediation & Hardening Script
The following Bash audit script runs against a Linux-based camera or management host (via your jump host) to verify the hardening controls the NBÚ warning implies: no default credentials, no Telnet, restricted management access, and enabled logging. Adapt paths to the vendor firmware — many camera OS builds are BusyBox-based and support ash/sh.
#!/bin/bash
# Speed camera / roadside device security audit — run via SSH from management jump host
# Validates controls implied by the NBU advisory. Requires root on the target device.
set -u
FAIL=0
note() { printf '[%s] %s\n' "$1" "$2"; }
# 1) Telnet must be disabled — Telnet on embedded devices is plaintext credential theft waiting to happen
if pgrep -x telnetd >/dev/null 2>&1 || netstat -tln 2>/dev/null | grep -q ':23 '; then
note FAIL "Telnet service is running or listening on port 23"; FAIL=1
else
note OK "Telnet not active"
fi
# 2) SSH hardening: no root password login, key-only auth preferred
SSHD_CFG="$(find /etc /etc/ssh -maxdepth 2 -name sshd_config 2>/dev/null | head -1)"
if [ -n "$SSHD_CFG" ]; then
grep -Eiq '^PermitRootLogin[[:space:]]+(no|prohibit-password)' "$SSHD_CFG" \
&& note OK "Root SSH login restricted" \
|| { note FAIL "PermitRootLogin not restricted in $SSHD_CFG"; FAIL=1; }
grep -Eiq '^PasswordAuthentication[[:space:]]+no' "$SSHD_CFG" \
&& note OK "Password auth disabled (key-only)" \
|| note WARN "PasswordAuthentication still enabled — enforce keys or strong unique passwords"
else
note WARN "sshd_config not found — verify SSH configuration manually"
fi
# 3) Check for accounts with well-known default/empty passwords
if [ -r /etc/shadow ]; then
awk -F: '($2=="" || $2=="!" ) && $1!~/^(daemon|bin|sys|sync|nobody)$/ {print $1}' /etc/shadow | while read -r acct; do
note WARN "Account '$acct' has empty/locked-but-present password field — verify"
done
# Common embedded defaults to flag: root/root, admin/admin, support/support hashes vary; check for shared hashes
DUPES=$(awk -F: '{print $2}' /etc/shadow | sort | uniq -d | grep -v '^[*!]' | wc -l)
[ "$DUPES" -gt 0 ] && note WARN "Duplicate password hashes across accounts — possible shared/default credentials"
fi
# 4) Management interface exposure: admin web UI should bind to mgmt VLAN only or sit behind firewall
LISTEN=$(netstat -tln 2>/dev/null | grep -E ':(80|443|8080|554) ')
if [ -n "$LISTEN" ]; then
echo "$LISTEN" | grep -q '0.0.0.0' && { note WARN "Web/RTSP services bound to all interfaces:"; echo "$LISTEN"; } \
|| note OK "Web/RTSP services bound to specific interfaces"
fi
# 5) Verify remote Syslog forwarding is configured (detection depends on it)
if grep -rqs '@' /etc/syslog.conf /etc/rsyslog.conf /etc/rsyslog.d/ 2>/dev/null; then
note OK "Remote syslog forwarding appears configured"
else
note FAIL "No remote syslog forwarding found — device is invisible to the SOC"; FAIL=1
fi
# 6) Outbound allowlist sanity check: enumerate established outbound connections
note INFO "Current outbound connections (verify all destinations against approved backend list):"
netstat -tn 2>/dev/null | grep ESTABLISHED | awk '{print $5}' | sort -u
# 7) Firmware version capture for vendor advisory cross-reference
note INFO "Kernel/OS: $(uname -a 2>/dev/null)"
[ -f /etc/os-release ] && cat /etc/os-release
exit $FAIL
Remediation
Since no specific CVE or patch version is attached to the NBÚ warning, remediation is a hardening and architecture program rather than a single patch deployment. Prioritize in this order:
-
Inventory and identify. Immediately determine whether you operate any of the camera models named in the NBÚ alert. Pull your full roadside device inventory — make, model, firmware version, deployment date, last patch date, and network segment. Cross-reference firmware versions against vendor security advisories. Devices past end-of-support should be scheduled for replacement, not patch-then-forget.
-
Contact the vendor — in writing. Request from each camera vendor: current firmware version and release notes, a list of known vulnerabilities affecting your deployed versions, the supported update mechanism, and the product's security support lifecycle. The NBÚ warning gives procurement and security teams leverage to demand answers that vendors routinely dodge.
-
Segment the camera network. Cameras belong in a dedicated VLAN or VRF with a deny-by-default egress policy. The only permitted flows should be: camera → designated backend collection servers (specific IPs/ports), camera → NTP/DNS, and jump host → camera for administration. Block all camera-initiated traffic to the internet and to any other internal segment. This single control neutralizes the "foothold into public networks" risk the NBÚ highlighted.
-
Kill default credentials and plaintext management. Rotate every device credential to a unique, strong password or key. Disable Telnet outright. Where the firmware permits, enforce SSH key authentication and disable root login. If a device cannot support non-default credentials, that is a replacement criterion — document it for procurement.
-
Restrict the management plane. All administrative access to cameras must originate from a single hardened jump host, ideally with MFA at the jump host itself and session recording. Firewall rules should deny management-port access (22/23/80/443/8080/554) from any other source.
-
Encrypt data in transit. Verify that camera-to-backend communication uses TLS 1.2+ with certificate validation, or a properly configured VPN tunnel. Plate and image data crossing municipal WANs or cellular links in plaintext is a GDPR exposure independent of any intrusion.
-
Instrument for detection. Forward device Syslog to your SIEM. Deploy the detections above. Baselining matters: build the approved-destination list first, then alert on deviation. A camera has an extremely predictable traffic profile — any deviation is suspicious almost by definition.
-
Address physical security. Audit roadside cabinet locks, tamper switches, and console port exposure. A device an attacker can open with a generic key is a device whose network controls can be bypassed entirely.
-
Establish a firmware update cadence. Quarterly review of vendor advisories, with defined maintenance windows for OTA or on-site updates. Track firmware currency as a KPI for the traffic infrastructure program.
-
Plan for replacement. If the NBÚ's assessment concludes the affected models cannot be adequately secured, budget for replacement now. Municipal procurement cycles are slow; the time to start a two-year replacement project is before the breach, not after.
There is no CISA KEV deadline attached to this advisory, but national-security-authority warnings about deployed infrastructure carry an implicit mandate: regulators and auditors will treat inaction after a public NBÚ warning as negligence. For EU operators, GDPR exposure of plate data adds regulatory risk on top of the intrusion risk.
The Bigger Lesson
The Slovakia warning is a template, not an anomaly. Every municipality and national agency deploying connected roadside, transit, or surveillance infrastructure faces the identical risk profile: physically exposed, minimally monitored, rarely patched devices holding trusted positions on public networks. If you operate any class of deployed IoT/OT at scale, run this exact playbook against it — cameras today, traffic signal controllers and EV chargers tomorrow.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.