Threat Detection
Offensive mindset. Defensive results.
Setting up the logging and alerting that catches real attacks, tuned to cut false positives so your team can focus on what matters.
What we monitor
Authentication Events
Failed logins, brute force attempts, credential stuffing, impossible travel detections, and MFA bypass attempts.
Network Traffic
Anomalous flows, lateral movement, data exfiltration patterns, DNS tunnelling, and command-and-control communication.
Endpoint Activity
Suspicious process execution, privilege escalation, persistence mechanisms, and malware indicators on endpoints.
Cloud Audit Trails
IAM policy changes, resource modifications, unusual API calls, and storage access patterns across cloud providers.
Application Logs
SQL injection attempts, XSS probes, access control violations, and business logic abuse at the application layer.
Email & Phishing
Suspicious email patterns, phishing campaign detection, domain spoofing alerts, and mailbox compromise indicators.
Detection engineering
Detection engineering is an iterative loop, not a one-off install. These five phases take you from “we collect logs” to “we get few, high-quality alerts and know what to do with each one.”
-
01
Log Source Assessment
We audit what you actually collect against what you would need to answer the questions that come up during an intrusion: who authenticated, from where, what did they run, what left the network. Most environments turn out to be missing one or two sources that every investigation needs — process creation, DNS, or cloud audit logs are the usual absentees.
We also look at retention and cost. Ninety days of the right sources beats a week of everything, and a good deal of log spend is on volume nobody ever queries. Trimming that is often what funds the sources you are missing.
-
02
Detection Rule Design
Rules are written against the MITRE ATT&CK techniques that are actually plausible for your stack and threat model — there is no value in cloud-credential-theft detections for an environment with no cloud, or in Windows rules for a Linux fleet. We start with the techniques that appear in real intrusions against organisations like yours.
Good rules use correlation and multiple signals rather than single indicators, because one-signal rules are the ones that either miss the real thing or fire constantly. Each rule is written with its intent, its expected false-positive sources, and its ATT&CK mapping recorded alongside it, so the next engineer knows why it exists.
-
03
Tuning & Baselining
A new ruleset is always too noisy at first. We baseline what normal looks like in your environment — the backup job that reads everything at 2am, the vulnerability scanner that looks exactly like an attacker, the admin who genuinely does work at odd hours — and tune thresholds and exclusions against that.
Exclusions are written as narrowly as possible and documented, because a broad “ignore this host” exclusion is how blind spots get created by people trying to reduce noise. The target is an alert volume your team can actually triage, where a firing alert is worth looking at.
-
04
Alert Routing & Playbooks
A correct alert that reaches nobody is not a detection. We set severity tiers and route each accordingly — which alerts page someone at 3am, which wait for the morning, which are only ever reviewed in aggregate — and define the escalation path when the first responder needs help.
Each alert gets a playbook: what it means, what to check first, the queries to run, how to tell a true positive from the usual false one, and what action to take including who can authorise it. This is what lets a junior analyst handle an alert correctly at 3am, and what stops the same investigation being reinvented every time.
-
05
Validation & Handover
Finally we prove the detections fire. We run the techniques they are meant to catch — safe, atomic tests executed in a controlled way — and confirm each produces the expected alert, with the expected context, routed to the expected place. Rules that do not fire get fixed; this step regularly finds rules that were subtly wrong for months.
We then hand over the ruleset, the coverage matrix and the playbooks, and show your team how to extend them. The aim is that you can add your own detections afterwards, not that you need us for the next one.
Common questions
What is threat detection?
Threat detection is the continuous monitoring of systems, networks, and applications to identify malicious activity, unauthorized access, and anomalous behaviour. It combines log analysis, alerting rules, and correlation to catch attacks early.
What logs should my organisation collect?
At minimum: authentication events, authorization failures, application errors, network flow data, DNS queries, firewall logs, and cloud API audit trails. The specific sources depend on your environment and threat model.
How do you reduce false positives?
We tune detection rules based on your environment's baseline behaviour, use multi-signal correlation, implement severity-based escalation thresholds, and continuously refine rules based on investigation outcomes.
Stop threats before they escalate.
Let us set up detection that actually catches attacks, not just generates noise.