10.6 Livestream: Real-Time Hunting

Livestream: Real-Time Hunting

Introduction

Standard hunting queries run once — you execute the query, review the results, and close the tab. If the threat you are hunting for occurs 5 minutes after you close the tab, you miss it. Livestream solves this: it continuously runs a hunting query against incoming data and alerts you when results appear. Livestream is real-time hunting — the query runs persistently until you stop it.

How Livestream works

Navigate to Sentinel → Hunting → Livestream tab → New Livestream.

Provide a name, a KQL query, and optionally an alert action (notification when results appear). The Livestream begins executing continuously against incoming data. When new events match the query, they appear in the Livestream results pane in near-real-time.

Livestream vs NRT rules vs scheduled rules:

Livestream is for temporary, active hunting sessions. You start it when hunting, monitor it during the session, and stop it when done. It does not create incidents or alerts in the Sentinel queue.

NRT rules (Module 9.3) are for permanent, automated detection. They run continuously, create alerts, and generate incidents. They are part of the detection library.

Scheduled rules (Module 9.2) are for periodic, automated detection. They run on a schedule, create alerts, and generate incidents.

When to use Livestream: During an active investigation — you have found an initial indicator and want to watch for related activity in real time. During a hypothesis hunt — you want to monitor for a specific pattern while you investigate other aspects of the hypothesis. After a containment action — you want to verify the attacker is not re-establishing access while you clean up.

When NOT to use Livestream: For permanent detection — use a scheduled or NRT rule instead. Livestream stops when you close the session. For detection that requires analyst notification — Livestream results require you to watch the pane. For automated response — Livestream cannot trigger playbooks.

Livestream query examples

Monitor for new sign-ins from a specific attacker IP:

1
2
3

SigninLogs
| where IPAddress == "203.0.113.47"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResultType

Start this Livestream after identifying the attacker IP during an incident. It immediately alerts you if the attacker attempts to use the same IP to access another account — even while you are performing containment on the first compromised account.

Monitor for new inbox rules during a BEC investigation:

1
2
3
4
5

CloudAppEvents
| where ActionType == "New-InboxRule"
| extend Creator = tostring(parse_json(RawEventData).UserId)
| extend RuleDetails = tostring(parse_json(RawEventData).Parameters)
| project TimeGenerated, Creator, RuleDetails

During a BEC investigation, the attacker may create new inbox rules on additional compromised accounts. This Livestream catches them immediately.

Monitor for lateral movement after initial containment:

1
2
3
4
5

SecurityEvent
| where EventID == 4624
| where LogonType in (3, 10)
| where Account has "compromised-user"
| project TimeGenerated, Computer, Account, IpAddress, LogonType

After revoking the compromised user’s tokens, monitor for any new logon events from that account — indicating the attacker has obtained new credentials or found another access method.

Advanced Livestream patterns

Multi-entity monitoring. During a campaign investigation, you identify 3 compromised accounts and 2 attacker IPs. Create separate Livestreams for each entity — 5 concurrent streams watching for any activity from the attacker’s known infrastructure.

1
2
3
4
5
6
7
8
9

// Livestream: all activity from known attacker infrastructure
SigninLogs
| where IPAddress in ("203.0.113.47", "198.51.100.22")
    or UserPrincipalName in (
        "j.morrison@northgateeng.com",
        "s.chen@northgateeng.com",
        "a.patel@northgateeng.com")
| project TimeGenerated, UserPrincipalName, IPAddress,
    AppDisplayName, ResultType

Data exfiltration monitoring. During an insider threat investigation, watch for the suspect transferring files.

1
2
3
4
5
6
7

// Livestream: file download activity by suspect user
CloudAppEvents
| where AccountObjectId == "suspect-user-object-id"
| where ActionType in ("FileDownloaded", "FileSyncDownloadedFull",
    "FileAccessed", "FileCopied")
| project TimeGenerated, ActionType, Application,
    FileName = tostring(parse_json(RawEventData).SourceFileName)

Post-containment verification. After blocking an attacker (password reset, device isolation, IP block), verify the containment is effective.

1
2
3
4
5
6
7
8

// Livestream: verify no new activity from contained entities
union
    (SigninLogs | where IPAddress == "203.0.113.47"
        | project TimeGenerated, Source = "SignIn", Detail = UserPrincipalName),
    (CommonSecurityLog | where SourceIP == "203.0.113.47"
        | project TimeGenerated, Source = "Firewall", Detail = DeviceAction),
    (DeviceNetworkEvents | where RemoteIP == "203.0.113.47"
        | project TimeGenerated, Source = "Endpoint", Detail = DeviceName)

If this Livestream shows any results after containment, the block is incomplete — the attacker is still reaching your environment through an unblocked path.

Livestream limitations and workarounds

Limitation 1: No persistence. Livestream sessions stop when you close the browser tab or navigate away. Workaround: for monitoring that must persist beyond a single session, convert the Livestream query to an NRT rule (subsection 9.3). The rule runs permanently until you disable it.

Limitation 2: No alerting. Livestream does not push notifications. You must watch the results pane to see new events. Workaround: for critical monitoring that requires notification, use an NRT rule with a Teams notification playbook. The NRT rule alerts you even when you are not watching the Livestream.

Limitation 3: Limited result history. Livestream shows recent results but does not maintain a scrollable history of all results since the stream started. Workaround: periodically bookmark important results as they appear. After the session, the bookmarks preserve the evidence.

Limitation 4: No entity mapping in results. Livestream results display as raw query output — entities are not clickable cards. Workaround: when you find a suspicious result, run the same query in the Logs blade, select the result, and create a bookmark with entity mapping.

Multi-analyst Livestream coordination

During a major incident with multiple analysts investigating simultaneously, coordinate Livestream usage to avoid duplication and maximise coverage.

Analyst 1: Monitor the attacker’s known IP. Livestream: SigninLogs | where IPAddress == "attacker-ip".

Analyst 2: Monitor the compromised accounts. Livestream: CloudAppEvents | where AccountObjectId in ("user1-id", "user2-id") | where ActionType has_any ("New-InboxRule", "Set-InboxRule", "HardDelete").

Analyst 3: Monitor network egress. Livestream: CommonSecurityLog | where DestinationIP == "attacker-ip" | where DeviceAction != "deny".

Each analyst covers a different data source and entity type. Communication via the SOC Teams channel: “My Livestream just showed Analyst-2’s compromised account accessing SharePoint — possible data exfiltration in progress.”

Livestream operational workflow

Livestream operational workflow

Step 1: Identify the entity to monitor. During investigation, determine the IP, account, or device that represents the attacker’s activity.

Step 2: Start the Livestream. Write a focused query targeting that entity. Keep queries narrow — a Livestream that returns 100 results per minute is unusable.

Step 3: Monitor while investigating. Keep the Livestream tab open while performing other investigation tasks. If new results appear, investigate them immediately — they may reveal the attacker’s next move.

Step 4: Bookmark significant results. If the Livestream surfaces a critical finding (the attacker accessing a new account, creating a new persistence mechanism), create a bookmark before the data scrolls past.

Step 5: Stop and convert. When the active investigation concludes, stop the Livestream. If the query proved valuable, consider converting it to a permanent NRT or scheduled rule — ensuring the detection persists after the hunt ends.

Managing active Livestreams

The Livestream tab shows all active streams with their name, status, and result count. You can have multiple Livestreams running simultaneously — one per active investigation aspect.

Stopping a Livestream. Click the stop button on the Livestream. Results from the session are retained temporarily but not persisted — if you found something important, create a bookmark before stopping the stream.

Promoting Livestream to a permanent rule. If a Livestream query proves valuable during the hunt and you want it to run permanently, convert it to a scheduled or NRT rule. The Livestream query becomes the analytics rule KQL. Add entity mapping, custom details, and alert grouping (which Livestream does not support), and deploy as a permanent detection.

Knowledge check