The Five Misconfiguration Categories
Misconfigurations are not code flaws — they are settings that are wrong. An attacker exploiting a misconfiguration does not need to bypass security controls; the misconfiguration means the control was never applied. Each of the five categories below represents a distinct type of "the configuration was wrong."
| Category | What's Misconfigured | How It's Exploited | Real Example | Fix |
|---|---|---|---|---|
| Open Permissions | Access control on a resource (storage bucket, file share, directory) is set to allow public or overly broad access | Attacker navigates directly to the resource URL — no credentials, no exploit required; the data is simply available | Verizon: 14M customer records in public S3 bucket (2017) | Apply least-privilege to all storage resources; audit bucket/share permissions regularly; block public access at the account level |
| Unsecured Admin Accounts | Built-in admin accounts (root, Administrator) are enabled with weak or unchanged passwords, or too many accounts have admin rights | Attacker brute-forces or credential-stuffs the known admin username; once in, has full system control | Common attack vector: default root/admin credentials on servers, IoT devices, network equipment | Disable direct root/Administrator login; require su/sudo elevation; apply least-privilege; minimize accounts with admin rights; enforce strong passwords + MFA |
| Insecure Protocols | Legacy cleartext protocols (Telnet, FTP, SMTP/IMAP without TLS) are in use instead of encrypted equivalents | Attacker captures network traffic (packet capture / on-path); reads credentials and data in plaintext | DEFCON Wall of Sheep: real-time credential display from conference network cleartext traffic | Replace Telnet→SSH; FTP→SFTP; IMAP/SMTP→IMAPS/SMTPS; require TLS on all network services |
| Default Settings | Hardware/software deployed with factory-default credentials or configurations that are publicly documented | Attacker tries known default credentials (admin/admin, root/root, device-specific defaults) — no brute force needed | Mirai botnet: 60+ IoT default credentials, compromised hundreds of thousands of cameras/routers/doorbells | Change all credentials before deployment; disable unused services in default config; apply vendor hardening guides |
| Open Ports & Services | Firewall rulesets have accumulated open ports for services that are no longer needed or should not be exposed | Attacker port-scans the target, identifies open services, attempts exploitation of listening services | Port scan discovers Telnet (23), FTP (21) still open from legacy systems never decommissioned | Periodic firewall audits; apply default-deny (block all, allow specific); decommission services when no longer needed; document and justify every open port |
Open Permissions: The S3 Access Control Model
Amazon S3 uses a layered permission model. Misconfiguration can happen at any layer, and each layer that grants public access overrides restrictions at other layers.
AWS Account Level
Block Public Access setting — can block all public access for all buckets in the account. Correct config: enabled.
↓
Bucket Level
Each bucket has its own ACL and bucket policy. A misconfigured bucket policy of
"Principal": "*" grants access to everyone on the internet.↓
Object Level
Individual objects can be set to public-read. A bucket can be private but individual objects made public — or vice versa.
↓
Result
Any "allow public" at any layer can expose data. Third-party contractors who create buckets may not apply the organization's standard policy — which is exactly what happened with Verizon's 2017 breach.
Insecure vs. Secure Protocol Replacements
Insecure (Cleartext)
- Telnet (port 23) — remote terminal; credentials and commands in plaintext
- FTP (port 21) — file transfer; credentials and file content in plaintext
- SMTP (port 25) — email sending without TLS; message content in plaintext
- IMAP (port 143) — email retrieval without TLS; credentials in plaintext
- HTTP (port 80) — web traffic without TLS; all content in plaintext
- SNMP v1/v2 — network management; community string in plaintext
Secure Replacements
- SSH (port 22) — encrypted remote terminal; replaces Telnet
- SFTP (port 22) — encrypted file transfer over SSH; replaces FTP
- SMTPS / SMTP+STARTTLS — encrypted email sending; replaces plain SMTP
- IMAPS (port 993) — encrypted email retrieval; replaces plain IMAP
- HTTPS (port 443) — encrypted web traffic; replaces HTTP
- SNMP v3 — authenticated and encrypted network management
Mirai Botnet: How Default Credentials Scale to a Catastrophe
Mirai demonstrated the industrial-scale effect of widespread default credential misconfiguration. The attack was not technically sophisticated — it was a scale problem.
Step 1: Credential List
Mirai contained a hardcoded list of approximately 60 default username/password combinations (admin/admin, root/xc3511, admin/1234, etc.) sourced from vendor documentation for dozens of IoT device types.
↓
Step 2: Internet-Wide Scan
Mirai-infected devices continuously scanned random IPv4 address space, probing for Telnet (port 23) and other management ports. At peak, Mirai generated significant internet scanning traffic.
↓
Step 3: Credential Testing
When a device responded on Telnet, Mirai tried each of its 60 credential combinations. Devices with unchanged defaults logged in immediately — no brute force, just the first or second attempt.
↓
Step 4: Infection and Propagation
Successfully logged-in devices were added to the botnet and began scanning for more victims. The botnet grew rapidly — cameras, routers, doorbells, DVRs, garage door openers.
↓
Step 5: DDoS Attack
The botnet was directed against DNS provider Dyn in October 2016, generating massive traffic that disrupted major websites including Twitter, Netflix, Reddit, and GitHub. After use, the source code was published publicly.
Least-Privilege for Admin Accounts
Common Misconfigurations
- Built-in root/Administrator accounts enabled with weak passwords
- Direct root SSH login allowed
- All IT staff members have full admin rights "just in case"
- Service accounts running as root/SYSTEM with no need for it
- Shared admin credentials used by multiple people (no individual accountability)
- Admin accounts that were provisioned for projects and never revoked
Correct Configuration
- Disable direct root/Administrator login; require named accounts + su/sudo elevation
- Each admin has their own named account (audit trail)
- Admin rights granted only for specific, documented business need
- Regular access reviews — revoke admin rights when no longer needed
- Service accounts run with minimal required permissions, not root/SYSTEM
- MFA required for all privileged account access
Firewall Audit: What to Look For
| Audit Finding | Risk | Action |
|---|---|---|
| Open port with no corresponding current service | Listening service may be vulnerable; attack surface with no business value | Identify the service; disable if not needed; close the port |
| Rule with "allow any source" or "allow any destination" | Overly broad rule may allow unintended traffic; masks which traffic is actually needed | Narrow to specific source/destination IPs; document justification |
| Rules for decommissioned systems or old IP ranges | Rules that no longer match any current asset may inadvertently permit unexpected traffic | Remove stale rules; verify IP ranges still belong to intended assets |
| Legacy protocol ports open (23/Telnet, 21/FTP) | Cleartext traffic on network; credentials exposed to any network observer | Migrate to SSH/SFTP; close Telnet and FTP ports at firewall |
| Rule conflicts (deny overridden by later allow) | Intended block may not be effective if a later rule permits the same traffic | Review rule order; firewall rules are evaluated top-down — earlier rules take precedence in most systems |
| Rules undocumented or without a business owner | No way to assess whether the rule is still needed; no accountability | Require business justification for every rule; flag undocumented rules for review |