Authentication Tracing - Instructions

Purpose

This skill performs forensic analysis of Entra ID authentication flows to determine whether anomalous sign-ins represent:

• Legitimate activity (VPN usage, user travel, mobile carrier routing)
• Token theft/credential compromise (stolen refresh tokens, session hijacking)

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.

---

📑 TABLE OF CONTENTS

1. Critical Workflow Rules - Start here!
2. Key Forensic Indicators - Understanding authentication signals
3. IP Enrichment Data - JSON structure reference
4. 6-Step Forensic Workflow - SessionId-based investigation
5. Real-World Example - Complete walkthrough
6. Authentication Methods Reference - Method patterns
7. Risk Escalation Criteria - High/Medium/Low classification
8. Best Practices - Summary checklist

---

⚠️ CRITICAL WORKFLOW RULES - READ FIRST ⚠️

🚨 MANDATORY CHECKPOINT: Before providing ANY risk assessment for authentication anomalies:

1. STOP - Do not improvise or use general security knowledge
2. READ the complete risk assessment framework in this document
3. QUOTE specific instruction sections in your analysis
4. VERIFY your conclusions match documented guidance before responding to user

Before executing ANY authentication tracing queries, you MUST:

1. Read the SessionId-based workflow (Steps 1-6 below) in full
2. Search the investigation JSON for IP enrichment data (ip_enrichment array) - PRIMARY DATA SOURCE
3. Follow the documented steps in order (SessionId → Authentication chain → Interactive MFA → Risk assessment)
4. 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.

RequestSequence Field

Value	Meaning	Implication
RequestSequence: 1 or higher	Interactive authentication	User was challenged and responded
RequestSequence: 0	Token-based authentication	No user interaction required

AuthenticationDetails Array Patterns

Interactive Pattern:

• Array contains authentication method (e.g., "Passkey (device-bound)") with RequestSequence > 0
• Followed by "Previously satisfied" entry

Token Reuse Pattern:

• 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)
is_proxy	Definitive proxy detection	is_proxy: true → Confirmed proxy (anonymized traffic)
is_tor	Definitive Tor detection	is_tor: true → Confirmed Tor exit node (high anonymity risk)
abuse_confidence_score	AbuseIPDB reputation (0-100)	>= 75 = High risk, >= 25 = Medium risk, 0 = Clean
threat_detected	Threat intel match flag	true → IP matches ThreatIntelIndicators table
threat_description	Threat intel details	"Surfshark VPN", "Malicious activity detected", etc.
org / asn	Network ownership	AS9009 = M247 Europe (VPN infrastructure provider)
signin_count	Total sign-ins from IP	High count (>100) = established pattern vs transient
last_auth_result_detail	Authentication method	"MFA satisfied by token" vs "Correct password" = interactive vs token reuse
first_seen / last_seen	Temporal pattern	Single day = transient, multi-day = established behavior

Analysis Priority Hierarchy

1. IP enrichment flags (is_vpn, is_proxy, is_tor) - Most authoritative source
2. Abuse reputation (abuse_confidence_score, total_reports) - Community-validated risk data
3. Threat intelligence (threat_detected, threat_description) - IOC matches from Sentinel
4. Network ownership (org, asn, company_type) - Infrastructure context (hosting, ISP, etc.)
5. Authentication patterns (last_auth_result_detail, signin_count) - Behavioral context
6. Identity Protection (risk detections) - Microsoft ML-based risk signals

⚠️ NEVER say "likely VPN" or "probably proxy" if enrichment data has explicit boolean flags!

---

Forensic Workflow: Tracing Authentication Chains

Scenario: Anomalous sign-ins detected from new IP/location. Determine if user performed fresh MFA or reused token.

Tool Selection: AH-First, Data Lake Fallback

Lookback	Tool	Table	Why
≤ 30 days (default)	RunAdvancedHuntingQuery	EntraIdSignInEvents	Single table covers interactive + non-interactive. No union needed. Direct columns for Country, City, Browser, UserAgent. Free on Analytics tier.
> 30 days	mcp_sentinel-data_query_lake	union SigninLogs, AADNonInteractiveUserSignInLogs	AH Graph API caps at 30d. Data Lake retains 90d+. See Data Lake Fallback Queries below.

Column mapping — EntraIdSignInEvents vs SigninLogs:

EntraIdSignInEvents (AH)	SigninLogs (Data Lake)	Notes
Timestamp	TimeGenerated
AccountUpn	UserPrincipalName
Application	AppDisplayName
ErrorCode (int)	ResultType (string)	AH: ErrorCode == 0, DL: ResultType == "0"
Country, City (direct strings)	Location or parse_json(LocationDetails)	No parsing needed in AH
LogonType (JSON array)	Separate tables (SigninLogs vs AADNonInteractive)	AH: has "interactiveUser", DL: check which table
AuthenticationRequirement	AuthenticationRequirement	Same values: singleFactorAuthentication, multiFactorAuthentication
UserAgent, Browser, OSPlatform	parse_json(DeviceDetail)	Direct columns in AH
UniqueTokenId	(not available)	AH-only — token-level forensics
SessionId	SessionId	Same
(not available)	AuthenticationDetails (JSON array)	DL-only — per-step RequestSequence + authenticationMethod

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:

1. Query suspicious IP(s) to get SessionId (single query for all suspicious IPs)
2. Query SessionId for complete chain — interactive vs non-interactive classification, geographic progression, token tracking
3. 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:

1. Look at FIRST authentication in session (earliest Timestamp)
2. Check if LogonType has "interactiveUser" → User performed interactive authentication at that IP/location
3. Check AuthenticationRequirement → multiFactorAuthentication = MFA was required and satisfied; singleFactorAuthentication = password-only
4. Subsequent events with LogonType has "nonInteractiveUser" = token reuse (expected OAuth flow)
5. Verify device consistency (Browser + UserAgent should match across session; different = possible token theft)
6. Assess geographic progression (impossible travel = high risk; reasonable = needs user confirmation)
7. 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:

1. From Interactive MFA session (Step 3 results)
2. From Suspicious session (Step 1 results)
3. 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:

1. Locate IP in ip_enrichment array (search by "ip": "<IP_ADDRESS>" field)

2. Extract key risk indicators:

   • is_vpn, is_proxy, is_tor (anonymization detection)
   • abuse_confidence_score, total_reports (reputation)
   • threat_description, threat_detected (threat intel matches)
   • org, asn (network ownership - hosting vs ISP)
   • last_auth_result_detail (authentication pattern)
   • signin_count, success_count, failure_count (frequency/behavior)
   • first_seen, last_seen (temporal pattern - transient vs established)

3. Document findings for EACH IP in the chain:

   • Geographic location + ISP/VPN status
   • Risk level + threat intelligence status
   • Authentication pattern (interactive vs token reuse)
   • Behavioral context (frequency, success rate, temporal pattern)

This creates a complete evidence picture showing the full authentication journey with enrichment context.

---

Step 6: Document Risk Assessment

⚠️ MANDATORY CHECKPOINT - Before writing risk assessment:

• READ the "When to Escalate Authentication Anomalies" section below
• IDENTIFY which risk classification criteria applies to your case
• QUOTE the specific criteria in your analysis
• DO NOT improvise - follow documented classification exactly

Present findings in clear evidence trail:

1. Interactive Session: IP, Location, Timestamp, AuthMethod, SessionId
2. Subsequent Session: IP, Location, Timestamp, AuthMethod (token-based), SessionId
3. 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)
4. Connection Proof: SessionId match + time gap + geographic distance + comprehensive enrichment context from all IPs
5. Risk Assessment: Evaluate based on context - MUST quote specific instruction criteria

Risk Assessment Framework - SessionId Interpretation:

• 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:

1. Query 1: Found 2 events with SMS verification and RequestSeq: 1
2. Result: User performed fresh interactive SMS authentication at Location A
3. Evidence: authenticationStepDateTime: 2025-10-15T14:23:05Z with RequestSequence: 1

Location B Analysis:

1. Query 1: Zero results (no non-"Previously satisfied" methods)
2. Result: Location B authentications used only token reuse - NO interactive MFA
3. 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
• ✅ Review applications accessed (any unusual admin tools?)
• ✅ Check for failed authentication attempts before success
• ✅ Look for account modifications or privilege changes
• ✅ Check IP enrichment data in investigation JSON - Use ip_enrichment array to verify:
  • VPN/proxy/Tor status (is_vpn, is_proxy, is_tor)
  • Abuse reputation (abuse_confidence_score, total_reports)
  • Threat intelligence matches (threat_detected, threat_description)
  • Authentication patterns (last_auth_result_detail, signin_count, success_count, failure_count)
  • 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:

1. "Were you using a VPN on [date] around [time]?" (if is_vpn: true)
2. "Did you travel between [Location A] and [Location B] during this timeframe?"
3. "Were you using multiple devices (e.g., laptop and phone) at the same time?" (if concurrent activity with different UserAgents detected)
4. "Do you recognize [applications] activity during this timeframe?"
5. "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
• Token reuse spanning >30 days (excessive token lifetime - increases theft window)
• 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

1. START WITH SessionId - Query suspicious IPs to get SessionId first (most efficient approach)
2. Use SessionId to trace complete chain - Single query shows entire authentication progression
3. Check IP enrichment data - Use investigation JSON ip_enrichment array for VPN, abuse scores, threat intel
4. Verify device consistency - Same SessionId + Same UserAgent + Geographic reasonableness = Likely legitimate
5. 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.
6. Concurrent activity ≠ Automatic compromise - Before concluding token theft from concurrent sessions, verify UserAgent differences and ask user about device usage patterns
7. SessionId alone is NOT conclusive - Must correlate with UserAgent, geography, behavior, and user confirmation
8. Check first authentication in session - RequestSeq > 0 shows where user performed interactive MFA
9. Assess geographic progression - Evaluate if travel is physically possible or if VPN is likely
10. Widen time ranges if needed - Tokens can be valid for 24-90 days depending on policy
11. Always confirm with user - Geographic anomalies require user verification regardless of SessionId

---

Prerequisites

Required MCP Servers

This skill requires:

1. Sentinel Triage MCP (primary, ≤30d) — RunAdvancedHuntingQuery for EntraIdSignInEvents
2. 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
• Investigation JSON - Pre-generated investigation file with ip_enrichment array (from user-investigation skill)

How to Find Investigation JSON

• Pattern: temp/investigation_<upn_prefix>_<timestamp>.json
• Most recent file for user is usually the one to analyze
• Use file_search or list_dir to locate existing investigations

---

Integration with User Investigation Skill

Authentication tracing is typically performed as a follow-up analysis after running a user investigation:

1. Run user-investigation skill → Generates investigation JSON with ip_enrichment array
2. Review anomalies → Identify suspicious IPs/locations requiring deeper analysis
3. Run authentication-tracing skill → Trace SessionId chains, correlate with IP enrichment
4. Document findings → Provide risk assessment with evidence trail

Key Integration Points:

• IP enrichment data comes from investigation JSON (already queried by user-investigation)
• SessionId queries are NEW queries specific to authentication tracing
• Risk assessment combines both data sources