Exercise 2: Why Documented Defaults Are More Dangerous — Possible Solution
====================================================================

A custom, undocumented misconfiguration is at least somewhat unique to
that specific system — an attacker has to actually discover it exists
before they can exploit it, which takes time, effort, or luck. A
default sample database or demo account, by contrast, is EXACTLY THE
SAME across every installation of that database engine that never
removed it — its existence, its default name, and often its default
credentials are all published in the vendor's own documentation,
tutorials, and countless articles online.

WHAT "PUBLICLY DOCUMENTED" CHANGES: it removes the discovery step
entirely for an attacker. Rather than needing to probe a specific
target to find a weakness, an attacker (or, more realistically, an
automated scanning tool) can simply check for the well-known default
account or sample database by name, because that name and its
properties are already public knowledge shared across every
installation of that software. This turns a single piece of published
information into a reusable, automatable attack against every
un-hardened installation of that database engine anywhere, rather than
requiring custom reconnaissance against one specific system.

This is exactly why removing defaults matters even though "nobody
would guess our specific custom misconfiguration" might be true — the
defaults were never a secret to begin with, so there was never
anything to guess.