Wiz CTF #4: Needle in a Haystack

Wiz CTF stamp 4

No flags are included in this writeup.

Overview

Needle in a Haystack was a reconnaissance-heavy challenge around a developer side project. The story was simple: someone had built an internal knowledge-base chatbot too quickly and stored sensitive data inside it. The work was finding the real app, then proving that the access controls were not real controls.

Field Value
Month September 2025
Points 20
Main area OSINT, GitHub, DNS, client-side validation, API abuse

The Recon Direction

The clues pointed toward public version-control discovery and two-level-deep infrastructure. I treated the public company domain as the starting point, but the actual signal came from looking for developer artifacts around the company.

The public trail led to a repository connected to the target. The important artifact was not only the current files, but also repository history and DNS configuration. Public repos often leak infrastructure naming patterns even when no secret key is sitting directly in the latest commit.

Finding The Application

The useful chain was:

  1. identify a developer/project connected to the company
  2. inspect repository files and commit history
  3. extract naming clues for internal or pre-production infrastructure
  4. test two-level subdomain patterns
  5. find the chatbot application

This is where the challenge name fit. The hidden app was not guarded by a complex exploit. It was buried under normal-looking internet noise.

Client-Side Security Failure

Once I reached the chatbot login, the source code mattered. The app exposed a third-party application identifier and implemented the employee-only restriction in client-side JavaScript.

That is not security. If the browser is enforcing the rule, the API needs to enforce the same rule server-side. Otherwise, the browser becomes optional.

The API exposed enough documentation and endpoints to register or authenticate directly. By talking to the API instead of the UI, the email-domain restriction could be bypassed.

Chatbot Data Exposure

After authentication, the chatbot itself became the sensitive surface. The issue was not only unauthorized login. The knowledge base had access to sensitive internal records, and the chatbot returned information it should have filtered.

The final lesson was a layered one:

  • public repo exposure revealed infrastructure
  • client code revealed app configuration
  • server-side auth rules were weaker than frontend rules
  • chatbot data access was not constrained tightly enough

Takeaways

Needle in a Haystack is the kind of challenge that maps directly to real bug bounty methodology:

  • inspect public repositories and commit history
  • treat CNAME files and DNS naming as sensitive clues
  • never trust client-side-only validation
  • check whether APIs enforce the same restrictions as the UI
  • assume internal chatbots and knowledge bases can amplify small auth mistakes into major leaks

The challenge rewarded patience more than tooling. The hardest part was staying systematic until the “needle” stopped looking like noise.