In June 2017, a security researcher at UpGuard discovered that a third-party contractor working for Verizon had stored data about approximately 14 million Verizon customers in an Amazon S3 bucket — and left the bucket publicly readable. No credentials were required to access it. The data included customer names, account details, account PINs (used for customer service authentication), and in some cases billing data.
How it happened: The third-party contractor, NICE Systems, had configured the S3 bucket as part of a customer service analytics project. The contractor set the bucket's access policy to allow public read — a configuration mistake, not an attack. The bucket was live for an unknown period before the researcher discovered it by scanning for misconfigured S3 buckets. The researcher discovered it before any known malicious actor did, but there is no way to determine whether anyone else accessed the data during the exposure window.
Why this matters: The vulnerability required no exploit. An attacker did not need credentials, did not need to bypass a security control, did not need to run any exploit code. The misconfiguration meant the data was simply accessible to anyone who navigated to the URL. This is the defining characteristic of a permissions misconfiguration — the "attack" is just making a normal HTTP request.
Third-party risk dimension: Verizon did not directly create the misconfiguration — their contractor did. This mirrors the supply chain dimension: organizations extend access to third parties who may not apply the same security standards. Verizon's data, on Verizon's (contracted) infrastructure, exposed because a third party configured it incorrectly.
Exam takeaways: (1) Open permissions require no exploit — the misconfiguration IS the vulnerability. (2) Cloud storage resources (S3 buckets, Azure Blob containers, GCP Cloud Storage) are a common source of data exposure through open permissions. (3) Third-party contractors can introduce misconfigurations even in environments the organization controls. (4) "Publicly readable bucket" + "sensitive data" = breach, regardless of whether an attacker found it or a researcher did.
Mirai was a malware strain first identified in August 2016 that exploited a single misconfiguration at massive scale: IoT devices with unchanged default credentials. The result was one of the largest botnets in internet history and a DDoS attack that disrupted major websites for millions of users.
The technical mechanism: Mirai contained a hardcoded list of approximately 60 default username/password combinations sourced from manufacturer documentation for dozens of IoT device types. It continuously scanned random internet IP addresses looking for open Telnet (port 23) connections. When a device responded, Mirai tried each credential from its list. Devices with unchanged defaults — the majority of deployed IoT devices at the time — logged in immediately. Those devices were then enrolled in the botnet and began scanning for more victims.
Target devices: Mirai's credential list was tuned for consumer IoT devices: IP cameras, home routers, network video recorders (DVRs), doorbells, and similar embedded systems. These devices were numerous, internet-connected, rarely monitored, and almost never had their default credentials changed by end users or installers.
The DDoS attack: In October 2016, the Mirai botnet was directed against Dyn, a major DNS provider. DNS is the infrastructure that translates domain names to IP addresses — attacking DNS disrupts access to any website using that DNS provider. The attack generated traffic volumes that overwhelmed Dyn's infrastructure, taking down access to Twitter, Netflix, Reddit, GitHub, Spotify, and dozens of other major sites for much of the eastern United States and Europe.
Open-sourcing: After the Dyn attack, Mirai's authors published the source code publicly. This made the botnet's technique — default credential scanning for IoT — available to any attacker who wanted to deploy it. Multiple Mirai variants were subsequently launched using the published code.
Exam takeaways: (1) Default credentials on IoT devices are a critical misconfiguration — the username and password are publicly known, making authentication trivial to bypass. (2) Scale matters: a misconfiguration on one device is a minor risk; the same misconfiguration on hundreds of millions of devices is a global infrastructure threat. (3) Mirai targeted consumer devices, not enterprise servers — security thinking must include all networked devices, not just traditional IT assets.
The "Wall of Sheep" is a recurring demonstration at the DEFCON security conference in Las Vegas. Security researchers monitor the conference network for cleartext authentication traffic — connections using protocols like Telnet, FTP, IMAP, or HTTP — and display the harvested account names and partial passwords on a large public screen in real time.
Why it works: When a user connects to a mail server over IMAP (port 143, without TLS), their email client sends their username and password in plaintext. Anyone on the same network — and at a conference, that includes thousands of people — who is running a packet capture tool can read every credential transmitted. No exploitation is required: the protocol simply does not encrypt the traffic.
At DEFCON 22 (2014): The Wall of Sheep displayed email addresses and partial passwords from attendees who had connected to their email accounts over unencrypted IMAP. This happened in a room full of security professionals — many of whom knew about the risk but had not changed their email client configuration, had email apps on their phones set to use legacy settings, or were connecting through corporate email systems that still supported unencrypted IMAP.
The lesson the Wall of Sheep demonstrates: Protocol security is not about user sophistication or awareness — it is about configuration. An informed user on an unencrypted IMAP connection has their credentials exposed exactly as much as an uninformed user. The fix is not training: it is configuring mail servers to require IMAPS (port 993) and blocking connections on port 143 (plain IMAP).
Exam takeaways: (1) Cleartext protocols expose credentials to passive network observation — no active attack required. (2) Telnet, FTP, and plain IMAP/SMTP are legacy protocols that should be disabled; SSH, SFTP, and IMAPS/SMTPS are their encrypted replacements. (3) Packet capture tools like Wireshark can read cleartext traffic in real time and extract credentials with no special privileges beyond network access.
Scenario: A security analyst discovers that sensitive customer data is accessible to anyone on the internet without authentication. The data is stored in a cloud object storage service. No credentials were stolen and no vulnerability was exploited. The analyst also notes that a third-party vendor was responsible for setting up the storage resource six months ago. What type of vulnerability caused this exposure, and what controls should have prevented it?
Answer: This is an open permissions misconfiguration. The storage resource was configured with public read access — no exploit was needed because the access control simply permitted public access. Controls that would have prevented it: (1) Organization-level policy to block public access on all cloud storage resources by default. (2) Infrastructure-as-code templates that enforce private access for all storage resources and prevent public access settings. (3) Continuous cloud security posture monitoring (CSPM) that alerts when any storage resource is set to public access. (4) Third-party vendor contract requirements that specify cloud security configuration standards, with the organization retaining the right to audit vendor-created resources. (5) Regular cloud resource permission audits.
Scenario: A security engineer is reviewing a network of 200 IP cameras deployed across a corporate campus over the past three years. She discovers that every camera is accessible over the network on port 23 (Telnet) and that all cameras respond to login attempts using the manufacturer's published default credentials. What misconfiguration categories are present, and what remediation steps are needed?
Answer: Two misconfiguration categories are present: (1) Default settings/credentials — cameras have not had their factory default username/password changed; these credentials are publicly known, making authentication trivially bypassable. (2) Insecure protocols — Telnet (port 23) is enabled; all management traffic is transmitted in cleartext, allowing any network observer to read credentials and commands. Remediation: (a) Change the default credentials on all 200 cameras immediately — unique credentials per device or at minimum non-default credentials. (b) Disable Telnet on all cameras; if remote management is required, configure SSH or HTTPS-based management interfaces. (c) Block port 23 at the network firewall to prevent Telnet access even if it remains enabled on individual devices. (d) Network-segment the camera management network so cameras are not accessible from the general corporate network. (e) Establish a policy that requires credential changes and protocol hardening before any new device is connected to the network.
Scenario: A penetration tester discovers during an internal assessment that: (1) the root account on Linux servers accepts direct SSH logins with password "Password1", (2) 31 of 50 Active Directory accounts have Domain Admin rights, and (3) a service account running a web application has been granted local administrator rights on every server in the environment "because it was easier." What is wrong with each finding, and what is the correct configuration for each?
Answer: (1) Direct root SSH login with weak password: Direct root login over SSH should be disabled (set PermitRootLogin no in sshd_config). Administrators should log in with their own named accounts and elevate with sudo. Additionally, "Password1" is a trivially weak password — root accounts require strong, unique passwords and ideally key-based authentication with MFA. (2) 31 of 50 accounts with Domain Admin: Domain Admin is the highest privilege in an Active Directory environment; it should be granted to the absolute minimum number of accounts required for specific administrative tasks, not used as a general IT role. Least-privilege principle: most IT staff should have standard user accounts and only elevate to admin rights for specific tasks. Conduct a privilege access review and revoke Domain Admin from all accounts that do not have a specific, documented business need for it. (3) Service account with local admin on all servers: Service accounts should run with the minimum permissions required to perform their function. A web application service account almost certainly does not need local administrator rights on every server. Granting admin rights "because it was easier" is the textbook definition of misconfiguration — the path of least resistance creates an attack vector. If an attacker compromises the web application, they inherit the service account's credentials and with them local admin rights across the entire server fleet.