11.6 Livestream: Real-Time Hunting

Livestream: Real-Time Hunting

Introduction

Required role: Microsoft Sentinel Reader (minimum for hunting queries). Sentinel Contributor for bookmark and hunt management.

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 10.3) are for permanent, automated detection. They run continuously, create alerts, and generate incidents. They are part of the detection library.

Scheduled rules (Module 10.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 as an investigation accelerator

Livestream is not only for monitoring known threats. It accelerates active investigations by providing real-time visibility into evolving situations.

During AiTM investigation (Module 12). When you discover the first compromised account, start a Livestream for the attacker IP before investigating further. While you are running sign-in log queries and assessing post-compromise activity, the Livestream is watching for additional victims in real time. This parallel monitoring means you discover Wave 2 immediately — not 6 hours later when you expand the investigation scope.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Investigation accelerator: monitor for attacker pivoting to new accounts
// Start this Livestream the moment you identify the attacker IP
let AttackerIPs = dynamic(["203.0.113.47", "203.0.113.52"]);
union
    (SigninLogs | where IPAddress in (AttackerIPs)
        | project TimeGenerated, Source = "Interactive", UserPrincipalName,
            IPAddress, AppDisplayName, ResultType),
    (AADNonInteractiveUserSignInLogs | where IPAddress in (AttackerIPs)
        | project TimeGenerated, Source = "NonInteractive", UserPrincipalName,
            IPAddress, AppDisplayName, ResultType)
| project TimeGenerated, Source, UserPrincipalName, IPAddress, AppDisplayName,
    Result = iff(ResultType == "0", "SUCCESS", strcat("FAILED-", ResultType))

This combined Livestream monitors both interactive AND non-interactive sign-ins from the attacker — catching both browser-based and API-based token replay in real time.

During insider threat investigation (Module 16). While you are reconstructing the suspect’s activity history, start a Livestream for real-time file access monitoring:

1
2
3
4
5
6
7
8

// Livestream: insider threat real-time file monitoring
CloudAppEvents
| where AccountObjectId == "suspect-user-object-id"
| where ActionType in ("FileDownloaded", "FileSyncDownloadedFull",
    "FileCopied", "FileUploaded")
| extend FileName = tostring(parse_json(RawEventData).SourceFileName)
| extend SiteName = tostring(parse_json(RawEventData).SiteUrl)
| project TimeGenerated, ActionType, FileName, SiteName

If the suspect starts downloading files while you are analysing their history, the Livestream catches it immediately — giving you real-time evidence and potentially accelerating the HR/legal decision.

Livestream query performance. Keep Livestream queries focused. A query that scans all of SigninLogs with no filter runs continuously against every incoming record — consuming query capacity and returning too many results. Always filter: by specific IP, specific user, specific ActionType, or a combination. The ideal Livestream query returns 0-2 results per minute under normal conditions and spikes when the attacker acts.

Livestream to NRT rule promotion workflow

When a Livestream query proves valuable, promote it to a permanent NRT rule:

1. Copy the Livestream KQL.
2. Navigate to Sentinel → Analytics → Create → NRT rule.
3. Paste the KQL. Add entity mapping (Account, IP, Host) — which Livestream does not support.
4. Add MITRE ATT&CK technique mapping.
5. Configure alert grouping (group by entity to create one incident per affected user).
6. Set severity based on the finding type.
7. Enable the rule.

The Livestream was your real-time eye during an active investigation. The NRT rule becomes your permanent detector for the same pattern — running 24/7 without an analyst watching a browser tab.

Livestream limitations and workarounds

Livestream query tuning for noise reduction. A Livestream that returns 50 results per minute is unusable — the signal drowns in noise. Tune before starting:

1
2
3
4
5
6
7
8
9

// BAD: too broad — matches every sign-in failure in the tenant
SigninLogs
| where ResultType != "0"

// GOOD: focused on a specific investigation entity
SigninLogs
| where ResultType != "0"
| where IPAddress == "203.0.113.47"
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// BAD: monitors all file activity — returns thousands of events per hour
CloudAppEvents
| where ActionType == "FileDownloaded"

// GOOD: monitors a specific user during an active investigation
CloudAppEvents
| where ActionType == "FileDownloaded"
| where AccountDisplayName == "Marcus Chen"
| extend FileName = tostring(parse_json(RawEventData).SourceFileName)
| project TimeGenerated, FileName, Application

The focus rule: Every Livestream query must filter on at least one specific entity (IP, user, device, or domain). Tenant-wide Livestream queries are noise generators, not monitoring tools.

Concurrent Livestream management. During a major incident, you may run 3-5 simultaneous Livestreams. Keep a note (physical sticky note or Teams message to yourself) listing: which Livestream is monitoring which entity, and which browser tab each stream is in. When a stream fires, you need to know which entity triggered — without switching between tabs to check.

Livestream during the incident response lifecycle

Livestream is not just a hunting tool — it is an incident response tool. Each phase of the incident lifecycle benefits from real-time monitoring.

During triage. The analytics rule fired. You are assessing the initial alert. Start a Livestream for the affected user and the suspicious IP immediately. While you are reading the alert details and running the first investigation queries, the Livestream watches for the attacker’s next move. If the attacker creates an inbox rule or accesses a second account while you are triaging, you know within seconds.

During investigation. You are deep in the sign-in logs, reconstructing the attack timeline. The Livestream runs in a second tab. When you find the first compromised account (j.morrison), you add a second Livestream for j.morrison’s mailbox activity. When you discover a second compromised account (s.chen), you add a third. Each stream covers a different entity — together they provide 360-degree real-time visibility of the attacker’s activity while you investigate the historical data.

During containment. You revoke tokens and reset the password. Is the containment effective? Start a Livestream filtered for the contained user and the attacker IP. If results appear after containment: the attacker has an alternative access path (OAuth app, registered device) — escalate. If the Livestream is silent for 30+ minutes: containment is holding.

During eradication. You remove inbox rules, forwarding, and MFA registrations. The Livestream monitors for: new inbox rules being created (the attacker re-establishing persistence), new MFA registrations (the attacker registering a backup method), and new sign-ins from the attacker IP (any remaining access).

During recovery. The user re-authenticates with their new password and resumes work. The Livestream monitors for abnormal activity from the user’s account — ensuring the account is genuinely under the user’s control and not the attacker’s.

The Livestream accompanies the entire incident — from first alert to confirmed closure. It is not a separate hunting activity bolted onto the investigation. It is the real-time monitoring layer that runs in parallel with every investigation step.

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 10.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