Skip to content

Hunt Queries and Analysis

This page covers advanced threat hunting techniques in Fencer: building precise multi-filter queries, understanding the normalized event schema, interpreting event details, using AI-powered analysis, and applying practical hunting playbooks to common investigation scenarios.

For an introduction to Threat Hunting, see Threat Hunting.

Click Filter on the Threat Hunting page to add any of these filters:

FilterOperatorsWhat it matches
Data Source Typeis, is notThe type of log source, such as AWS CloudTrail. Only types you have connected appear.
Data Sourceis, is notOne of your AWS or GCP monitor data sources, by its display name.
Event IDisOne event, by its ID.
Messageis, contains, does not containThe event’s normalized description.
Event Datacontains, does not containThe full event payload. See Searching event data.
Triggered Detectionis Yes or NoWhether the event triggered a detection.

A Grouping Key filter is added when you open a detection’s events with Investigate events. It scopes the list to the events of that detection.

Add as many filters as needed. An event must match every filter to appear. In Data Source Type or Data Source, pick several values to match any of them. For example, to find unauthorized GitHub API calls from a specific IP range, add Data Source Type is GitHub Events, Event Data contains the CIDR range, and Message contains unauthorized. All three must match for an event to appear.

The Event Data filter searches the whole raw event payload, so you do not need to know the exact field name:

  • IP addresses and CIDR ranges — enter a single IPv4 address (for example 203.0.113.42) or a CIDR range (for example 203.0.113.0/24). Fencer matches IP addresses anywhere in the event that fall in the range.
  • Text — enter words or values, such as an email address or an API action. Fencer matches events that contain them. Text with a colon in it is read as a field and a value: the part before the first colon is the field name.
  • One field — in the event detail panel, hover over a field in Event Data and click Include or Exclude. Fencer adds an Event Data filter that matches that field’s value, written as "field":"value". You can type the same form yourself, using a dot path for a nested field, such as "userIdentity.arn":"arn:aws:iam::123456789012:user/alice".

Using “is not” and “does not contain” to exclude noise

Section titled “Using “is not” and “does not contain” to exclude noise”

The Data Source Type and Data Source filters support is not, and Message and Event Data support does not contain. Use them to exclude known-noisy sources, internal automation accounts, or known scanner IPs while keeping everything else visible.

The Filter menu also offers Noise reduction suggestions: the descriptions and sources that occur most often in the current results, with their counts. Pick one to exclude it.

The Triggered Detection filter lets you scope results to events that have (or have not) triggered a detection rule:

  • Yes — show only events that fired a detection. Useful for reviewing the context around an active alert.
  • No — show only events that did not trigger any rule. Useful for hunting for threats that your current rule set does not cover.

If your organization has a batch AWS VPC Flow Logs data source, the first time you open Threat Hunting a filter excludes AWS VPC Flow Logs. VPC Flow Logs are very high volume and typically not useful for most investigations. To include them, remove that filter from the filter bar.

Threat Hunting queries Fencer’s OCSF (Open Cybersecurity Schema Framework) view, which normalizes events from all connected log sources into a common format.

OCSF is an open standard for security event data. By normalizing events from different providers into a common schema, Fencer lets you write filters that work across all your data sources without needing to know provider-specific field names.

The View option in the filter bar switches between two layouts:

  • Structured — Source / Timestamp, then the Actor, Action, and Target of the event.
  • Description — Source / Timestamp and the normalized Description.

Timestamps are in UTC unless you switch the time range picker to your own timezone.

The full provider-specific event payload is available in the event detail panel as JSON. Fields vary by provider, but the normalized description and timestamp are always present. Every log source you connect appears as a Data Source Type, such as AWS CloudTrail, GitHub Events, 1Password Audit Events, or GCP Cloud Audit Logs. See Supported log sources.

Click any event to open Event Details. It shows:

  • The event’s source and timestamp.
  • Quick Filters — Include this source type and Exclude this source type add a Data Source Type filter for the event’s source.
  • Description — the normalized description.
  • AI Analysis — see below.
  • Event Data — the complete event payload as JSON. Hover over a field to add an Include or Exclude filter for its value, or click Copy to copy the whole payload to your clipboard.

In the event detail panel, click Ask AI in the AI Analysis section to request an AI-generated breakdown of the selected event.

The analysis returns four sections:

  • What Happened — a plain-language summary of the event: what action occurred, who or what performed it, and what resource was affected.
  • Technical Details — key technical observations drawn from the payload, such as source IP, user agent, API endpoint, response codes, and relevant metadata.
  • Why This Matters — the security significance of the event in context, including potential risk and relevance to common attack patterns.
  • Investigation Paths — concrete suggested next steps, such as additional filters to run, related events to look for, or external lookups to perform.

When the event triggered a detection, the analysis takes that detection into account. Asking again about the same event shows the saved analysis.

  • Events per page: the list loads 1,000 events at a time, newest first. Scroll down to load older events.
  • Maximum time range: 90 days. A longer custom range is cut to the 90 days before its end time.
  • Query time: a hunt that runs too long stops with “This hunt took too long to run.” Narrow the time range or add a filter.
  • AI analysis: each organization has a daily limit on AI analyses.

If you suspect a user account has been compromised:

  1. Set the time range to 7 days.
  2. Add Data Source Type is 1Password Sign-in Attempt Events.
  3. Add Event Data contains the user’s email address.
  4. Review sign-in events for unusual source IPs, new countries, or unusual times.
  5. Cross-reference by switching Data Source Type to AWS CloudTrail and adding Event Data contains each IP address found in step 4.

To look for unexpected AWS API calls that may indicate unauthorized access:

  1. Set the time range to 24 hours.
  2. Add Data Source Type is AWS CloudTrail.
  3. Add Message contains the API action you are investigating (for example CreateUser or PutBucketPolicy).
  4. Review the results for unexpected principals (user ARNs or roles), unusual source IPs, or actions occurring outside business hours.
  5. Add Triggered Detection is No to look for suspicious calls that did not fire any existing rule.
  1. Set the time range to cover the suspected incident window.
  2. Add Data Source Type is AWS CloudTrail.
  3. Add Message contains AssumeRole.
  4. Review events for role assumption chains from unexpected source accounts or principals.
  5. Add an Event Data filter with each source IP to cross-check it against threat intelligence.

The timeline at the top of the Threat Hunting page shows event count over your selected time range divided into equal time buckets. Use it to identify anomalous activity spikes that warrant investigation and to check that your filters are not too broad or too narrow. Drag across a spike to list only its events, then zoom in to make it the time range.

Your on-call engineer reports a suspicious alert. You open Threat Hunting, set a custom time range covering the last 2 hours, add Data Source Type is AWS CloudTrail, add Event Data contains 198.51.100.0/24 (a suspicious IP range from threat intel), and add Triggered Detection is No to surface events not caught by existing rules. Among the results are two GetSecretValue calls against Secrets Manager from an unexpected IAM role. You click each event, review the event data, and click Ask AI for suggested investigation paths.

You find a GCP Cloud Audit Logs event showing an unusual storage.objects.list call against a sensitive bucket. You click the event to open the detail panel and click Ask AI. The analysis might describe a service account listing a sensitive bucket from an IP address not seen before, a pattern consistent with reconnaissance before exfiltration, and suggest filtering for later storage.objects.get calls from the same service account under Investigation Paths.

  • Query returns 0 results despite events being expected — Check your filters for over-restriction, including the default AWS VPC Flow Logs exclusion. Try removing all filters and re-adding them one at a time to identify which filter is excluding the events you expect.
  • “Daily AI analysis limit reached” — Your organization has used its AI analyses for the day. Try again tomorrow.
  • “AI analysis is temporarily unavailable” — Click Retry.
  • Query is slow to return results — Broad time ranges with high event volumes take longer to process. While a query runs for more than a few seconds, the event list shows a loading message, and after about 15 seconds it reads Still hunting. Lots of ground to cover. Narrow the time range or add a Data Source Type filter to reduce the query scope.
  • The search box finds nothing that should match — Search events… only searches the events already loaded. Scroll to load more, or use a Message or Event Data filter, which searches the whole time range.