Anomaly Events

Prerequisites

• You must have a valid Graylog Security license.

• You are running Graylog 7.1 or later.

• For Impossible Travel Anomalies, your Graylog pipeline or processing configuration applies GeoIP lookups to source IP addresses in your authentication logs, populating the source_geo_* fields, and login events include a consistent user identity field.

• For Log Volume Anomalies, the selected streams contain enough historical data to build a baseline.

How Anomaly Events Work

Each anomaly event definition uses one detection type. On each scheduled run, the detector:

1. Searches the selected streams, filtered by the search query and search filters, over the current time window.

2. Calculates a value for that window, such as the travel speed between a user's logins or the number of messages received.

3. Compares the value against the detection type's reference, such as the user's previous login or a baseline built from historical data.

4. Creates an event if the deviation exceeds the configured thresholds.

The event then follows the same workflow as any other event in Graylog. It appears on the Alerts & Events page, triggers any configured notifications, and can be investigated with a replay search.

Detection Types

Use the built-in detection types when a threat cannot be identified from a single log message or a fixed count, but can be identified by comparing current activity to a known reference.

Impossible Travel Anomalies

Impossible Travel Anomalies detects account compromise that standard rules miss. Each login event appears legitimate on its own; the risk becomes visible only when a login is compared to the same user's previous login. The detector compares each user's current login with their most recent prior login within the lookback period, calculates the distance and time between the two events, and creates an event when the implied travel speed is unrealistic.

Use this detection type to identify:

• Stolen or leaked credentials used from another region.

• Shared accounts used by people in different locations.

• Hijacked sessions or tokens replayed from an attacker's infrastructure.

• Logins from unexpected countries for users who normally work from one location.

Log Volume Anomalies

Log Volume Anomalies detects changes in the amount of data a source sends. Normal volume varies by source and time of day, so a fixed message-count threshold is either too sensitive or too permissive. The detector groups messages into time buckets, calculates a baseline from historical buckets, and compares the current bucket against it. It also detects sources that stop sending data, which a search-based rule cannot detect because there are no messages to match.

Use this detection type to identify:

• Volume drops caused by a failed forwarder or input, a network outage, or an attacker disabling logging to avoid detection.

• Volume spikes caused by brute-force attempts, scanning, data exfiltration, or a misconfigured application that floods logs and increases license usage.

These are the only detection types available for user-configured anomaly event definitions by default. The RCF detection type is used only by the predefined Illuminate anomaly event definitions and cannot be selected when you create an event definition.

Configuration Options

The Anomaly Events condition type includes the following configuration options:

Detection Type	Selects the built-in detector that supplies the detection logic: Impossible Travel Anomalies or Log Volume Anomalies. Your selection determines which detection type options appear.
Search Query (optional)	An optional Lucene query to filter which messages are evaluated. Use this to scope detection to specific log sources or event types, for example action:login. When empty, all messages in the selected streams are evaluated.
Search Filters (optional)	Search filters let you reuse query snippets to refine your search result.
Streams	The stream that contains your events, for example windows-security-logs or auth-logs, so the detector evaluates the correct log source.
Stream Categories (optional)	Select stream categories the search should include. This helps when filtering or organizing at scale.
Use Cron Scheduling	Enables custom scheduling using a cron expression. Use this option to run the event definition at a fixed time, date, or other interval. Graylog uses Quartz cron syntax. See Cron Scheduling for Event Definitions.
Execute search every	Sets how frequently the detection logic runs. For Log Volume Anomalies, this value also defines the bucket size used for aggregation. The default is 15 minutes.
Window Delay	Offsets the search window backward by the value specified to account for ingestion latency, ensuring late-arriving log messages are included in detection.
Enable (Checkbox)	Select this option to execute this event definition automatically.

Impossible Travel Anomalies Options

When you select Impossible Travel Anomalies, the following additional options appear:

User Field	The message field containing the user identity, for example user_name or source_user. The detector uses this field to associate login events with a specific user.
Distance Threshold	The minimum geographic distance between two consecutive logins required to trigger an alert. This also filters out noise caused by GeoIP inaccuracy. Select kilometers or miles as the unit. The default is 900 kilometers.
Time Threshold	Works in combination with the distance threshold to define the maximum plausible travel speed. Logins that exceed this speed over the distance threshold trigger an event. The default is 1 hour.
Lookback Period	How far back to search for a user's previous login when comparing locations. This determines the longest gap between logins that the detector can evaluate. The default is 24 hours.

Log Volume Anomalies Options

When you select Log Volume Anomalies, the following additional options appear:

Historical Time Period	How far back to look when calculating the historical baseline. Can be configured in hours or days. The default is 24 hours.
Baseline Statistic	The statistic used to summarize historical bucket counts into a single baseline value: Average, Median, 95th Percentile, or 99th Percentile. The default is 95th Percentile.
Alert Direction	High (volume spike): Alerts when the current count exceeds the baseline threshold. Low (volume drop): Alerts when the current count falls below the baseline threshold. The default is High (volume spike).
Threshold Percent	The percentage of the baseline that triggers an alert. The value must be greater than 0. For High (volume spike), the default value of 300 means "alert when volume is 3x the baseline." For Low (volume drop), a value of 50 means "alert when volume drops to half the baseline."
Minimum Data Ratio	The minimum fraction of expected historical buckets that must contain data before the detector alerts. This prevents false positives when data is sparse. The default value of 0.75 means at least 75% of historical buckets must be non-empty. Range: 0–1.

Hint: The Log Volume detector silently skips alerting and produces no event when fewer than 2 total buckets are returned, or when the data coverage ratio is below the configured Minimum Data Ratio.

Additional Details

The Additional Details step of the event definition wizard includes the following optional settings:

Tags	Labels attached to the event definition. Tags propagate onto every event the definition produces and make filtering and grouping easier on the Alerts & Events page. Tags are lowercased and deduplicated. Only lowercase letters, digits, hyphens, underscores, and dots are allowed.
Tactics/Techniques	MITRE ATT&CK® tactic (TA0000), technique (T0000), or sub-technique (T0000.000) IDs associated with the event definition. Select from the installed MITRE catalog or enter an ID manually.
Event Fields	Custom fields that add information to events generated by the event definition. Use event fields to make events easier to search or to provide more context in notifications.

Create an Anomaly Event Definition

1. Navigate to Alerts > Event Definitions and select Create Event Definition.

2. On the Event Details step, enter a title, priority, and description. You can also add an event procedure to guide your team on how to respond to alerts triggered by the event definition.

3. On the next step, select Anomaly Events as the Condition Type.

4. Select a Detection Type.

5. Configure the configuration options and the options for your detection type.

6. On the Additional Details step, optionally add tags, MITRE ATT&CK® IDs, and event fields.

7. On the Notifications step, add any notifications to send when an event is created.

8. On the Share step, optionally share the event definition with other users or teams.

9. On the Summary step, review your configuration and select Create event definition.

Example Use Cases

Detecting Impossible Travel

In this scenario, you want to alert your security team when a user account logs in from two locations that are too far apart to be legitimate, which can indicate stolen credentials or a compromised account.

1. Create a new event definition under Alerts > Event Definitions, then set the title, priority, and description.

2. Select Anomaly Events as the Condition Type.

3. Configure the following fields:

   • Detection Type: Impossible Travel Anomalies

     Compares each login to the same user's previous login.

   • Streams: auth-logs

     Evaluates authentication events only.

   • User Field: user_name

     Associates each login with a specific user.

   • Distance Threshold: 3,000 miles

     Ignores logins that are close together, such as nearby offices.

   • Time Threshold: 30 minutes

     Flags logins where covering the distance in the elapsed time is not realistic.

   • Execute search every: 5 minutes

     Evaluates new authentication activity every 5 minutes.

4. On the Additional Details step, add the tag impossible-travel and the MITRE ATT&CK® technique T1078 (Valid Accounts).

5. On the Notifications step, add a notification that routes alerts to your security team, then review the summary and create the event definition.

Once active, the event definition evaluates authentication activity on each run. If a user logs in from New York and then, 10 minutes later, from Singapore, Graylog creates an event and sends an alert according to your notification settings. From there, you can run a replay search on the related authentication logs, confirm whether the activity is unauthorized, and begin incident response.

Detecting a Silent Log Source

In this scenario, you want to know when a critical log source stops sending data, which could indicate a misconfiguration, a network outage, or an attacker disabling logging.

1. Create a new event definition under Alerts > Event Definitions, then set the title, priority, and description.

2. Select Anomaly Events as the Condition Type.

3. Configure the following fields:

   • Detection Type: Log Volume Anomalies

     Compares current message volume to the stream's historical baseline.

   • Streams: firewall-logs

     Monitors the firewall log source only.

   • Execute search every: 15 minutes

     Counts messages in 15-minute buckets.

   • Alert Direction: Low (volume drop)

     Alerts when volume falls below the baseline rather than above it.

   • Threshold Percent: 10

     Alerts when volume drops to 10% of the baseline or lower, a decrease of 90% or more.

4. On the Notifications step, add a notification that routes alerts to the team responsible for log collection, then review the summary and create the event definition.

When the firewall stops sending logs, the current bucket count falls below 10% of the baseline and Graylog creates an event. You can then investigate the logging source to determine the cause of the ingestion failure.

Best Practices

• Start with one detection type, one stream, and the default thresholds. Review the events it produces for a few days before tuning.

• Scope each definition with a Search Query or specific Streams. Evaluating only the relevant data reduces noise and load.

• Set Window Delay to cover your typical ingestion latency so late-arriving messages are not missed.

• For Log Volume Anomalies, let the stream collect a full Historical Time Period of data before relying on the alerts.

• Add an event procedure so analysts know how to respond, and use tags and MITRE ATT&CK® IDs to make anomaly events easy to filter and report on.

• Tune one setting at a time and note the effect, so you know which change reduced false positives.

Troubleshooting

Issue	Likely Cause	Resolution
No Impossible Travel events are created.	Authentication logs are missing source_geo_* fields, or the User Field does not match the field your logs use.	Confirm that GeoIP lookups are applied to source IPs (see Geolocation) and that the User Field is populated consistently.
No Log Volume events are created.	Fewer than 2 buckets were returned, or the data coverage ratio is below the Minimum Data Ratio. In either case, the detector skips alerting.	Allow the stream to collect a full Historical Time Period of data, or lower the Minimum Data Ratio for sparse sources.
Too many events are created.	Thresholds are too sensitive for your environment, or the search scope is too broad.	Raise the Distance Threshold or Threshold Percent, or narrow the Search Query and Streams.
Events miss recent activity.	Messages arrive after the search window has already been evaluated.	Increase the Window Delay to match your ingestion latency.
The event definition never runs.	The event definition is not enabled.	Edit the event definition and select Enable.

Further Reading

Explore the following additional resources and recommended readings to expand your knowledge on related topics:

• Anomaly Detection

• Random Cut Forest (RCF) Anomaly Detection

• Identify Events

• Cron Scheduling for Event Definitions

• Event Procedures

• Geolocation

• Asset Events