Events surrounding alert (1)

Hunt Hypothesis

Adversaries may be leveraging recent system activity to move laterally or execute follow-up actions, making this detection useful for identifying potential chain-of-events. SOC teams should proactively hunt for this behavior in Azure Sentinel to uncover coordinated attacks that rely on timing and contextual event relationships.

KQL Query

// Modified query: instead of copy-pasting the timestamp, get the timestamp of some event you can filter - MTP Schema
// In this example, take the time of the first detected event in an alert.
// We filter on alertId - which you can get from all our APIs (SIEM, Graph API, PowerBI, DeviceAlertEvents table) or from the UI (the last part of the link to the alert page)
let alertId = "636641078490537577_-1905871543";
let alert = AlertInfo | join AlertEvidence on AlertId | where AlertId == alertId | summarize AlertFirstTimestamp=min(Timestamp) by DeviceId;
let DeviceId = toscalar(alert | project DeviceId);
let timestamp = toscalar(alert | project AlertFirstTimestamp);
let lookupPeriod = 10m;
DeviceLogonEvents
| where Timestamp between ((timestamp - lookupPeriod) .. lookupPeriod)
        and DeviceId == DeviceId
        and LogonType == "Network"

Analytic Rule Definition

id: 55a29d46-2cd5-44af-80aa-20d0ac4c86f8
name: Events surrounding alert (1)
description: |
  This query looks for events that are near in time to a detected event.
  It shows how you could avoid typing exact timestamps, and replace it with a simple query to get the timestamp of your pivot event (e.g. a detected event).
  This is useful when you have queries that you run often - e.g. as part of your regular investigation of an alert.
  Original query: filter for network logon events right before some timestamp.
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - DeviceAlertEvents
  - AlertInfo
  - AlertEvidence
  - DeviceLogonEvents
query: |
  // Modified query: instead of copy-pasting the timestamp, get the timestamp of some event you can filter - MTP Schema
  // In this example, take the time of the first detected event in an alert.
  // We filter on alertId - which you can get from all our APIs (SIEM, Graph API, PowerBI, DeviceAlertEvents table) or from the UI (the last part of the link to the alert page)
  let alertId = "636641078490537577_-1905871543";
  let alert = AlertInfo | join AlertEvidence on AlertId | where AlertId == alertId | summarize AlertFirstTimestamp=min(Timestamp) by DeviceId;
  let DeviceId = toscalar(alert | project DeviceId);
  let timestamp = toscalar(alert | project AlertFirstTimestamp);
  let lookupPeriod = 10m;
  DeviceLogonEvents
  | where Timestamp between ((timestamp - lookupPeriod) .. lookupPeriod)
          and DeviceId == DeviceId
          and LogonType == "Network"

Required Data Sources

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/General queries/Events surrounding alert (1).yaml)

False Positive Guidance

• Scenario: A system administrator is performing a scheduled backup using Veeam Backup & Replication and generates a series of log entries around the same time as a legitimate system event.
  Filter/Exclusion: Exclude events related to Veeam Backup by checking the event source or message content for keywords like “backup” or “Veeam”.

• Scenario: An Ansible playbook is executed during maintenance window, causing multiple system events to be logged in a short time frame.
  Filter/Exclusion: Use the event source or event ID to filter out events generated by Ansible, or include a field indicating the playbook name in the event data.

• Scenario: A Windows Task Scheduler job is running, which triggers several event logs that appear suspicious due to their timing.
  Filter/Exclusion: Filter events where the event source is “Task Scheduler” or check for the presence of a scheduled task name in the event properties.

• Scenario: A PowerShell script is executed as part of a routine system health check, generating multiple events that cluster around the same time.
  Filter/Exclusion: Use event ID or event message to identify events generated by PowerShell scripts, or include a custom field indicating the script name or origin.

• Scenario: A SIEM correlation rule is triggered by a legitimate user activity, such as a user login or file access, which causes a chain of related events.
  Filter/Exclusion: Exclude events associated with known SIEM correlation rules by checking the event source or custom fields that indicate correlation rule execution.