CASE STUDY · THREAT INTELLIGENCE PLATFORMS
Standing up proactive threat hunting for a client with no security team.
- 1414 actionable security findings in the first review
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
Threat-hunting queries and response playbooks. The queries search existing logs and systems for signs of known attacker behaviour. The playbooks tell a small team exactly what to do when a query finds something.
- 1The company had a purely reactive security posture.
- 2It had basic tools and relied on alerts and the occasional external advisory.
- 3There was no dedicated security team, so nobody looked for problems that had not yet raised an alarm.
- 4Leadership wanted to know whether something was already wrong, and what the likely attack routes were for a firm of its size and sector.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Log coverage was patchy
Some systems kept logs for only a few days, and a few key sources were not collected at all, so some hunts could not be answered. We did not hide this. We reported it as a finding in its own right, prioritised the gaps by risk, and had the client turn on retention and collection for the most important sources first.
- PROBLEM 02Later hunts then had data to work with
- PROBLEM 03A second problem was alert fatigue in reverse
Some hunts returned long lists of events that were normal for the business, such as an administrator working at night. If we reported them all, the IT lead would stop reading. We added notes to each query on known normal behaviour, ran each hunt against two weeks of data first to judge volume, and only raised findings that needed a decision.
- PROBLEM 04This kept the review short and credible
03 · THE PROCESS
How we ran it.
This was a compact engagement. We began with a short discovery phase to learn the environment: what was logged, where, for how long, and who owned each system. Then we agreed a list of hunt hypotheses, drawn from techniques commonly used against organisations like theirs. We ran hunts in weekly cycles, reviewing results with the IT lead each Thursday, and wrote playbooks as findings emerged. A final session handed over the queries, the playbooks and a hunting calendar.
- 01Step 1
This was a compact engagement.
- 02Step 2
We began with a short discovery phase to learn the environment: what was logged, where, for how long, and who owned each system.
- 03Step 3
Then we agreed a list of hunt hypotheses, drawn from techniques commonly used against organisations like theirs.
- 04Step 4
We ran hunts in weekly cycles, reviewing results with the IT lead each Thursday, and wrote playbooks as findings emerged.
- 05Step 5
A final session handed over the queries, the playbooks and a hunting calendar.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Hunts run on a schedule, with a named owner.
- NOW 02
Logging and retention are treated as security requirements.
- NOW 03
Playbooks exist for common findings, so response does not depend on one person's memory.
- NOW 04
Leadership receives a short findings report each cycle.
- 14
14 actionable security findings in the first review
05 · WHAT WE BUILT
How it works.
- Data sources: identity provider logs, endpoint telemetry, email gateway logs, cloud audit logs and network device logs, where available.
- Hypotheses: each hunt starts with a written question, such as "are there sign-ins from unusual places for privileged accounts?", mapped to attacker techniques.
- Queries: saved, versioned, with notes on expected false positives.
- Playbooks: step-by-step response for each finding type: confirm, contain, investigate, recover, record.
- Controls: read-only access for hunting accounts, findings logged in a tracker with an owner and status, and sensitive data handled under agreed access rules.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The company had a purely reactive security posture. It had basic tools and relied on alerts and the occasional external advisory. There was no dedicated security team, so nobody looked for problems that had not yet raised an alarm. Leadership wanted to know whether something was already wrong, and what the likely attack routes were for a firm of its size and sector.
- What did Brandsmashers build?
- Threat-hunting queries and response playbooks. The queries search existing logs and systems for signs of known attacker behaviour. The playbooks tell a small team exactly what to do when a query finds something.
- How was the work run?
- This was a compact engagement. We began with a short discovery phase to learn the environment: what was logged, where, for how long, and who owned each system. Then we agreed a list of hunt hypotheses, drawn from techniques commonly used against organisations like theirs. We ran hunts in weekly cycles, reviewing results with the IT lead each Thursday, and wrote playbooks as findings emerged. A final session handed over the queries, the playbooks and a hunting calendar.
- What were the results?
- 14 actionable security findings in the first review.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
