Threat hunting in your own app

February 13, 2026 · 6 min read

Security monitoring generates alerts. Threat hunting starts where alerts stop: someone looks at the data proactively, searching for patterns that automated rules haven't been configured to catch, investigating connections between accounts that no single rule would surface, and reconstructing what actually happened during an incident.

For products with user accounts, the data required for threat hunting is behavioral: who logged in, from where, on what device, what they did during the session, what they changed, and how that compares to their normal pattern. The same data that powers automated risk scoring also powers manual investigation, but investigation requires a different interface. It needs the ability to drill into a single user and see their full history, to search across accounts for shared signals, and to trace the sequence of events that led to a specific outcome.

Most threat hunting tooling is designed for infrastructure security teams working with SIEM platforms across network logs, endpoint telemetry, and cloud audit trails. For teams whose primary security surface is their own application, the hunting ground is narrower and more focused: the events generated by users interacting with the product itself.

What threat hunting looks like at the application level

Threat hunting in application security typically starts with a question rather than an alert. Something looks unusual in aggregate data: a spike in registration volume, an uptick in failed logins from a specific region, a cluster of accounts that changed their email addresses within the same short window. The question is whether the pattern represents a coordinated attack, an organic change in user behavior, or noise.

Answering that question requires the ability to pivot from the aggregate observation to specific accounts and sessions. A spike in registrations becomes meaningful when you can see that the registrations share device identities, originate from a narrow IP range, and use email addresses from the same recently registered domain. A cluster of email changes becomes concerning when the accounts involved had recent logins from unfamiliar devices and locations.

Incident response follows a similar pattern but works backward from known damage. An account was compromised. What happened before the takeover? Which IP addresses accessed it? Were there failed login attempts first? Did the attacker change the email address? Did they access data or initiate activity inconsistent with the account's history? Are there other accounts accessed from the same infrastructure during the same window?

tirreno as an investigation tool

tirreno's data model is built around the user. Every event (login, page view, account change, failed authentication, field modification) is tied to a user identity and stored with its full context: IP address, device identity, browser information, timestamp, URL, and event type. The result is a per-user timeline that shows the complete history of each account.

The single user view is the primary investigation surface. Selecting a user shows their activity history: every session, every device they have used, every IP address they have connected from, every event type associated with their account. Devices, IPs, and locations are visible as distinct entities with their own metadata: when first seen, when last active, and what other accounts have used them. These entity-level connections are the paths that lead from one compromised account to the scope of a broader incident.

The activity page provides the operational view across all user events. Every event is shown with the user's trust score, timestamp, event type, IP address, IP type, and device. The page is filterable by event type, triggered rule, or device type. For credential stuffing campaigns, it shows the volume and distribution of failed login attempts across IPs and devices. For scraping incidents, it shows the request patterns and source infrastructure. The Logbook page complements this by showing raw API requests for debugging whether events from your application are arriving correctly.

IP and device drill-downs let investigators pivot from a user to the infrastructure they used and from there to other accounts sharing the same infrastructure. An IP address view shows all users who have connected from it, the geographic and network metadata from the enrichment API (datacenter, VPN, TOR, residential), and whether it appears in abuse lists. A device view shows all accounts associated with that device identity and when each was active.

The risk score breakdown shows which rules fired for a specific user and what weight each contributed. During an investigation, this tells you why an account was flagged and which combination of signals produced the score. When evaluating whether an alert was a true positive or a false positive, the contributing rules are the evidence.

Forensic analysis after an incident

When the priority shifts from detection to reconstruction, the event record becomes forensic evidence. Every event is recorded with its full context and cannot be altered after the fact.

For account takeover incidents, the timeline shows when the attacker gained access (the first login from the unfamiliar device), what they did during the compromised session (email change, data access, activity inconsistent with the account's history), and how long the compromise lasted before detection. If the application instruments field changes through the API, the audit trail shows which data was modified, the old and new values, and the session context of each modification.

For coordinated attacks (credential stuffing campaigns, bulk registration fraud, or multi-accounting operations) the entity connections across accounts reveal the scope. Starting from one identified fraudulent account, the shared device identities and IP addresses lead to the full set of related accounts. The investigation scales from a single account to the entire operation through data already in the system.

For compliance-driven investigations, where a regulator or auditor asks for evidence of what a specific user did and when, the per-user timeline and field audit trail produce the answer directly. The evidence is in your database, queryable and exportable under your own governance policies.

A practical integration plan

Threat hunting is only as good as the data available to hunt through. The goal is to reach a state where every meaningful user action is captured with enough context to support investigation.

1. Identify your investigation scenarios. What incidents has your team dealt with in the past, or expects to deal with? Account takeovers, credential stuffing, data exfiltration, insider misuse, fraudulent registrations. Each scenario determines which events and which context fields your investigation will need. If you have never had to investigate an incident, consider what questions you would need to answer if one happened tomorrow.

2. Instrument authentication events first. Logins, failed logins, password changes, email changes, and session starts are the foundation of any investigation. These events establish who accessed what, when, and from where. They are also the lowest-effort integration point because most applications already have authentication hooks where event emission can be added.

3. Add application-specific actions that carry consequence. Payments, record modifications, data exports, permission changes, configuration updates. These are the events where damage happens. Instrument them with the field audit trail so that investigations can reconstruct what changed, including the old and new values.

4. Ensure device and IP context flows with every event. Investigation depends on being able to pivot from a user to their infrastructure and from infrastructure back to other users. Every event sent to tirreno should include the device identity and IP address. Without these, cross-account correlation is not possible, and cross-account correlation is the core of any coordinated-attack investigation.

5. Run a tabletop investigation against your own data. Once events are flowing, pick a real account and try to answer investigation questions from the tirreno interface. Can you see their full session history? Can you identify every device and IP they have used? Can you find other accounts that share the same device? If any of these answers require data you are not yet capturing, that tells you what to instrument next.

Why investigation data should stay in your infrastructure

The data that powers threat hunting and forensic analysis is the most detailed record of user activity your product generates. It contains login histories, session patterns, device inventories, IP geolocation records, and modification trails tied to individual identities.

Your team needs unrestricted access to this data during an incident, without delays for vendor data requests or dependency on a third party's availability. Self-hosted monitoring means the data is in your database, under your access controls, available at 2 AM when the incident happens and available months later when the auditor asks questions.

Open source means the data model is transparent. The investigation works from data you understand completely because the system that generated it is open to inspection.

Live demo at play.tirreno.com. Download at tirreno.com/download. The administration guide covers security configuration and log management.