Case study
The suspected breach that was not a breach, and the real exposure underneath
An organisation believed an outsider had reached a private form. The evidence did not support that. Establishing it surfaced a materially worse exposure that nobody had reported, sitting in plain sight the whole time.
Based on a real engagement. Client anonymised and details changed.
At a glance
- Engagement
- Incident response: investigating a suspected breach
- Timeframe
- Not part of this account
- Scope
- The suspicious submission, the form that received it, and the account that collected the responses
- Outcome
- The reported intrusion closed as unfounded; a worse, unreported exposure escalated for remediation and notification
The situation
A team noticed a submission to an internal form that looked wrong: implausible content, arriving from nowhere they could account for. The working assumption was that a link had leaked or an account had been compromised, and the engagement was commissioned to find out who had got in.
What we did
- Started from the artefact itself (its submission metadata, referrer and timing) before reasoning about who could have produced it
- Established what the platform records natively, so conclusions rested on evidence rather than on the platform's marketing claims
- Worked read-only throughout: nothing created, modified or deleted, so the evidence stayed intact for anyone who looked later
- Tested the commissioning premise as a hypothesis that could fail, rather than as the thing to confirm
What we found
The suspicious submission came from inside the account
Metadata placed its origin in the platform's own authenticated administration interface, which a member of the public completing a published form cannot produce. The most likely explanation was ordinary testing by the team itself. No intrusion was required to explain it.
The form was never access controlled in the first place
The premise assumed a private form someone had reached improperly. It was published on a public, search-indexed page with no authentication of any kind. There was no boundary to breach, which is a worse finding than the one that was suspected, not a reassuring one.
It was collecting credentials in plain text
The form asked people to type an account password into a free-text field, stored unencrypted and readable by anyone with access to the collecting account. Because password reuse is common, those credentials had to be treated as valid well beyond the service they were given for.
What changed
The reported incident was closed as unfounded, with the reasoning documented so the same conclusion could be re-derived. The genuine exposure was escalated for immediate remediation and for notification of the affected people, under legal direction rather than technical judgement alone.
The lesson
Investigations commissioned to confirm a theory are the ones most likely to miss what is actually wrong. Two habits matter: let the premise fail, and when it does, keep looking. The reason someone noticed something is often adjacent to a real problem, even when their explanation is mistaken. Being told "no attacker" is not the same as being told "no exposure."
What to check in your own environment
- Find every form that asks for a password, token or other secret, including forms built outside your codebase
- Check whether each form you think of as private sits behind authentication, or only behind a link nobody was meant to share
- Search for your own forms in a search engine to see which ones are indexed
- Compare each form's views and starts with the number of people it was meant for
- Before investigating a suspected breach, write down what evidence would show it did not happen
- Work read-only, and export the current state before anyone changes anything
Recognise your own systems in this?
A short conversation is the quickest way to find out whether the same thing is true of yours, and what it would take to check.