Announcing Graylog Illuminate v7.2.0
Release Date: Oct 10th, 2026
In this release, we introduce new spotlights and processing packs as well as enhancements to existing content.
KNOWN ISSUES
- Illuminate: deprecation and eventual removal of some stream categories (3575)
- Illuminate will now assign stream categories based upon the GIM Categories assigned to logs stored in the associated streams. The following stream categories are deprecated, and will be removed in Illuminate version 8.0.0: “webserver”, “firewall”, “network_traffic”, “windows_logs”, “webserver”, “linux”, “system”, “compliance”, “endpoint”, “hids”.
ADDED
- Windows: Added support for Graylog Collector (4004)
- Linux: Added support for Graylog Collector (4005)
- Added event_sequence schema field (4030)
- Added event_sequence to support exact ordering of events beyond millisecond timestamp precision. Can be used as a tiebreaker when two or more events share the same timestamp.
- Added agent_* schema fields (4026)
- Added fields for normalizing agent-related properties in log messages to schema fields.
- Curated Alerts: Adding Windows Detection Chains III (3865)
- A unified pack of Windows detection chains for Graylog 7.2 and later: 74 detection chains and their 171 detection rules (event definitions), enriched with TruKno breach metadata. Replaces the Windows Detection Chains – Sigma Rules and Windows Detection Chains II – Sigma Rules packs.
- Apache HTTPD: add support for HTTPS access logs. (4031)
- Apache HTTPD access log parsing now also covers HTTPS access logs. The network protocol is set to https for these events and http for standard access logs.
FIXED
- Security Core: Corrected the search query for the DNS traffic to unapproved DNS Server event definition (4126)
- The “DNS traffic to unapproved DNS Server (Security Core: Perimeter)” event definition did not alert as intended because its search query did not group the DNS traffic check and the unapproved server check together. The query is now `(destination_port:53 OR _exists_:query_request) AND approved_dns_server:false`. It relies on `approved_dns_server` from the Core DNS Processing pack.
- Index templates: declare the streams field so it is available on empty indices (4080)
- The streams field is now declared in the index templates, so it is available for searches and aggregations on an Illuminate stream whose index has not received a message yet. Previously the field only became available after the first message reached the index. This applies to newly created indices. Existing indices are unchanged, and already have the field available.
- Security Core: Outbound transfer rules not filtering outbound traffic (4111)
- Updated the Security Core event definition query for outbound transfer/connections, fixing the query strings and assigning the correct stream categories. Updated the following event definitions: “Excessive Outbound Connections from Single Host (Security Core: Endpoint)”, “Large Outbound Transfer – Greater than 5GB (Security Core: Perimeter)”, “Large Outbound Transfer – Greater than 100MB (Security Core: Perimeter)”
- Linux: successful sshd logins were categorized as authentication.default instead of authentication.credential validation (4146)
- Successful SSH authentications were assigned the generic authentication.default GIM subcategory, so the SSH tab of the “Illuminate:Linux System Logs Overview” dashboard showed no successful logins. They are now categorized as authentication.credential validation, as are connection resets from invalid or illegal users.
- Security Core: A lot of noise from Security core rule. (4035)
- The Security Core event definition “Multiple Logins to service account in short time frame from different source (Security Core: Identity)” generated excessive findings. Adjusted the rule: – Raised threshold for >= 5 per query – Updated search window to query rolling 10 minute windows every 5 minutes – Excluded events where the source was a loopback address – Fixed an issue with the search filter not scoped to authentication events
- Palo Alto 11: SYSTEM auth events are now parsed and categorized, and the GlobalProtect dashboard uses event_outcome (4166)
- PAN-OS SYSTEM logs with the auth subtype (auth-success and auth-fail) were identified but their description was never parsed, leaving user_name, source_ip and event_outcome unpopulated. These events are now parsed and categorized as authentication.credential validation. The GlobalProtect Overview widgets now query the normalized event_outcome field instead of the vendor-specific vendor_event_outcome.
- AWS S3 indexing errors caused by illegal file_size value (3959)
- Event procedure step `Next steps for Unapproved DNS Server` not formatted (4140)
- Fixed formatting for this event procedure step, and improved procedure step by covering other conditions besides malicious DNS activity such as system/policy issues, etc.
- Security Core: Outbound transfer event definitions could miss activity spanning search windows (4156)
- Updated the “Large Outbound Transfer – Greater than 100MB (Security Core: Perimeter)” and “Large Outbound Transfer – Greater than 5GB (Security Core: Perimeter)” event definitions to use overlapping search windows. Previously, these aggregation event definitions searched a 5 minute window every 5 minutes. Because the aggregation only counts activity within a single window, a transfer that spanned two adjacent 5 minute blocks – for example starting near the end of one window and continuing into the next – could be split across both searches and never accumulate enough volume in either one to trigger an alert. The search window has been widened to 10 minutes while keeping the 5 minute execution interval, so each search overlaps the previous one and captures activity that crosses a window boundary.
- Security Core – VPN Access Report references widget that no longer exists (4010)
- Palo Alto 11 not parsing event_created (4174)
- The Palo Alto 11 pack was not identifying high resolution timestamps where the timezone was greater than GMT (+XX:XX). Updated the timestamp matching pattern to identify and handle these timestamps properly. This update also sets a strict pattern (YYYY-MM-DD’T’HH:MM:SS.SSSZ) for the date format for the event_created field.
- Windows Security: Event ID 6416 miscategorized (4181)
- This event was incorrectly categorized as a system driver load but this is a device attachment event. This resulted in Security Core’s driver load detection generating excessive false positive findings. Removed the system driver load categorization assignment, leaving it empty. A device attached event will be defined in GIM in the future. Added normalization of user details from 6416 to user_name, user_id, et cetera.
- Suricata: DCERPC interface details no longer cause an indexing error and are captured as searchable fields. (3970)
- Suricata DCERPC events no longer fail to index on their interface list; the interface UUID and version are captured in vendor_data_dcerpc_interface_uuid and vendor_data_dcerpc_interface_version.
- Palo Alto field vendor_high_res_time may contain a 0, which fails to be parsed as a date (4020)
- Fortigate auth log misclassified as event_outcome: failure (4056)
- The Fortigate pack treated authentication without an explicit success outcome as a failure but success is implicit for some Fortigate events. Updated the Fortigate pack, removing the implicit failure, and assigning event_outcome = success for user events where success is implied by the log. User events that do not have a success/failure outcome, and where success is not implicit, will now no longer have an outcome assigned.
- Security Core: Some event definitions have broken custom fields (4148)
CHANGED
- Change Request: Security Core – Configure event definition custom fields to exclude empty fields (4147)
- Suricata: parse EVE JSON delivered behind a non-JSON forwarder prefix (such as Vectra), and stop storing failed/unknown app_proto values in network_protocol. (3973)
- Suricata EVE JSON delivered behind a forwarder prefix (such as Vectra) is now parsed, and network_protocol is no longer set to “failed” or “unknown”.
- Add a field identifying the schema version a pack complies with (4023)
- All processing packs will now create the field `sdm_version` which indicates which version of the Security Data Model (SDM) the pack supports.
- Add a schema version property to the SDM components (4024)
- Security Core: Migrating event definitions to the tactics_techniques field (4061)(3865)
- The MITRE ATT&CK coverage on Security Core event definitions now lives in the tactics_techniques field on the event definition and on the alerts it generates, rather than in custom sigma_rule_tag_N fields stamped onto each event. Coverage shows up as named chips on the event definition and on alerts, and drives filtering, the tactic and technique histograms, and threat coverage. Requires Graylog 7.2 or later. Any saved searches, dashboard widgets, or pipeline rules that reference the sigma_rule_tag_N fields by name should be updated to use tactics_techniques, since support for the older fields may be removed in a future version of Graylog.
- Illuminate – Remove version filtering for Beats (4057)
- Beats compatibility is only certified with version 8.19.7 but later versions should function normally. This change enables support for later/future versions of beats.
- Illuminate Core: Added support for file watchlist processing (4099)
- Illuminate Core will now, when Illuminate is activated, inspect all messages with the field “file_path” and check it against the file watchlist. When matches are found, the value “watchlist_file” will be added to the “gim_tags” field. Matches must be exact, but are case insensitive.
REMOVED
- Curated Alerts: Removing Windows Detection Chains – Sigma Rules and Windows Detection Chains II – Sigma Rules (3865)
- Both packs are superseded by Windows Detection Chains (Graylog 7.2). On upgrade to this bundle, existing installations of either pack are moved onto the new pack automatically: the detection rules keep their identities along with any notifications, search filters, and enabled state, and the old packs are uninstalled.
Let us know what you’d like to have included in our GitHub issue tracker.