Lab: Detecting Infostealer Session Hijacking in Microsoft Sentinel

Overview

This lab deploys a five-rule detection stack for infostealer session hijacking to an existing Microsoft Sentinel workspace. Infostealers can steal browser cookies and session tokens that carry claims from an earlier MFA-protected sign-in, allowing an attacker to replay the session without repeating the victim’s interactive password and MFA ceremony while the session remains valid. The detection rules focus on the behavioral anomalies that stolen-token replay leaves in Entra ID non-interactive sign-in logs.

Blog post: Detecting Infostealer Session Hijacking with Microsoft Sentinel

Reviewed source: j-dahl7/session-hijack-detection-sentinel at 9cec443

Prerequisites

Quick Start

# Clone the companion repo
git clone https://github.com/j-dahl7/session-hijack-detection-sentinel.git
cd session-hijack-detection-sentinel
git checkout 9cec4432e0f14b83cf871da90b0323273b8a8d37

# Deploy to your Sentinel workspace
./scripts/Deploy-Lab.ps1 -ResourceGroup "rg-sentinel-lab" -WorkspaceName "law-sentinel-lab"

# Run the simulation
./scripts/Test-SessionHijack.ps1

What Gets Deployed

Test Scenarios

Test-SessionHijack.ps1 is a safe connectivity and seed-activity helper, not a deterministic incident generator:

1. Varied Graph request headers — validates five low-privilege /me requests; those headers are not guaranteed to become Entra DeviceDetail fingerprints.
2. Graph request burst — validates a controlled request path; cached-token requests do not create one new Entra refresh row per request.
3. Current-IP token use — provides context when the actual token activity produces a new source IP.
4. Impossible travel — still requires controlled token issuance or refresh from a VPN or Azure Cloud Shell region.
5. Revoked grant followed by new-IP authentication — requires an authorized manual sequence: produce a real 50173 row for a dedicated lab user, then authenticate the same immutable UserId from a different IP within 30 minutes.

Earlier revisions of all five rule families have historical live-incident evidence in the companion article. That evidence does not validate every condition in the current pinned queries: Rule 4 now requires one recorded SessionId; Rule 5 now requires documented error 50173 and correlates both sign-in tables on a nonempty immutable UserId; and Rule 1’s tuple/baseline behavior has changed. It also does not prove the helper caused Rules 3 and 4. Validate the surge rule with real non-interactive token issuance or refresh volume, and validate the fingerprint rule with controlled sign-ins that populate both SessionId and genuinely different DeviceDetail fingerprints for that same recorded session. Impossible travel and the revoked-grant sequence still require the documented manual steps. Error 50173 can also follow password changes, token expiry, or administrator revocation, so a match is a triage lead rather than proof of token theft or CAE enforcement.

Cost Estimate

This lab creates no new workspace or ingestion pipeline; it deploys analytics rules and a shared workbook into an existing Sentinel workspace. Existing Microsoft Sentinel and Log Analytics ingestion, retention, query, and related workspace charges still apply. AADNonInteractiveUserSignInLogs can be high-volume, so review the tenant’s data volume and retention settings before enabling or extending collection.

Cleanup

./scripts/Deploy-Lab.ps1 -ResourceGroup "rg-sentinel-lab" -WorkspaceName "law-sentinel-lab" -Destroy

This removes all 5 analytics rules and the workbook. Diagnostic settings are not modified.