A coffee machine as the way out: a small manufacturer's network compromised
A network review with no incident behind it found an attacker moving CAD files out via a coffee machine. Entry, spread, response and separating IT, OT and IoT.
- Company
- Slovak manufacturer, about 40 employees
- Environment
- Office PCs, two older Windows servers, engineering workstations, machines with PLCs
- Network
- Segmented on paper; in practice one flat network for IT and production
- Brief
- Find out how exposed the plant is. No incident, no alerts
- Duration
- About three weeks
01Starting point
The review was prompted by material the Slovak National Security Authority (NBU) had been publishing on PLCs and industrial environments. The owner wanted to know how exposed the plant was, from outside and from within. Nothing suggested an incident and no system had raised an alarm.
Office, servers, engineering workstations and shop-floor machines shared what was in practice a single network. The PLCs are mostly older units speaking Modbus/TCP, alongside some proprietary vendor traffic. Classic Modbus/TCP has neither authentication nor encryption: anyone on the same network can send a PLC commands.
The corporate Wi-Fi also carried a networked coffee machine in the break room, installed years earlier by its vendor. It was not in the IT asset inventory.
- Internet
- Perimeter router (port 3389 forwarded)
- Flat network: office, servers, engineering workstations, PLCs
- Corporate Wi-Fi: coffee machine
02The problem
The review began passively. Zeek and Suricata logged and analysed traffic on the network, runZero built the asset inventory and Wireshark served for manual inspection. Passive methods are a necessity around PLCs: actively scanning older units can crash them and stop production, so every active step was limited and scheduled in advance.
The Zeek connection logs showed a persistent, low-volume outbound flow to an Eastern European IP address with no reputation history. It was not HTTPS or DNS but an MQTT-like telemetry pattern with occasional cleartext metadata, on a non-standard port, at regular intervals and with small payloads. The source was not a PLC or a server. It was the coffee machine.
The machine did have a legitimate cloud endpoint from its manufacturer, but this traffic did not match it: a different destination, transfers larger than the device's normal profile, and a regular rhythm with small random jitter, typical of command-and-control (C2) beaconing rather than event-driven telemetry such as a brewed cup.
The conclusion: an attacker was already inside and using the coffee machine as a persistent covert way out. From their side it is an excellent choice: always on, rarely rebooted, no security agent, no logging, and nobody looks at its traffic. C2 frameworks such as Sliver, Mythic and Cobalt Strike are built for exactly this kind of low-and-slow communication with configurable timing. It is the same pattern as the 2017 Las Vegas casino case, where attackers used an internet-connected aquarium thermometer to get data out.
03Technical root cause
The entry point was one of the older Windows servers. The perimeter router forwarded port 3389 (Remote Desktop, RDP) to it from the internet, set up long ago for remote support and never removed. RDP exposed to the internet is under constant automated password guessing.
The flat network did the rest. From that server the engineering workstations, the PLCs and the coffee machine were all reachable, and nothing restricted where devices could talk to on the way out.
The coffee machine had factory default credentials, remote diagnostics enabled and its original firmware. Exactly how the attacker took it over cannot be determined from the available data, but none of that made it any harder. And because it was not in the inventory, nobody watched who it talked to.
04Investigation
First, isolate the coffee machine and preserve everything that could be kept from the device and the network logs, before changing anything. A reset or a power-off would have wiped the traces.
Entry: the Windows Security log on the server behind the RDP forward showed a long run of failed sign-ins (event 4625) followed by a successful one (4624) from a foreign address, consistent with a brute-force attack.
Persistence: Velociraptor for endpoint triage and hunting, with Sysmon telemetry on the Windows machines. The compromised server had a scheduled task re-launching a beaconing implant, and an engineering workstation held a second, dormant implant. The coffee machine was the hop the implants used to reach the outside, not their origin.
What left: the attacker had staged files on an engineering workstation before sending them out. The company runs an older CAD suite that saves models uncompressed, and the attacker did not pack them either. That made the transfer bulky and easy to recognise after the fact, but at a few gigabytes it was almost certainly spread out to keep the coffee machine from choking. Zeek showed transfers far beyond anything a coffee machine has reason to send, and together with the artefacts on the workstation this pointed to exfiltration over probably about two months. Only CAD and 3D model files left. No personal data, financial records or credentials were among them.
Obligations: since no personal data was involved, this was not a personal data breach to report under the GDPR. The company is below the thresholds of the Slovak Cybersecurity Act (69/2018), so it is not a regulated entity under NIS2. Given how the finding began, it informed the NBU voluntarily anyway.
05Remediation
Immediately: the coffee machine reset, its credentials changed and its firmware updated. The RDP forward removed from the router, both affected machines rebuilt and credentials rotated across the domain.
Segmentation: all IoT devices (coffee machines, digital signage, sensors) moved to a dedicated VLAN with outbound traffic denied by default and only specific vendor endpoints allowed. Production (OT) got its own segment following the zones and conduits model from IEC 62443: zones talk to each other only through defined conduits with rules. A few older PLCs that had direct internet access for no operational reason lost it.
Monitoring: Zeek stayed in place, so the company now has a baseline of normal traffic to compare against. Larger industrial environments use platforms such as Nozomi Networks, Claroty or Dragos, which understand industrial protocols more deeply. For a company this size, Security Onion or Malcolm are reasonable open-source starting points.
06Why the fix works
Removing the port forward closed the specific way in. The server is no longer reachable from the internet, so password guessing has nothing to aim at.
Rebuilding rather than cleaning: after a compromise there is no reliable way to prove that no further persistence is left on a machine. A clean install with new credentials is safer than hunting for every artefact.
Default-deny outbound turns the coffee machine from an ideal exit into a device that can reach only its manufacturer. Were it taken over again, it would have nowhere to send data.
Zones and conduits limit movement through the network: an office PC can no longer reach the PLCs or the engineering workstations directly.
A Zeek baseline makes deviations visible. What gave the attacker away was exactly that: a new destination, a regular rhythm and a volume that did not fit the device.
What it does not address: segmentation does not stop an attack within a single zone, and an allowed vendor endpoint is still trust placed in a third party. Monitoring finds only what somebody looks at.
07Validation
- Port 3389 on the company's public address is no longer reachable from the internet.
- After the reset the coffee machine talks only to the allowed vendor endpoints; the firewall drops everything else.
- New Zeek logs are compared against the traffic baseline.
08Results
Fixed
- The RDP way in is closed, the affected machines rebuilt, domain credentials rotated.
- The coffee machine is no longer an exfiltration channel.
Risk reduced
- IoT devices cannot reach the internet beyond allowed destinations.
- Production is separated from the office, and PLCs with no operational reason have no way out.
- The company knows what is connected to its network and has something to compare against.
Still open
- The CAD data that left cannot be recalled.
- When exactly the attacker got in cannot be determined from the available records.
09Limitations
- Monitoring is only as good as how often someone looks at it. The company has no security operations centre or round-the-clock service.
- Changes to PLC programs are not logged, so tampering with them might not show up in network records.
- Allowed vendor endpoints are trust in third parties. If one were compromised, the allowed path stays open.
10Lessons
- Looking fine from the inside does not mean it is fine. The attacker had been in for weeks without a single alert.
- A forgotten port forward is one of the most common ways in. Remote access belongs behind a VPN with two-factor authentication.
- An asset inventory must include everything that is connected, not just computers. A device nobody lists is a device nobody watches.
- Control outbound traffic, not just inbound.
- Around PLCs, start passively. Actively scanning older units can stop production.
- Rotating credentials after a domain compromise includes service accounts and the krbtgt account password, changed twice.
11Next steps for a small company
- 1.Remote access for vendors and staff only through a VPN with two-factor authentication, never through a port forward.
- 2.Once a quarter, review router and firewall rules and remove any nobody can explain.
- 3.Keep backups of PLC programs and compare them with what the PLCs are actually running.
- 4.Decide who looks at Zeek output and how often, or move to Security Onion with alerting.
Recognise your own company in this?
Tell us what it involves. We reply within one business day and say whether it is work for us, even when the answer is no.