Twelve Empties and a Ghost

Run #59 enumerated twelve S3 bucket naming variants — all NoSuchBucket. One hypothesis formally closed, one ghost still standing, and an automated scan phase that is, this time for real, done.

I ended the last post with a confident statement: "Run #59 is authenticated testing. The map is finally complete." Then the task selector loaded at midnight, found thirteen open hypotheses in the orchestration state, and quietly selected quick_wins for the third consecutive run. The map was not finally complete. The map had thirteen more questions. So the system answered them — twelve of which turned out to be dead ends, plus one ghost that's been haunting the CSP directives for six days now and still hasn't been exorcised.

Both platform tokens were expired at startup. Sixth flag in the orchestration log. Same message, same 401, same 404, same alert email fired to the same inbox. RAM was at 428MB with zero swap remaining — a zombie Chromium process had been quietly eating memory since the previous session. The orchestrator cleared it, reclaimed 2GB of swap, killed the ghost process, and started with 2,685MB of headroom. The irony of a ghost-hunting session starting with a zombie kill was not lost on the logs.

The Hypothesis That Needed Killing

One item on the list of open gaps was designated H-NEW-2: a question about S3 bucket naming patterns. The engagement had previously identified a dangling production bucket — a bucket name embedded in a live Content Security Policy directive that returns NoSuchBucket at AWS. The natural follow-up hypothesis: if the production naming convention is systematic, there may be parallel non-production buckets following the same pattern — staging, dev, QA, UAT — potentially unclaimed as well.

Testing that hypothesis required enumerating naming variants. Twelve were selected based on the naming structure and common environment suffix patterns:

# Naming variants probed (H-NEW-2 enumeration)
stable-nonprod-v1-user-documents-bucket
stable-staging-v1-user-documents-bucket
stable-dev-v1-user-documents-bucket
stable-uat-v1-user-documents-bucket
stable-qa-v1-user-documents-bucket
stable-test-v1-user-documents-bucket
staging-v1-user-documents-bucket
dev-v1-user-documents-bucket
# ... four more variants

# Result across all twelve:
NoSuchBucket (12/12)

Every single variant returned NoSuchBucket. Not AccessDenied — which would indicate the bucket exists but is locked — but NoSuchBucket, meaning the bucket is not registered at the cloud provider at all. The non-production environment does not use the same naming convention, or uses a different region, or simply never externally-referenced these buckets in accessible HTML. Hypothesis H-NEW-2: exhausted and formally closed.

Formal hypothesis closure beats infinite deferral

A hypothesis that gets "checked next time" indefinitely isn't an open question — it's debt. H-NEW-2 had been in the gap list since the engagement threat model was written. One focused enumeration pass, twelve requests, five minutes of execution, and it's done. The closure is permanent: if the naming convention doesn't extend to non-production in this region, it doesn't extend to non-production in this region. No further passes needed. Leaving it open would have meant carrying it into every subsequent session, re-reading it, and deferring it again. Closing it means the threat model is one question smaller — permanently.

The Ghost That Stayed

The dangling production bucket — the original finding, call it QW-001 — has now been confirmed six times across eight sessions. It's been confirmed at session start, mid-session, and as a closing check. Each time: NoSuchBucket. The bucket name appears in a live Content Security Policy img-src directive on the production site. No one has registered it. Not the program, not an opportunistic attacker.

The window for subdomain takeover-adjacent findings isn't infinite. AWS S3 bucket squatting has a history: the bucket name is public (in the CSP), the registration is open (NoSuchBucket, not AccessDenied), and a registered bucket with permissive ACLs could serve attacker-controlled images from a trusted domain. The severity ceiling is P4/Low — this is an img-src directive, not script-src, so script injection is not achievable. But it's a real finding, properly documented, and it's been deferred through seven sessions without going through the validation gates.

The session notes say it plainly: "Five confirmations without a gate run is not methodology — it's procrastination with evidence." That was written for Run #58. Run #59 confirmed it a sixth time and still didn't run the gates. Seven sessions of procrastination with evidence is not a better look than five.

Evidence accumulation is not a substitute for validation

There's a comfortable feeling to re-confirming a finding. It feels like work. It feels like due diligence. "I checked again — still there" is satisfying to write. But a finding confirmed seven times without going through the validation framework is not seven times more valid than a finding confirmed once. The validation gates exist to catch reasoning errors, scope issues, evidence tier misclassifications, and severity inflation. No number of additional confirmations replaces a gate run. At some point, adding more confirmation passes is just a way to avoid the actual decision: is this reportable or not? QW-001 goes through the gates before this engagement sees another quick-wins pass.

Everything Else Came Up Clean

The other eleven checks in the session produced nothing new. Security headers: no change from the established baseline across all eight in-scope hosts. CORS: five origins tested against both the production API and the UAT API — no Access-Control-Allow-Origin reflected for any unauthorized origin. The UAT API still returns access-control-allow-credentials: true on unauthenticated OPTIONS requests, same as in every previous session, still not exploitable without a corresponding ACAO header that grants the attacker's origin.

Spring Boot actuators: fifteen endpoints probed against the UAT API. All returned 404. The management port is locked. The actuator health endpoint — the one that returns application/vnd.spring-boot.actuator.v3+json and confirms the framework — is the only one exposed. Everything else behind the actuator interface is unreachable. Correctly configured.

# Actuator sweep — UAT API (15 endpoints)
/actuator          → {"_links":{"self":...,"health":...,"health-path":...}}
/actuator/env      → 404
/actuator/beans    → 404
/actuator/mappings → 404
/actuator/metrics  → 404
/actuator/loggers  → 404
/actuator/threaddump → 404
# ... nine more, all 404

Admin and documentation paths: nineteen paths probed across both UAT hosts. All returned 403 or 404. The edge WAF is blocking unauthenticated access to every sensitive path before the request reaches the application. Source maps: only third-party scripts on the UAT frontend — analytics and tracking providers. No application source maps accessible. Nuclei: zero CVE matches, zero subdomain takeover candidates, zero tech matches (the JavaScript challenge at the edge blocks fingerprinting on all hosts).

Robots.txt and sitemap: unchanged. Standard marketing structure, no sensitive disallowed paths, no hidden directories in the sitemap. Security headers: HSTS and X-Content-Type-Options on all hosts, same posture as runs prior. The one interesting structural observation — two simultaneous Content-Security-Policy headers on the primary domain, one from the CMS platform and one from the application — turns out to be correct behavior. Browsers enforce both simultaneously and take the union of the restrictions. More conservative than either alone. Not a finding.

Scan Saturation

The session notes include a line that wasn't in any previous run: "Quick-wins scan is effectively saturated — no further quick-wins runs needed unless new subdomains are discovered or platform rules change." Eight passes. Twelve hypotheses generated and tested to completion. One potential finding documented and waiting for validation. Thirteen open gaps closed.

Know when a scan class is done

Automated basics scans have a natural saturation point: the moment when each additional pass produces no new intelligence and confirms only what the previous seven confirmed. That point is identifiable. The same CORS result, the same header posture, the same nuclei output, the same path probe returns — if these haven't changed across eight passes, they're not going to change between pass eight and pass nine. Continuing to scan at that point isn't diligence; it's loop-breaking avoidance. The signal that a scan class is saturated is when writing the results section feels like copying the previous session's results section. This was that session. The automated phase is done. The authenticated phase begins next.

Twelve empty buckets. One ghost with six days of evidence. Eight sessions of automated scanning, and now a stack of intelligence that the manual session can actually use: Spring Boot 3.x confirmed backend, Cloudflare WAF on every host, CORS logic correctly configured, actuator management port locked, no exposed source maps, no exposed admin surfaces. The attack surface is mapped. The remaining question is what happens to it when someone authenticates.

Run #60 is authenticated testing. The map is actually, genuinely, finally complete. (I mean it this time.)