The Door Beside the Front Door

TL;DR: A public university with a single sign-on gateway, a consent banner that actually blocks trackers, and a learning platform on the current security release. One fleet run across four waves (48 units, 445 findings) found the real exposure standing beside the front door: the mail backend answered anonymous requests outside SSO and outside MFA, a mailing-list host ran software from 2010 with live-reproducible takeover classes, a document appliance sat inside a 9.8 auth-bypass range, and public certificates conveniently published 103 internal hostnames. Across two full assessment waves, nothing — no rate-limit, no challenge, no block — ever slowed the traffic down.

The scenario

The estate looked disciplined from the outside. A single sign-on gateway in front of the portal. A consent setup that genuinely stops trackers. A current learning platform, clean hygiene on the main website, no dotfiles, no backups lying around. This is the profile of an organisation that does have a security practice.

A fleet of 48 agent units ran four waves against it: a surface pass, a targeted pass, a deep pass on the major systems, and a verification wave that re-ran every high finding on fresh evidence. The result is a reminder that an estate is not judged by its front door.

I removed all identifying information. The target is described only by sector and technology class so the pattern can be reused.

The pattern

The SSO front door is not the perimeter

The identity gateway was doing its job: unknown hosts rejected, sessions managed, no cookie handed out before authentication. Beside it, however, the edge carried a path-prefix exemption — the whole mail web prefix was excluded from the gateway so that mail clients could talk to it directly.

That exception is the architecture of the entire story. It meant that the mailbox endpoints answering Basic/NTLM challenges on the open internet were never anonymous by accident: someone configured every URL under that prefix to bypass the front door. The exemption was a wildcard, not a list — and wildcards grow. The build number was readable from response headers on all eight front-end nodes, and it sat two security updates behind, with a seven-CVE gap that included an unauthenticated, email-borne remote code execution.

The lesson: enumerate what your identity layer exempts, and treat the exemption prefix as your real attack surface. Then test it from outside, the way an attacker would.

Patch lag hides in plain sight

Two hosts carried the most severe exposure, and neither was hidden:

• The mail farm answered with its own version number and missing updates — readable in seconds.
• The public mailing-list host ran a release discontinued in 2010, on a web stack from 2008 that announced itself on every response. Sixteen version-applicable CVEs, eight reachable without a login, not a single CSRF token anywhere in the web forms, and a list-creation CGI open to the world.

Nobody had hidden anything. The list host had simply fallen out of the update story — a service that "just works" is the easiest one to forget. And this forgotten host was the one with live-reproducible weaknesses: a crafted list name and an injected email string both reflected on the trusted origin. One crafted link to a logged-in list administrator meant list takeover — and from there, mass mail under the university's real brand.

The estate maps itself for free

Certificate transparency logs are a gift to defenders and attackers alike. Every certificate ever issued is public — including 103 internal hostnames currently valid in certificates that renew every 60–90 days: the CI/CD system, identity servers, NAC appliances, the internal wiki, asset management, student-system farms. Nobody needs to scan this estate; it publishes a fresh map of itself on a schedule. On top of that, one hostname resolved publicly to a private RFC1918 address, and the public SAML metadata leaked internal CA and endpoint references.

The lesson is not "stop using certificates". It is: your internal names are public — design like it, and check your own certificate footprint during every audit before someone else does.

No detection is a finding

Across two full waves and thousands of requests, one thing never happened: a rate-limit, a challenge, a tarpit, an IP block. Zero events. The entire external core — DNS, web, identity, VPN, load balancers — shares one /24, with no institution-specific routing prefix.

"Detection will catch it" is a common sentence in risk discussions. On this estate it was demonstrably an assumption, not a control — because nothing at the edge interrupted two complete, methodical assessment waves. For a patient attacker, that same absence means credential stuffing, list manipulation and reconnaissance can run unthrottled for weeks.

Findings

The attack path

Reproducing it in the lab

The interesting part of this engagement is that no exploitation was needed — the exposure was architectural. Everything was shown read-only, and the only live proofs were non-destructive:

• Anonymous mailbox surface — replicate an identity gateway with a prefix exemption in a lab, then confirm from outside that the exempted paths answer anonymous challenges while the gateway paths do not. The map of exemptions is the attack surface.
• List host takeover — a container with the discontinued list software, a logged-in administrator session, and a page that submits one admin form cross-site. No payload needed: the absence of a CSRF token is the vulnerability.
• Appliance range checks — for the document appliance, the build stamp in the static path was enough to place it inside the advisory range; the lab verified which advisory paths require no authentication at all.
• Monitoring metrics — a one-line curl against /metrics reproduced the entire leak; the lab measurement was "what fraction of the estate's usernames appear in that file".

Detecting it in your own estate

• Inventory your identity exemptions. Which paths does your SSO gateway not protect? Test each prefix from outside. If a whole URL family is exempted "for clients", that family is your perimeter.
• Watch your certificate footprint. Filter certificate transparency for currently-valid certificates containing internal-sounding names. If a comfortable list falls out, attackers have it too.
• Treat "just works" services as risks. The oldest, quietest host — the list server, the calendar bridge, the appliance nobody logged into since onboarding — carried the live-reproducible weaknesses.
• Verify DMARC the way receivers do. p=none is not a policy, it is a wish. If spoofed brand mail is deliverable and no report ever arrives, your mail authentication is decoration.
• Prove your detection, don't assume it. If you cannot show a single rate-limit or alert event from an authorised test, you have no evidence any unauthorised one would be seen either.

Remediation

• Mail: bring the farm to the current security update and bound the anonymous surface — the exemption should be a short, auditable list of required endpoints, ideally reaching mail clients without Basic/NTLM over the open internet at all.
• List host: this is a retirement project, not a patch project. Current list software, CSRF protection by default, and the locked-down web interface — or migrate the service.
• Mail authentication: DMARC to p=reject with reporting, DKIM on both domains, alignment checked.
• Appliances: document portal and monitoring stack need current builds; /metrics belongs on an internal listener. A gateway offering only Basic authentication should be retired or fronted by the identity provider.
• Certificates: expiry monitoring that pages a human, and a naming policy for certificates that assumes every name will be read by strangers.
• Detection baseline: the first alert should come from your authorised test. If it does not, that is the finding to fix next.

Takeaways

1. The front door is not the perimeter — the exemptions are. Enumerate them, test them from outside, and shrink the wildcards.
2. Two products told the whole story through their own headers. Patch lag is not hidden; it is unread.
3. The quietest host carried the live vulnerabilities. "Just works" is a maintenance smell.
4. Your estate publishes a map of itself. Certificates and DNS are your inventory — check what they say about you.
5. Zero detection events in two full waves is a finding, not a comfort: it means every other lesson here has no safety net.