Authentication Tracing

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

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

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

Column mapping — EntraIdSignInEvents vs SigninLogs:

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"