Events surrounding alert (3)

Hunt Hypothesis

Adversaries may be leveraging recently detected activity to move laterally or escalate privileges within the network. SOC teams should proactively hunt for these correlated events in Azure Sentinel to identify potential follow-on malicious actions and disrupt attack chains early.

KQL Query

// Modified query: instead of copy-pasting the timestamp, get the timestamp of some event you can filter
// 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: c4955324-02ff-46fa-a642-64952334482d
name: Events surrounding alert (3)
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
  // 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 (3).yaml)

False Positive Guidance

• Scenario: A system administrator manually logs into a server to perform a scheduled maintenance task.
  Filter/Exclusion: Exclude events related to known administrative tasks using the event_id or process_name of legitimate administrative tools (e.g., event_id=4624 with process_name=taskmgr.exe or event_id=4624 with process_name=cmd.exe and logon_type=10).

• Scenario: A scheduled backup job runs and generates a series of file access events.
  Filter/Exclusion: Exclude events associated with backup processes using the process_name field (e.g., process_name=wbadmin.exe or process_name=backup.exe) or by checking the event_data for backup-related keywords.

• Scenario: A user initiates a remote desktop session to access a server for troubleshooting.
  Filter/Exclusion: Exclude events related to remote desktop connections using the event_id=4624 with logon_type=10 (interactive logon) or by checking the source_ip against known internal IP ranges.

• Scenario: A system update or patching task is executed via a configuration management tool like Ansible or Puppet.
  Filter/Exclusion: Exclude events related to configuration management tools using the process_name field (e.g., process_name=ansible.exe, process_name=puppet.exe) or by checking the event_data for known update-related keywords.

• Scenario: A user runs a legitimate script or tool (e.g., PowerShell or Python) to perform routine system checks or data processing.
  Filter/Exclusion: Exclude events associated with known scripting tools using the process_name field (e.g., process_name=powershell.exe, process_name=python.exe) or by checking the event_data