IoT hardware as a proxy for lateral movement
A smart aquarium system provided a persistent network path for hackers to exfiltrate 10GB of data from a casino.

A TikTok post by @scroll.engineer describes how hackers exfiltrated 10GB of data from a casino via a smart aquarium system. The device was connected to the internet to monitor water temperature and feeding conditions, providing a pathway into the internal network. This incident highlights how non-traditional IoT hardware can expand an organisation's attack surface.
How it works
The attack relies on the lack of network segmentation between IoT hardware and core business systems. When a smart aquarium connects to a network, it establishes a persistent communication path to the internet for telemetry. This connection provides a foothold for an attacker to move laterally. If the device shares a trusted network with sensitive servers, the attacker can use the aquarium as a proxy to reach internal systems. They then use the device's outbound permissions to move data from the internal environment to an external destination. The source from @scroll.engineer notes that the casino allowed the device to have network access and credentials that made it useful for this path.
- IoT Device ConnectionThe aquarium establishes a connection to the internet to transmit temperature and feeding data.
- Lateral MovementAn attacker identifies the device and uses it to scan for and reach internal systems or sensitive servers.
- Data ExfiltrationThe attacker moves 10GB of data out of the network through the established communication path.
What it takes to run
To deploy IoT hardware like a smart aquarium within a production environment, you must first define the boundaries of its network access. The device requires a path to the internet to send telemetry data regarding temperature and feeding conditions. It also needs an identity within your network, which involves managing credentials and firewall rules. You must decide if the device is permitted to communicate with any other internal systems or if it must remain isolated. Maintenance requires a process for firmware updates and monitoring the device's active connections to ensure it does not become a persistent proxy for outbound traffic.
- A dedicated network segment for IoT devices to prevent lateral movement.
- A firewall configuration that restricts outbound traffic to specific external endpoints.
- A credential management system for device authentication.
- A monitoring system to track telemetry data flow and connection states.
- A maintenance protocol for updating device software and security patches.
Where it breaks
IoT security fails when the hardware lacks the compute resources for robust encryption or local authentication. Most smart devices use hardcoded credentials or simplified protocols that do not support granular access control. If the device cannot perform identity verification at the edge, it relies entirely on the network to enforce security. When the network fails to isolate the device, the hardware becomes a transparent bridge. It cannot defend itself against lateral movement because it lacks the stack to inspect the traffic it carries. The failure occurs at the boundary where the device's outbound telemetry requirements overlap with the network's internal trust zones.
- Hardcoded credentials in firmware cannot be rotated by the user.
- Lack of local processing prevents the device from running an agent for monitoring.
- Simplified protocols may lack the headers required for deep packet inspection.
- Shared network segments allow the device to act as a proxy for internal scanning.
How we would build it
We treat every IoT device as a potential breach point rather than a peripheral utility. If a device requires internet access for telemetry, it must be treated as an untrusted endpoint. We do not rely on the hardware's internal security, as many smart devices lack the compute power for proper encryption or local authentication. Instead, we enforce security at the network layer by creating a zero-trust environment where the device is denied all lateral movement by default.
- Network SegmentationPlace all IoT hardware on a dedicated VLAN with no routing paths to the production environment.
- Egress FilteringApply firewall rules that restrict the device to specific IP addresses and ports required for its telemetry.
- Identity ManagementAssign unique, non-shared credentials to each device to prevent a single compromise from granting broad access.
- Traffic AnalysisMonitor the volume and frequency of outbound packets to identify anomalies in data exfiltration.
Most teams treat IoT devices as trusted endpoints on the corporate LAN. You must treat them as external threats. Instead of broad access, you write explicit firewall rules that permit only the specific IP addresses and ports required for the device to function.
Key takeaways
- IoT devices often lack the compute resources for local encryption or identity verification.
- Hardcoded credentials in firmware create permanent vulnerabilities that users cannot rotate.
- Security must be enforced at the network layer because the hardware cannot inspect its own traffic.
Frequently asked
How do I determine which external endpoints my IoT device needs to reach?
You must review the manufacturer's documentation to identify the specific IP addresses and ports required for telemetry.
Can I use a VPN to secure the device's telemetry traffic?
The article does not state whether the hardware supports VPN clients or if a gateway can tunnel the traffic.
What specific logs should I monitor to detect a proxy attack?
You should monitor the volume and frequency of outbound packets for anomalies that deviate from normal telemetry patterns.