Maya had been doing cloud security assessments for two years, and she'd developed a habit: before reviewing any application code, she scanned for open buckets. She could hear her mentor's voice every time she did it — "The most dangerous vulnerability isn't the clever zero-day. It's the setting someone forgot to change."
This morning she was onboarding a new client, a regional telecom. The intake form said their AWS environment was "locked down and audited quarterly." She typed the first S3 bucket name from their asset inventory into her tool and waited.
The response came back in under a second: 403 Forbidden. Locked. Good. She tried the second bucket. 403. Third: 403. Fourth: 200 OK — public access enabled.
She navigated to the URL. A directory listing loaded in her browser — no authentication, no credential prompt. A list of filenames scrolled past: customer_export_2024_Q3.csv, billing_records_full.csv, support_tickets_with_PII.json. She didn't open any of them. She immediately called her client contact.
"That bucket was set up by a contractor six months ago," the contact said, voice flat. "We didn't know it was public."
Nobody ever does, Maya thought, until someone finds it.
A misconfigured access control — like a publicly readable Amazon S3 bucket — exposes data to anyone who knows the URL. In 2017, a Verizon contractor left 14 million customer records in an open S3 bucket accessible to the public internet. No exploit required: the data was simply available. The misconfiguration was the vulnerability. The "attacker" in that case was a security researcher — but it just as easily could have been someone with worse intentions.
After the bucket incident was contained, Maya turned to the second item on her checklist. She requested the client's Active Directory configuration report and scanned for the Administrator account status.
The report showed that the built-in Administrator account on 47 Windows servers was enabled, with the same password on all of them. She ran a quick check on the Linux jump server: the root account accepted direct SSH logins. She looked at their password policy — minimum eight characters, no complexity requirement, no expiration. She pulled the list of active admin accounts: 34 users with full administrative privileges.
"Why does your receptionist have admin rights?" she asked the IT lead on the call.
A pause. "She asked for them when she joined. Four years ago. We never took them away."
Maya had heard variations of this story at almost every client. Privileges accumulated. Accounts were never cleaned up. The default administrative accounts that come with every operating system sat enabled, accessible, waiting.
Every operating system ships with powerful built-in accounts: root on Linux/Unix systems, Administrator on Windows. These accounts are among the most targeted by attackers — they provide unrestricted system access and their usernames are already known. Weak passwords (the most common include 123456, ninja, and football) make them trivially brute-forceable. Best practice: disable direct root/Administrator logins, require elevation through su or sudo, and apply least-privilege — minimize the number of accounts that have administrative access at all.
The third finding was quieter, but in some ways it bothered Maya most.
She ran a packet capture on the client's internal management network for twenty minutes — a standard part of her assessment. When she opened the capture file, she saw it immediately: TELNET sessions, in the clear. Every character typed — usernames, passwords, commands — plaintext in the packet stream. She also spotted FTP traffic, same problem. An IMAP mail client connecting to an internal mail server with no TLS.
She thought about DEFCON 22, where the security researchers had set up a "wall of sheep" — a display board showing email addresses and partial passwords harvested in real time from attendees who had connected to the conference network using unencrypted protocols. Security professionals, many of them, connecting to mail servers over IMAP without encryption, watching their own credentials appear on the wall. The point wasn't to shame anyone — it was to make viscerally clear how visible cleartext traffic is to anyone on the same network.
An attacker with network access to this client's management segment wouldn't need to exploit anything. They just needed to capture packets.
Certain legacy protocols transmit data — including credentials — in cleartext: Telnet (remote access), FTP (file transfer), SMTP/IMAP without TLS (email). Any attacker who can intercept network traffic can read everything. The fix is straightforward: replace Telnet with SSH, replace FTP with SFTP, require TLS/HTTPS for web and API traffic, and configure mail servers to require IMAPS/SMTPS. DEFCON's "wall of sheep" — a real-time display of credentials harvested from cleartext traffic on the conference network — demonstrates exactly how exposed these protocols leave their users.
Maya saved the most predictable finding for last in her notes, but it never failed to appear. She ran a credential scan against the network devices on the client's inventory — switches, routers, a half-dozen IP cameras, a network-connected thermostat system, two VoIP handsets, and a DVR unit.
The cameras logged in on the first try: username admin, password admin. So did the thermostat. The DVR: admin / 1234. One of the VoIP phones still had the manufacturer default of root / root.
She thought about Mirai. In 2016, the Mirai botnet had scanned the entire internet looking for IoT devices with default credentials — not a sophisticated hack, just automated credential stuffing against a list of roughly 60 known default username/password combinations. Cameras. Routers. Doorbells. Garage door openers. Hundreds of thousands of devices logged in, became bots, and then participated in one of the largest DDoS attacks ever recorded. The botnet's creators open-sourced the code when they were done with it, making it available to anyone who wanted to build their own.
"How long have these cameras been installed?" Maya asked.
"About two years," the IT lead said.
"Still on the default password?"
"I guess we never changed it."
Hardware and software ship with default credentials and configurations that are published in vendor documentation — which means attackers have them too. The Mirai botnet (2016) used a list of approximately 60 default IoT credential combinations to automatically compromise cameras, routers, doorbells, and garage door openers at massive scale. Mirai's code was eventually open-sourced, making this technique available to any attacker. The fix is simple and non-negotiable: change all default credentials before deployment. Never put a device on a network with factory defaults intact.
On her last day at the client site, Maya ran a full port scan of their externally facing IP space and their internal server subnet. She compiled the results against their firewall ruleset documentation.
The discrepancies were immediate. Several ports were open that the documentation said should be closed — services that had been started for a project two years ago and never shut down. A few firewall rules with "allow any any" entries dated from a migration project. One rule allowed inbound connections from an IP range that no longer existed in their environment — it had been created during an acquisition that was subsequently unwound, but the rule stayed.
Firewall rulesets grew over time, she explained to the client team at her debrief. Every new service needed a rule. Every project opened ports. Very few were ever closed when the project ended. The ruleset grew more complex, harder to audit, and the security posture drifted from the documented policy. Each open port was an entry point — a listening service, potentially vulnerable, definitely reachable.
"Schedule quarterly reviews," she told them. "The ruleset you have today is not the ruleset you had two years ago, and it's probably not the one your policy says you have."
Every open network port represents a running service — and a potential entry point for attackers. Firewall rulesets manage which ports are accessible, but they accumulate over time: rules are added for new services and projects but rarely removed when those services are decommissioned. The result is a ruleset that is increasingly complex, error-prone, and inconsistent with documented policy. The defense is simple but requires discipline: periodic firewall audits to identify ports that should be closed, services that should be disabled, and rules that no longer match any current business requirement.