Use this skill when asked to trace authentication flows, analyze SessionId chains, investigate token reuse vs interactive MFA, or assess geographic anomalies in sign-ins. Triggers on keywords like "trace authentication", "trace back to interactive MFA", "SessionId analysis", "token reuse", "geographic anomaly", "impossible travel", or when investigating suspicious sign-in locations. This skill provides forensic analysis of Entra ID authentication chains to distinguish legitimate activity from credential/token theft.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use this skill when asked to trace authentication flows, analyze SessionId chains, investigate token reuse vs interactive MFA, or assess geographic anomalies in sign-ins. Triggers on keywords like "trace authentication", "trace back to interactive MFA", "SessionId analysis", "token reuse", "geographic anomaly", "impossible travel", or when investigating suspicious sign-in locations. This skill provides forensic analysis of Entra ID authentication chains to distinguish legitimate activity from credential/token theft.
The key distinction is whether the user actively performed MFA at a suspicious location or if the authentication used a refresh token from a prior session.
🚨 MANDATORY CHECKPOINT: Before providing ANY risk assessment for authentication anomalies:
STOP - Do not improvise or use general security knowledge
READ the complete risk assessment framework in this document
QUOTE specific instruction sections in your analysis
VERIFY your conclusions match documented guidance before responding to user
Before executing ANY authentication tracing queries, you MUST:
Read the SessionId-based workflow (Steps 1-6 below) in full
Search the investigation JSON for IP enrichment data (ip_enrichment array) - PRIMARY DATA SOURCE
Follow the documented steps in order (SessionId → Authentication chain → Interactive MFA → Risk assessment)
Use IP enrichment context in your final risk assessment (VPN status, abuse scores, threat intel, auth patterns)
Skipping these steps will result in incomplete or incorrect analysis.
Key Forensic Indicators
When investigating anomalous sign-ins (e.g., from new countries, IPs, or devices), it's critical to determine whether the user actively performed MFA at that location or if the authentication used a refresh token from a prior session.
Array contains ONLY "Previously satisfied" entries
Shows "MFA requirement satisfied by claim in the token"
authenticationStepDateTime Correlation
If authenticationStepDateTime references a time when NO interactive auth occurred, it indicates token reuse
Cross-reference timestamps with events that have RequestSequence > 0 to trace token origin
IP Enrichment Data Structure (PRIMARY EVIDENCE SOURCE)
CRITICAL: The investigation JSON contains a comprehensive ip_enrichment array with authoritative detection flags.
Always reference this data FIRST before making VPN/proxy/Tor determinations.
Example IP Enrichment Entry (Actual JSON Structure)
{"ip":"203.0.113.42",// ← KEY: Use "ip" field, not "ip_address""city":"Singapore","region":"Singapore","country":"SG","org":"AS12345 Example Hosting Ltd","asn":"AS12345","timezone":"Asia/Singapore","risk_level":"HIGH",// ← Overall risk assessment (LOW/MEDIUM/HIGH)"assessment":"⚠️ Threat Intelligence Match: Commercial VPN Service Detected","is_vpn":true,// ← PRIMARY VPN DETECTION FLAG (ipinfo.io detection)"is_proxy":false,// ← PRIMARY PROXY DETECTION FLAG"is_tor":false,// ← PRIMARY TOR DETECTION FLAG"abuse_confidence_score":0,// ← AbuseIPDB score 0-100 (0=clean, 75+=high risk)"total_reports":2,// ← Number of abuse reports in AbuseIPDB"is_whitelisted":false,"threat_description":"Commercial VPN Service: Known Anonymization Infrastructure","anomaly_type":"NewInteractiveIP","first_seen":"2025-10-16",// ← First sign-in from this IP (date string)"last_seen":"2025-10-16",// ← Last sign-in from this IP (date string)"hit_count":5,// ← Number of anomaly detections"signin_count":8,// ← Total sign-ins from this IP"success_count":7,// ← Successful authentications"failure_count":1,// ← Failed authentications"last_auth_result_detail":"MFA requirement satisfied by claim in the token","threat_detected":false,// ← Legacy field (use threat_description instead)"threat_confidence":0,"threat_tlp_level":"","threat_activity_groups":""}
CRITICAL: Always use ip_enrichment[].ip to match IPs, NOT ip_address!
Key Fields for Analysis
Field
Purpose
Usage Example
is_vpn
Definitive VPN detection
is_vpn: true → Confirmed VPN endpoint (don't infer, use this flag)
Key trade-off:AuthenticationDetails (Data Lake only) provides per-step RequestSequence and authenticationMethod ("Password", "Previously satisfied", "Mobile app notification"). EntraIdSignInEvents replaces this with row-level LogonType (interactive vs non-interactive) + AuthenticationRequirement (singleFactor/multiFactor) + UniqueTokenId. Both achieve the same forensic goal — determining interactive MFA vs token reuse — through different signals.
⚠️ Table name casing: Capital I in SignIn — EntraIdSignInEvents, NOT EntraIdSigninEvents.
⚠️ LogonType is a JSON array string (e.g., ["interactiveUser"]). Use has for filtering, NOT ==.
CRITICAL: START WITH SessionId - This is Your Primary and Most Efficient Investigation Pattern:
Query suspicious IP(s) to get SessionId (single query for all suspicious IPs)
Query SessionId for complete chain — interactive vs non-interactive classification, geographic progression, token tracking
Find interactive sign-ins to determine where the user (or attacker) authenticated interactively
Expand date range progressively if needed: investigation window → 7 days → 30 days (AH limit)
If > 30d lookback required: Switch to Data Lake fallback queries (90d retention)
AVOID chronological searching without SessionId - it requires multiple queries and is less efficient.
Step 1: Get SessionId from Suspicious Authentication (ALWAYS START HERE)
Tool:RunAdvancedHuntingQuery
This single query gives you SessionId AND enough context to determine next steps:
let suspicious_ips = dynamic(["<IP_1>", "<IP_2>"]); // All suspicious IPs
EntraIdSignInEvents
| where Timestamp > ago(30d)
| where AccountUpn =~ '<UPN>'
| where IPAddress in (suspicious_ips)
| project Timestamp, IPAddress, Country, City, Application,
SessionId, LogonType, AuthenticationRequirement,
UserAgent, Browser, OSPlatform, ErrorCode, UniqueTokenId
| order by Timestamp asc
| take 50
What This Returns:
SessionId(s) for suspicious authentications (your primary key for Step 2)
Device fingerprint (UserAgent) to check for device consistency
Application context
Initial timeline
Critical Decision Point:
All suspicious IPs share same SessionId? → Session continuity detected → Investigate further (could be legitimate user OR stolen token)
Different SessionIds across IPs? → Different authentication flows → Investigate device and authentication patterns
IMPORTANT: SessionId alone does NOT determine legitimacy - must correlate with UserAgent, geography, and behavior patterns
Step 2: Trace Complete Authentication Chain by SessionId (DEFINITIVE PROOF)
Tool:RunAdvancedHuntingQuery
Once you have SessionId from Step 1, query ALL authentications in that session:
let target_session_id = "<SESSION_ID_FROM_STEP_1>";
EntraIdSignInEvents
| where Timestamp > ago(30d)
| where AccountUpn =~ '<UPN>'
| where SessionId == target_session_id
| project Timestamp, IPAddress, Country, City, Application,
LogonType, AuthenticationRequirement, ErrorCode,
UserAgent, Browser, OSPlatform, UniqueTokenId
| order by Timestamp asc
This Single Query Reveals:
Complete geographic progression (all IPs/locations in chronological order)
Where interactive authentication occurred (LogonType has "interactiveUser" + AuthenticationRequirement == "multiFactorAuthentication")
Token reuse pattern (LogonType has "nonInteractiveUser" — all subsequent events using cached tokens)
Device consistency (Browser + UserAgent + OSPlatform should match across session)
Time gaps between locations (assess physical possibility of travel)
Token-level tracking (UniqueTokenId — same token reused across IPs = session continuity)
Critical Evidence - What SessionId Indicates:
SessionId is a browser session identifier that tracks authentication flows
Same SessionId across IPs = Session continuity (could be legitimate user OR stolen token replay)
SessionId does NOT prove device identity - stolen refresh tokens maintain session continuity
Same SessionId + Same UserAgent + Geographic impossibility = Possible token theft
Token theft attacks maintain the original SessionId - attacker inherits session from stolen token
CRITICAL: Same SessionId does NOT rule out credential/token theft
Analysis Pattern:
Look at FIRST authentication in session (earliest Timestamp)
Check if LogonType has "interactiveUser" → User performed interactive authentication at that IP/location
Check AuthenticationRequirement → multiFactorAuthentication = MFA was required and satisfied; singleFactorAuthentication = password-only
Subsequent events with LogonType has "nonInteractiveUser" = token reuse (expected OAuth flow)
Verify device consistency (Browser + UserAgent should match across session; different = possible token theft)
Assess geographic progression (impossible travel = high risk; reasonable = needs user confirmation)
Track UniqueTokenId — same token ID across geographically distant IPs = session continuity (could be VPN OR stolen token)
Step 3: Find Interactive Sign-Ins with Progressive Date Range Expansion
Tool:RunAdvancedHuntingQuery (≤30d) or Data Lake fallback (>30d)
Use this when Step 2 shows only nonInteractiveUser logon types (no interactive auth in the session)
Query Pattern:
EntraIdSignInEvents
| where Timestamp > ago(30d)
| where AccountUpn =~ '<UPN>'
| where LogonType has "interactiveUser"
| where ErrorCode == 0
| summarize
SignInCount = count(),
Apps = make_set(Application, 5),
Countries = make_set(Country, 3),
AuthReqs = make_set(AuthenticationRequirement),
TokenIds = dcount(UniqueTokenId),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp)
by IPAddress, SessionId
| order by LastSeen desc
| take 20
What This Returns:
All IPs where the user performed interactive sign-ins, grouped by session
AuthenticationRequirement per IP — reveals whether MFA was required or bypassed
TokenIds count — how many distinct tokens were issued from each IP/session pair
Match SessionIds against Step 1 results — if the suspicious SessionId also has interactive sign-ins from a VPS IP, the attacker has the password
Progressive expansion (if AH 30d window is insufficient):
If no interactive sign-ins found in 30d → Switch to Data Lake fallback queries for 90d lookback
Tokens can be valid for up to 90 days depending on tenant policy
Data Lake Fallback Queries (>30d)
Use these when the AH 30d window is insufficient — e.g., tracing token origins older than 30 days.
Tool:mcp_sentinel-data_query_lake with workspaceId
Step 1 (Data Lake):
let suspicious_ips = dynamic(["<IP_1>", "<IP_2>"]);
union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(90d)
| where UserPrincipalName =~ '<UPN>'
| where IPAddress in (suspicious_ips)
| project TimeGenerated, IPAddress, Location, AppDisplayName,
SessionId = tostring(SessionId), UserAgent, ResultType, CorrelationId
| order by TimeGenerated asc
| take 50
Step 2 (Data Lake) — with per-step auth detail:
let target_session_id = "<SESSION_ID>";
union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(90d)
| where UserPrincipalName =~ '<UPN>'
| where SessionId == target_session_id
| extend AuthDetails = parse_json(tostring(AuthenticationDetails))
| mv-expand AuthDetails
| extend AuthMethod = tostring(AuthDetails.authenticationMethod)
| extend AuthStepDateTime = todatetime(AuthDetails.authenticationStepDateTime)
| extend RequestSeq = toint(AuthDetails.RequestSequence)
| project TimeGenerated, IPAddress, Location, AppDisplayName,
AuthMethod, AuthStepDateTime, RequestSeq, UserAgent, ResultType
| order by TimeGenerated asc
Data Lake advantage:AuthenticationDetails provides granular per-step RequestSequence and authenticationMethod ("Password", "Previously satisfied", "Mobile app notification") not available in EntraIdSignInEvents. Use this for forensic-grade MFA step tracing when AH's LogonType + AuthenticationRequirement columns are insufficient.
Step 3 (Data Lake) — interactive MFA search:
union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(90d)
| where UserPrincipalName =~ '<UPN>'
| extend AuthDetails = parse_json(tostring(AuthenticationDetails))
| mv-expand AuthDetails
| extend AuthMethod = tostring(AuthDetails.authenticationMethod)
| extend RequestSeq = toint(AuthDetails.RequestSequence)
| where AuthMethod != "Previously satisfied"
| where RequestSeq > 0
| project TimeGenerated, IPAddress, Location, AppDisplayName, AuthMethod,
RequestSeq, SessionId = tostring(SessionId), UserAgent, ResultType
| order by TimeGenerated desc
| take 30
Step 4: Collect All IPs from Authentication Chain
CRITICAL: After completing the SessionId trace, extract ALL unique IP addresses discovered:
From Interactive MFA session (Step 3 results)
From Suspicious session (Step 1 results)
From Complete SessionId chain (Step 2 results)
Build comprehensive IP list for enrichment analysis.
Step 5: Analyze IP Enrichment Data for ALL Discovered IPs
MANDATORY: Search investigation JSON ip_enrichment array for EVERY IP in the authentication chain:
For each IP address discovered in Steps 1-3:
Locate IP in ip_enrichment array (search by "ip": "<IP_ADDRESS>" field)
IP Enrichment Analysis for ALL IPs: Present enrichment data for EVERY IP discovered in trace (VPN status, abuse scores, threat intel, auth patterns, frequency, temporal context)
Connection Proof: SessionId match + time gap + geographic distance + comprehensive enrichment context from all IPs
Risk Assessment: Evaluate based on context - MUST quote specific instruction criteria
SessionId does NOT prove device identity - token theft maintains session continuity
Same SessionId across geographically distant IPs = Requires investigation (VPN/travel OR stolen token)
Different SessionIds = Different authentication flows (not necessarily more suspicious)
Must correlate multiple signals: SessionId + UserAgent + Geography + Behavior + Time patterns + IP enrichment data
Real-World Example: Geographic Anomaly Analysis
Scenario: User sign-ins detected from two geographically distant locations within 18 hours.
Step 1: Interactive MFA Analysis
Location A Analysis:
Query 1: Found 2 events with SMS verification and RequestSeq: 1
Result: User performed fresh interactive SMS authentication at Location A
Evidence: authenticationStepDateTime: 2025-10-15T14:23:05Z with RequestSequence: 1
Location B Analysis:
Query 1: Zero results (no non-"Previously satisfied" methods)
Result: Location B authentications used only token reuse - NO interactive MFA
Evidence: All events show "MFA requirement satisfied by claim in the token"
Step 2: SessionId Verification (SMOKING GUN)
Query to compare sessions across both IPs:
let suspicious_ips = dynamic(["<IP_ADDRESS_1>", "<IP_ADDRESS_2>"]);
union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated between (datetime(<START_DATE>) .. datetime(<END_DATE>))
| where UserPrincipalName =~ '<UPN>'
| where IPAddress in (suspicious_ips)
| project TimeGenerated, IPAddress, Location, SessionId, UserAgent
| order by TimeGenerated asc
CRITICAL FINDING:
SessionId: <SESSION_ID_EXAMPLE>
ALL Location A authentications: Same SessionId (over time period 1)
ALL Location B authentications: Same SessionId (over time period 2)
Time gap: Varies (analyze based on context)
Geographic distance: Varies (analyze based on context)
Initial Appearance: Potential geographic anomaly requiring investigation
Further Analysis Required: Correlate SessionId with UserAgent, behavior patterns, and user confirmation
Step 3: Evidence Summary and Interpretation
Evidence Type
Finding
Observation
Interactive MFA
Location A only
User performed SMS authentication
Location B Auth Methods
"Previously satisfied" only
Token reuse (normal OAuth flow)
SessionId
Same across both locations
Session continuity maintained
Time Gap
18 hours
Within typical refresh token lifetime (24-90 days)
User Agent
Same
Consistent device fingerprint
Applications
Consistent across locations
Consistent workflow pattern
Critical Analysis - SessionId Does NOT Prove Legitimacy
The same SessionId requires careful analysis because:
SessionId is a browser session identifier that tracks authentication flows
Same SessionId = Session continuity (could be legitimate user OR stolen token)
Stolen refresh tokens maintain the original SessionId - attacker inherits session state
Same SessionId does NOT rule out token theft or credential compromise
Possible Scenarios Requiring Investigation:
Scenario
Description
Action Required
Legitimate VPN Connection
User switched VPN exit nodes (same device, different apparent location)
Requires user confirmation
Legitimate User Travel
User traveled between locations with sufficient time gap (tokens remained valid)
Requires user confirmation
Multi-Device User
User has laptop + phone active simultaneously (different IPs, concurrent activity)
Check UserAgent for mobile vs desktop - Requires user confirmation
Stolen Token Replay
Attacker obtained refresh token (SessionId stays same, may show different UserAgent)
Cannot be ruled out by SessionId alone
Mobile Carrier Routing
Carrier routes traffic through regional gateways (device in one location, exits another)
Check IP enrichment for ISP org
Additional Investigation Checklist
✅ Check UserAgent consistency across all sessions
✅ Distinguish mobile vs desktop UserAgents - Concurrent activity from different device types (e.g., Android Chrome + Windows Edge) may indicate legitimate multi-device usage, not token theft
✅ Verify geographic progression is physically possible
Temporal context (first_seen, last_seen - transient vs established pattern)
✅ Most important: Confirm with user directly
Recommendation: User Confirmation Questions
Use IP enrichment data from investigation JSON to strengthen your analysis, then confirm with user:
"Were you using a VPN on [date] around [time]?" (if is_vpn: true)
"Did you travel between [Location A] and [Location B] during this timeframe?"
"Were you using multiple devices (e.g., laptop and phone) at the same time?" (if concurrent activity with different UserAgents detected)
"Do you recognize [applications] activity during this timeframe?"
"Have you noticed any unusual device or account behavior recently?"
Only after user confirmation can you conclude VPN usage or travel is legitimate. Same SessionId + IP enrichment data together provide strong evidence, but user confirmation is still required.
Common Authentication Methods and RequestSequence Patterns
Authentication Method
RequestSeq > 0 Meaning
RequestSeq = 0 Meaning
Passkey (device-bound)
User physically approved with biometric/PIN
Passkey used in prior session, token reused
Phone sign-in
User approved notification on phone
Phone approval in prior session, token reused
SMS verification
User entered SMS code
SMS verification in prior session, token reused
Microsoft Authenticator app
User approved push notification
Authenticator used in prior session, token reused
Previously satisfied
N/A - never has RequestSeq > 0
Always indicates token/claim reuse
When to Escalate Authentication Anomalies
CRITICAL: Always check IP enrichment data before making risk determination!
High Risk (Escalate Immediately)
Token reuse from geographically impossible locations (regardless of SessionId)
Token reuse after user reports device loss/theft
Concurrent sessions from multiple countries simultaneously with same UserAgent (same device can't be in two places)
Note: Concurrent activity with different UserAgents (mobile vs desktop) may indicate legitimate multi-device usage - verify before escalating
Token reuse from IPs matching ThreatIntelIndicators OR threat_detected: true in IP enrichment
Unusual application access (admin portals, sensitive resources not in user's normal pattern)
Failed authentication attempts followed by successful token reuse
Account modifications or privilege escalations during suspicious sessions
Geographic anomaly + Same SessionId + Different UserAgent = Likely token theft
Impossible travel time between authentications (regardless of SessionId)
IP enrichment shows: abuse_confidence_score >= 75, is_tor: true, or malicious threat_description
Medium Risk (Investigate Further - Confirm with User)
Same SessionId + Geographically distant locations = Could be VPN/travel OR token theft - VERIFY with IP enrichment
Concurrent activity from different IPs with different UserAgents = Could be multi-device (laptop + phone) OR token theft - ASK user about device usage
Token reuse from unexpected country without prior user notification
Pattern of token-only authentications without any interactive MFA in 30+ days
Sign-ins during unusual hours for user's timezone
Access to sensitive data repositories during suspicious sessions
Same SessionId + Same UserAgent + Unusual geographic pattern = Needs user confirmation
IP enrichment shows: abuse_confidence_score >= 25, is_vpn: true without user confirmation, or total_reports > 0
Low Risk / Likely Legitimate (Monitor Only)
Token reuse from nearby IPs in same city (mobile carrier IP rotation)
Token reuse following confirmed interactive MFA from expected location
Token reuse from known corporate VPN IP ranges
Applications and access patterns consistent with user's role
User confirms VPN usage or travel when questioned
No unusual data access or configuration changes
Consistent UserAgent + Reasonable geographic progression + User confirmation
IP enrichment shows: abuse_confidence_score: 0, residential ISP org (TELUS, Comcast, etc.), is_vpn: false, high signin_count with consistent success rate
Best Practices for Authentication Tracing
START WITH SessionId - Query suspicious IPs to get SessionId first (most efficient approach)
Use SessionId to trace complete chain - Single query shows entire authentication progression
Check IP enrichment data - Use investigation JSON ip_enrichment array for VPN, abuse scores, threat intel
Verify device consistency - Same SessionId + Same UserAgent + Geographic reasonableness = Likely legitimate
Check for multi-device scenarios - Different UserAgents (mobile vs desktop) with concurrent activity often indicates legitimate multi-device usage, not token theft. Users commonly work on laptop while checking email on phone.
Concurrent activity ≠ Automatic compromise - Before concluding token theft from concurrent sessions, verify UserAgent differences and ask user about device usage patterns
SessionId alone is NOT conclusive - Must correlate with UserAgent, geography, behavior, and user confirmation
Check first authentication in session - RequestSeq > 0 shows where user performed interactive MFA
Assess geographic progression - Evaluate if travel is physically possible or if VPN is likely
Widen time ranges if needed - Tokens can be valid for 24-90 days depending on policy
Always confirm with user - Geographic anomalies require user verification regardless of SessionId
Prerequisites
Required MCP Servers
This skill requires:
Sentinel Triage MCP (primary, ≤30d) — RunAdvancedHuntingQuery for EntraIdSignInEvents
Microsoft Sentinel Data Lake MCP (fallback, >30d) — mcp_sentinel-data_query_lake for SigninLogs + AADNonInteractiveUserSignInLogs union
Required Data Sources
EntraIdSignInEvents (primary) — Unified interactive + non-interactive sign-in events. Advanced Hunting only, 30d retention via Graph API
SigninLogs + AADNonInteractiveUserSignInLogs (fallback) — Sentinel Data Lake, 90d+ retention. Required when tracing token origins older than 30 days or when AuthenticationDetails per-step granularity is needed
