> root@coffee-iot:~# strings firmware.bin | grep -i 'WPA_PASSPHRASE'<span class="cursor-blink">_</span>_
The coffee machine arrived on a Tuesday. It was a premium, internet-enabled, bean-to-cup machine — the kind that connects to the manufacturer's cloud platform so the facilities team can monitor bean levels, water filter status, and daily consumption statistics from a dashboard on their phone. It cost roughly two thousand pounds. It was installed in the fourth-floor kitchen by the supplier's engineer, who plugged it into a power socket, connected it to the nearest network port, helped the office manager download the companion app, and left.
Nobody told IT. Nobody submitted a change request. Nobody asked whether the network port in the kitchen was on a segregated VLAN or whether the coffee machine's embedded operating system met the organisation's security baseline. The machine made excellent coffee. That was its entire selection criteria.
Six weeks later, we arrived for an internal penetration test. The coffee machine was the first device we compromised. It would not be the last.
The client was a technology company with approximately two hundred and fifty staff, operating from a single modern office in a business park. They had engaged us for an annual internal network penetration test — a recurring engagement that we had conducted for the previous two years. The scope was consistent with prior years: assumed-insider access from a user VLAN, with the objective of testing lateral movement, privilege escalation, and the effectiveness of recently implemented security controls.
The client had been making steady improvements to their security posture. Following our recommendations from the previous year, they had deployed EDR across all workstations, enforced SMB signing, implemented LAPS for local administrator passwords, disabled LLMNR and NBT-NS, and begun work on network segmentation. They were expecting — not unreasonably — that this year's assessment would demonstrate measurable progress.
It did. Their workstations were considerably harder to attack than the previous year. The path we found instead went through the kitchen.
We connected to our assigned network port on the user VLAN and began our standard reconnaissance workflow — passive capture followed by active enumeration. The passive capture was immediately quieter than previous years. LLMNR and NBT-NS had been disabled, removing the broadcast chatter that had provided easy credential harvesting opportunities on prior engagements. This was tangible evidence of improvement.
During the active scan of the 10.20.4.0/24 user VLAN, we identified the usual population of Windows workstations, network printers, and VoIP handsets. We also identified a device that had not been present on any previous assessment.
The device profile was immediately recognisable as consumer IoT — an embedded Linux system running lightweight services, with an MQTT broker and a REST API. The MAC vendor OUI resolved to a manufacturer of connected kitchen appliances. The mDNS announcement confirmed it: the device was broadcasting a friendly name that included the manufacturer's brand and the model designation of a commercial bean-to-cup coffee machine.
A coffee machine. On the user VLAN. With SSH, HTTP, MQTT, and a REST API. Sitting alongside workstations, printers, and — one subnet hop away — the organisation's servers and domain controllers.
An internet-enabled coffee machine had been connected to the corporate user VLAN without the knowledge of the IT department. The device did not appear in the organisation's asset register, was not covered by any security controls, and was running an embedded Linux operating system with multiple network services exposed.
We accessed the HTTP interface on port 80. The device served a management dashboard — attractively designed, clearly intended for facilities staff, displaying real-time statistics on daily cup count, bean hopper levels, water filter life, drip tray capacity, and maintenance alerts. A navigation panel offered sections for device settings, network configuration, cloud connectivity, and firmware updates.
There was no authentication. No login page. No password prompt. The full administrative interface was accessible to any device on the network without credentials of any kind.
The network configuration page disclosed the device's full network settings: IP address, subnet mask, gateway, DNS servers, MAC address, and — critically — the Wi-Fi configuration. The machine was dual-homed. In addition to its wired Ethernet connection to the corporate network, it maintained a wireless connection to a network named CoffeeMgmt, which the device used to communicate with the manufacturer's cloud platform and to allow the companion mobile app to connect for local management.
The wireless PSK and the cloud authentication token were masked in the web interface — displayed as bullet characters rather than plaintext. This is a cosmetic control, not a security one. The values still existed in the device's configuration and could be retrieved through other means. The dashboard had, however, already given us everything else: the internal network topology, the DNS servers (which were the domain controllers), and the existence of a secondary wireless network that the machine was hosting.
The web interface included a firmware update page that displayed the current firmware version and provided a mechanism for uploading update packages. Crucially, it also provided a link to check for updates from the manufacturer's server — and the current firmware package was available for download directly from the manufacturer's public support portal. No authentication was required to download it.
We downloaded the firmware package onto our assessment laptop and began analysis.
The firmware image contained a standard embedded Linux filesystem. Binwalk extracted a SquashFS root filesystem and a JFFS2 data partition. The SquashFS partition contained the operating system, web server files, application binaries, and configuration templates. The JFFS2 partition was where the device stored its runtime configuration — the settings that change after deployment, including network credentials.
We examined the extracted filesystem methodically.
The /etc/shadow file contained the root password hash, stored using the MD5-crypt algorithm — a hashing scheme so weak that it has been deprecated for over a decade. The hash cracked in fourteen seconds. The password was the manufacturer's name followed by '123'. This was a hardcoded default root credential, compiled into the firmware, identical on every device of this model sold anywhere in the world.
But the firmware analysis yielded more than just the root password.
The firmware contained hardcoded MQTT broker credentials, a cloud API secret, a default Wi-Fi AP passphrase that followed a predictable pattern, an RSA private key for TLS communication (shared across all devices of the same model — a catastrophic key management failure), and fallback credentials embedded in the application binary itself.
Every secret the device used to authenticate to every service it communicated with was recoverable from firmware that anyone could download from the manufacturer's public website.
With the root password recovered from the firmware analysis, we connected to the coffee machine's SSH service.
Root access to the coffee machine. A 256MB ARM-based Linux system with a writable data partition and enough free space and memory to host additional tools. The device was compact but capable — far more capable than a machine whose sole purpose was to dispense espresso had any right to be.
We examined the runtime configuration stored on the data partition. This is where the device stores the settings applied after deployment — the values that were masked in the web interface.
The Wi-Fi passphrase, the cloud authentication token, and the device identity were all stored in plaintext JSON on the data partition. The CoffeeMgmt wireless network passphrase was FreshBeans2023! — set by the installer during commissioning and never changed.
We now had root access to a Linux device on the corporate user VLAN. The device had a writable filesystem, network connectivity to the same subnet as user workstations, and DNS resolution pointing at the domain controllers. We treated it exactly as we would treat any other compromised Linux host — as an operational platform for lateral movement.
The coffee machine had limited storage and no package manager, but it had BusyBox, netcat, and a functioning shell. We uploaded a statically compiled ARM build of Nmap and a custom credential harvesting tool to the /data partition via SCP.
From the coffee machine, we performed a targeted scan of the server VLAN at 10.20.1.0/24. The user VLAN had limited access to the server VLAN — the firewall rules permitted only DNS (UDP 53) and Kerberos (TCP 88) from the user VLAN to the domain controllers. But the coffee machine was not a workstation. It did not have the EDR agent that monitored outbound connections from Windows hosts. It was not subject to the host-based firewall rules pushed via Group Policy. It existed outside every endpoint security control the organisation had deployed.
We tested the firewall rules from the coffee machine's IP address and discovered that the access control lists applied to the user VLAN were based on source VLAN, not source host. The coffee machine, as a member of the user VLAN, had the same network access as any workstation — but without any of the endpoint controls. The firewall did not distinguish between a managed Windows workstation and an unmanaged coffee machine.
The coffee machine inherited the network access permissions of the user VLAN, including connectivity to DNS and Kerberos services on the domain controllers. The organisation's firewall rules did not differentiate between managed endpoints and unmanaged IoT devices on the same VLAN.
With LLMNR and NBT-NS disabled across the environment, our usual Responder-based credential harvesting was not viable — the client's hardening work had genuinely eliminated that vector. We needed a different approach.
The coffee machine's MQTT broker on port 1883 was accessible from the network without authentication. We subscribed to its topics and observed the traffic patterns. The machine published telemetry data every thirty seconds — cup counts, temperatures, maintenance states. But it also received messages. The companion mobile app, used by the facilities manager, connected to the MQTT broker over the CoffeeMgmt wireless network and published configuration commands.
We also discovered that the REST API on port 8443 accepted unauthenticated requests and exposed an endpoint that returned the device's complete configuration — including its configured DNS settings. Using root access, we modified the coffee machine's DNS configuration to point to our assessment laptop, where we ran a custom DNS responder that served legitimate responses for all queries except those for the organisation's internal domain — for which it returned our laptop's IP address.
This was not a standard DNS poisoning attack against the network. It was localised to the coffee machine itself. But the coffee machine's web interface was occasionally accessed by the facilities manager from her workstation to check consumable levels. When her browser resolved the coffee machine's hostname via the corporate DNS — which still worked normally — she reached the legitimate interface. But any resources the interface loaded from internal hostnames were resolved by the coffee machine's modified DNS, redirecting requests through our infrastructure.
More productively, we used our root access to deploy a network sniffer on the coffee machine's Ethernet interface. The device was on a switched network, so broadcast traffic was limited — but we could observe ARP traffic, mDNS queries, and any traffic directed to or through the coffee machine's IP address. We combined this with ARP spoofing targeting specific hosts on the local subnet, positioning the coffee machine as a man-in-the-middle for selected traffic flows.
The ARP spoofing yielded credentials within the first hour. An internal wiki running on HTTP (not HTTPS) exposed a user's Basic authentication credentials in cleartext. An NTLM authentication exchange to an internal file share provided a hash suitable for offline cracking. And an FTP connection to a legacy data import server delivered credentials in plaintext — FTP transmits everything, including passwords, without encryption.
The FTP credentials belonged to a service account used for automated data imports. This account, when tested against the domain, proved to have local administrator rights on several servers — a relic of the account's original provisioning that had never been reviewed or revoked.
From the coffee machine, we used the compromised FTP service account credentials to authenticate to a data import server on the server VLAN. The firewall rules permitted this connection because the FTP service was legitimately accessed from the user VLAN.
On the data import server, we extracted additional cached credentials using our standard post-compromise methodology. Among the cached credentials was an account with Domain Admins membership — a senior systems administrator who had logged onto the server to troubleshoot a data import failure three weeks prior and whose credentials remained cached in the system's credential store.
The path from the coffee machine to domain administrator had taken approximately five hours of active work.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | Identified consumer IoT coffee machine on user VLAN | Unregistered device connected without IT knowledge or approval |
| 02 | Accessed unauthenticated web management interface | No authentication on administrative interface |
| 03 | Downloaded and analysed firmware from manufacturer website | Firmware publicly available; secrets hardcoded; weak password hash |
| 04 | Cracked root password from firmware /etc/shadow (14 seconds) | MD5-crypt hash; manufacturer name + '123' as password |
| 05 | SSH root access to coffee machine | Hardcoded default root credentials identical across all units |
| 06 | Deployed ARP spoofing from compromised device | No dynamic ARP inspection; no port security on switch |
| 07 | Captured FTP credentials from intercepted traffic | Legacy FTP service transmitting credentials in cleartext |
| 08 | Pivoted to data import server; extracted cached domain admin creds | Overprivileged service account; cached admin credentials on server |
This engagement illustrates a challenge that security teams face with increasing frequency: the infiltration of consumer-grade IoT devices into corporate networks through procurement channels that bypass IT governance entirely.
The coffee machine was not purchased by IT. It was purchased by the office manager through a facilities budget. It was installed by the manufacturer's engineer, who connected it to the nearest available network port — which happened to be on the corporate user VLAN. No change request was submitted. No risk assessment was conducted. No security review was performed. The device was not added to the asset register. It was not covered by the vulnerability management programme. It was not monitored by the SIEM.
The client in this engagement had done excellent work on their workstation security. Their EDR deployment, SMB signing enforcement, LLMNR disablement, and LAPS implementation represented genuine, measurable progress. On a workstation-only assessment, they would have performed well.
But the attack path did not use a workstation. It used a coffee machine that nobody knew was there.
The immediate priority was removing the coffee machine from the corporate network and reconnecting it — if connectivity was required for facilities management — to a dedicated IoT VLAN that permits outbound internet access only, with no routing to internal corporate networks. The coffee machine needs to talk to the manufacturer's cloud. It does not need to talk to the domain controllers.
802.1X port authentication or MAC-based authentication would have prevented the coffee machine from obtaining a valid network connection in the first place. Unknown devices should be placed into a quarantine VLAN automatically, preventing them from accessing corporate resources until explicitly approved by IT.
Dynamic ARP Inspection on the access switches would have detected and blocked the ARP spoofing attack that enabled our credential interception. This is a standard Layer 2 security feature available on all enterprise-grade switches, yet it is disabled by default and rarely enabled.
The underlying procurement and governance issue is equally important. A procurement policy requiring IT review and approval for any device that connects to the network — whether purchased through IT budgets or not — would have caught this device before it was deployed. The policy need not be burdensome: a simple notification to IT that a connected device is being installed, combined with a brief assessment of its network requirements, would have resulted in the coffee machine being placed on an appropriate VLAN from day one.
There is a lesson in this engagement that extends beyond coffee machines. Every organisation has a procurement process that was designed for a world in which kitchen appliances did not have IP addresses. That world no longer exists. A refrigerator has a network stack. A dishwasher has firmware. A coffee machine has root access.
The security improvements this client had made were genuine and effective. Their workstations were well-defended. Their credentials were properly managed. Their protocols were hardened. But none of those controls extended to a device that was purchased on a corporate credit card, delivered by a courier, and plugged into the network by someone whose primary concern was whether it made a decent flat white.
It did, as it happens. Excellent coffee. Terrible security.
Until next time — stay sharp, stay curious, and check what is connected to the network port behind the kettle.
This article describes a penetration test conducted under formal engagement with full written authorisation from the client. All identifying details have been altered or omitted to preserve client confidentiality. The techniques described were performed within the scope of a legal agreement. Unauthorised access to computer systems is a criminal offence under the Computer Misuse Act 1990 and equivalent legislation worldwide. Do not attempt to replicate these techniques without proper authorisation.
Hedgehog Security finds the devices that asset registers miss. Consumer IoT, shadow IT, unmanaged infrastructure — if it has an IP address and it is on your network, it is in your attack surface. Let us show you what is hiding in your kitchen, your meeting rooms, and your building management systems.