root/blog/full-compromise-from-lobby
secure channel

// full-compromise-from-lobby.mdx

Full Domain Compromise from the Lobby

The client restricted me to the lobby with no credentials — I had domain admin before the morning was over.

2022-06-12[wireless] [iot] [physical] [penetration testing]

The rules of engagement for this wireless penetration test were deliberately restrictive. The client's point of contact wanted to see what an attacker could accomplish from the most constrained starting position available: the public lobby, no credentials, no prior knowledge of the internal environment. It is the kind of scope that sounds limiting but is actually an interesting challenge because it forces you to work with what you can physically observe.

What I could physically observe in the lobby was an iPad kiosk.

The kiosk was running some kind of visitor management or information display application, locked into a single-purpose mode by the device's configuration. The PIN protecting access to the underlying tablet was four digits. I tried 1234. That was it. The tablet was open.

From there the objective was to get wireless credentials onto my laptop so I could join the same network the tablet was connected to. The tablet had built-in network sharing capability, and I was able to use it to share its wireless connection. My laptop joined the guest IoT network.

The guest IoT network was intended to be isolated. It was not well isolated. Doing a scan of the network, I found a printer that had no authentication on its administrative web interface. This is not an unusual finding; network printers are frequently deployed with default or no credentials and forgotten. What was unusual was the content of the admin panel.

A firmware bug in this specific printer caused a service account credential to render in plaintext in the HTML source of one of the administrative pages. Not in a form field, not in a password prompt. Just sitting in the page source, visible to anyone who loaded the page and looked at the markup. I looked at the markup.

The credential was a service account. I tried it against the enterprise WPA2 network that the guest IoT segment was supposed to be separated from. It authenticated.

I was now on the enterprise wireless network with a valid service account credential. The service account had been granted domain admin privileges, likely by someone who found it easier to give it broad access than to figure out the minimum permissions it actually needed. That is a configuration decision that gets made constantly in enterprise environments, usually not by security people, and usually without anyone thinking carefully about what it means if the credential is ever exposed.

From the enterprise network with a domain admin credential, the rest was administrative work. Full domain compromise, starting from the lobby.

The remediation picture touched every layer of this chain: the kiosk PIN (use a complex passcode; consider a proper kiosk management solution that does not expose the underlying OS), the IoT network segmentation (guest and IoT devices should not be able to reach administrative printer interfaces), the printer firmware (update it; disable the admin interface if it is not actively needed), service account privilege (apply least privilege; no service account that logs into a printer needs domain admin), and the enterprise WPA2 credential exposure (rotate it; audit all service accounts with elevated domain privileges).

The client had been confident in their perimeter because they were thinking about their firewall and their VPN. They were not thinking about the printer in the lobby hallway.