[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEFVHE1XEE3WGJA66X617P":3,"skill-same:01M6AEFVHE1XEE3WGJA66X617P":131},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":90,"commitSha":91,"skillDirectory":92,"forksCount":93,"repositoryHtmlUrl":94,"repositoryHomepageUrl":95,"ownerHtmlUrl":96,"ownerBlogUrl":97,"ownerDescription":98,"updatedAt":99,"install":100,"resources":113},"01M6AEFVHE1XEE3WGJA66X617P","detecting-oauth-token-theft",null,"Detect and respond to OAuth token theft and replay in Microsoft Entra ID (Azure AD), covering access token theft, refresh token replay, Primary Refresh Token (PRT) abuse, pass-the-cookie attacks, and Token Protection conditional access policies. Use for impossible-travel or anomalous token-usage alerts, suspected session hijacking, sign-in log analysis, or configuring token-binding defenses in Azure\u002FM365.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-oauth-token-theft\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"detecting oauth token theft","OAuth","cloud-security","PRT","identity-security","token-replay","impossible-travel","token-theft","azure-ad","entra-id","security","browser","authentication","pr","azure","entra id","identity","microsoft","web","cybersecurity","2026-11-10 10:12:30",false,"---\nname: detecting-oauth-token-theft\ndescription: Detect and respond to OAuth token theft and replay in Microsoft Entra ID (Azure AD), covering access token theft, refresh token replay, Primary Refresh Token (PRT) abuse, pass-the-cookie attacks, and Token Protection conditional access policies. Use for impossible-travel or anomalous token-usage alerts, suspected session hijacking, sign-in log analysis, or configuring token-binding defenses in Azure\u002FM365.\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- oauth\n- token-theft\n- azure-ad\n- entra-id\n- conditional-access\n- token-replay\n- identity-security\n- PRT\nversion: 1.0.0\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.IR-01\n- ID.AM-08\n- GV.SC-06\n- DE.CM-01\nmitre_attack:\n- T1078.004\n- T1530\n- T1537\n- T1580\nmitre_f3:\n  version: '1.1'\n  tactics:\n  - initial-access\n  - positioning\n  techniques:\n  - id: F1004\n    name: Access with Stolen Session Cookie\n    tactic: initial-access\n    source: f3\n  - id: T1539\n    name: Steal Web Session Cookie\n    tactic: positioning\n    source: attack\n  - id: T1557\n    name: Adversary-in-the-Middle\n    tactic: initial-access\n    source: attack\n  - id: T1550.001\n    name: 'Use Alternate Authentication Material: Application Access Token'\n    tactic: initial-access\n    source: attack\n  - id: F1006\n    name: Account Takeover\n    tactic: initial-access\n    source: f3\n  - id: T1185\n    name: Browser Session Hijacking\n    tactic: positioning\n    source: attack\n---\n\n# Detecting OAuth Token Theft\n\n## When to Use\n\n- Investigating alerts for impossible travel or anomalous token usage in Microsoft Entra ID\n- Responding to a suspected session hijacking or pass-the-cookie attack\n- Configuring proactive defenses against OAuth token theft in an Azure\u002FM365 environment\n- Detecting OAuth device code phishing campaigns that bypass MFA\n- Analyzing sign-in logs for token replay indicators\n- Implementing Token Protection conditional access policies to bind tokens to devices\n\n**Do not use** for on-premises Kerberos ticket attacks (pass-the-ticket, golden ticket); use Active Directory-specific investigation techniques for those scenarios.\n\n## Prerequisites\n\n- Microsoft Entra ID P2 license (required for Identity Protection risk detections and conditional access)\n- Global Administrator or Security Administrator role in the Entra admin center\n- Microsoft Defender for Cloud Apps (MDCA) license for session anomaly detection\n- Access to Entra ID Sign-in Logs and Audit Logs (requires Diagnostic Settings configured to Log Analytics or Sentinel)\n- Familiarity with OAuth 2.0 authorization flows (authorization code, device code, client credentials)\n- Microsoft Sentinel or equivalent SIEM ingesting Entra ID sign-in and audit logs\n\n## Workflow\n\n### Step 1: Understand the Token Theft Attack Surface\n\nIdentify which token types are at risk and how they are stolen:\n\n```\nToken Type            | Lifetime     | Theft Vector                    | Impact\n----------------------|-------------|----------------------------------|------------------\nAccess Token          | 60-90 min   | Memory dump, proxy interception  | API access for token lifetime\nRefresh Token         | Up to 90 days| Browser cookie theft, malware   | Persistent access, new access tokens\nPrimary Refresh Token | Session-based| Mimikatz, AADInternals, malware | Full SSO to all M365\u002FAzure apps\nSession Cookie        | Varies      | XSS, browser exploit, AitM proxy | Full session hijacking\nDevice Code Token     | 15 min auth | Phishing (device code flow abuse)| Attacker gets refresh token via social engineering\n```\n\nCommon attack techniques:\n- **AitM Phishing (Adversary-in-the-Middle)**: Attacker proxies the legitimate login page via tools like Evilginx2, capturing session cookies and tokens after the user completes MFA\n- **Device Code Phishing**: Attacker generates a device code, sends it to the victim via email\u002FTeams, victim authenticates, attacker receives the token\n- **PRT Extraction**: Attacker with local admin on a device extracts the Primary Refresh Token using Mimikatz (`sekurlsa::cloudap`) or AADInternals\n- **Browser Cookie Theft**: Malware or infostealer exfiltrates browser cookies containing session tokens\n\n### Step 2: Configure Entra ID Sign-in Risk Detection\n\nEnable Identity Protection to flag anomalous token usage:\n\n```\nEntra Admin Center > Protection > Identity Protection > Risk Detections\n\nKey risk detections for token theft:\n- Anomalous Token        : Token has unusual characteristics (claim anomalies)\n- Token Issuer Anomaly   : Token issued by an unusual token issuer\n- Unfamiliar Sign-in     : Sign-in from a location not seen before for the user\n- Impossible Travel      : Sign-ins from geographically distant locations in impossible time\n- Malicious IP Address   : Sign-in from a known malicious IP\n- Suspicious Browser     : Sign-in from a suspicious or attacker-controlled browser\n```\n\nConfigure risk-based conditional access:\n\n```\nEntra Admin Center > Protection > Conditional Access > New Policy\n\nPolicy Name: \"Block High-Risk Sign-ins - Token Theft Protection\"\nAssignments:\n  Users: All users (exclude break-glass accounts)\n  Cloud Apps: All cloud apps\nConditions:\n  Sign-in Risk: High\nGrant:\n  Block access\n\nPolicy Name: \"Require MFA for Medium-Risk Sign-ins\"\nAssignments:\n  Users: All users\n  Cloud Apps: All cloud apps\nConditions:\n  Sign-in Risk: Medium\nGrant:\n  Require multifactor authentication\n  Require password change\n```\n\n### Step 3: Enable Token Protection (Preview)\n\nConfigure Token Protection to bind sign-in session tokens to the device:\n\n```\nEntra Admin Center > Protection > Conditional Access > New Policy\n\nPolicy Name: \"Enforce Token Protection for Desktop Sessions\"\nAssignments:\n  Users: All users (start with a pilot group)\n  Cloud Apps: Office 365 Exchange Online, Office 365 SharePoint Online\n  Conditions:\n    Device Platforms: Windows\nSession:\n  Require token protection for sign-in sessions (Preview): Enabled\nGrant:\n  Require device to be marked as compliant\n  OR Require Hybrid Azure AD joined device\n```\n\nToken Protection ensures that access tokens are cryptographically bound to the device's Trusted Platform Module (TPM). If an attacker steals a token and replays it from a different device, the token is rejected because the proof-of-possession key does not match.\n\n### Step 4: Detect Token Replay in Sign-in Logs\n\nQuery Entra sign-in logs for indicators of token theft:\n\n```kusto\n\u002F\u002F KQL query for Microsoft Sentinel or Log Analytics\n\u002F\u002F Detect sign-ins where the token was issued in one location and used in another\nSigninLogs\n| where TimeGenerated > ago(7d)\n| where RiskDetail contains \"token\" or RiskEventTypes_V2 has \"anomalousToken\"\n| project TimeGenerated, UserPrincipalName, IPAddress, Location,\n          RiskDetail, RiskLevelDuringSignIn, AppDisplayName,\n          DeviceDetail, ClientAppUsed, TokenIssuerType\n| sort by TimeGenerated desc\n\n\u002F\u002F Detect impossible travel with token reuse\nSigninLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == 0  \u002F\u002F Successful sign-ins only\n| summarize Locations=make_set(Location), IPs=make_set(IPAddress),\n            Count=count() by UserPrincipalName, bin(TimeGenerated, 1h)\n| where array_length(Locations) > 1\n| sort by TimeGenerated desc\n\n\u002F\u002F Detect device code flow abuse (often used in phishing)\nSigninLogs\n| where TimeGenerated > ago(7d)\n| where AuthenticationProtocol == \"deviceCode\"\n| project TimeGenerated, UserPrincipalName, IPAddress, Location,\n          AppDisplayName, DeviceDetail, ResultType\n| sort by TimeGenerated desc\n\n\u002F\u002F Detect token replay: same token used from multiple IPs\nAADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == 0\n| summarize IPs=make_set(IPAddress), IPCount=dcount(IPAddress)\n            by UserPrincipalName, CorrelationId\n| where IPCount > 1\n| sort by IPCount desc\n```\n\n### Step 5: Investigate and Respond to Token Theft\n\nWhen a token theft event is detected, follow this response procedure:\n\n```powershell\n# Step 5a: Revoke all refresh tokens for the compromised user\n# Microsoft Graph PowerShell\nConnect-MgGraph -Scopes \"User.ReadWrite.All\"\nRevoke-MgUserSignInSession -UserId \"user@contoso.com\"\n\n# Step 5b: Force password reset\nUpdate-MgUser -UserId \"user@contoso.com\" -PasswordProfile @{\n    ForceChangePasswordNextSignIn = $true\n}\n\n# Step 5c: Review and revoke OAuth app consent grants\n# Check for malicious app consent (common post-compromise persistence)\nGet-MgUserOauth2PermissionGrant -UserId \"user@contoso.com\" |\n    Select-Object ClientId, ConsentType, Scope\n\n# Remove suspicious OAuth grants\nRemove-MgOauth2PermissionGrant -OAuth2PermissionGrantId \"\u003Cgrant-id>\"\n\n# Step 5d: Review enterprise app registrations for rogue apps\nGet-MgServicePrincipal -Filter \"displayName eq 'Suspicious App'\" |\n    Select-Object AppId, DisplayName, SignInAudience\n\n# Step 5e: Check for mail forwarding rules (common post-compromise action)\nGet-MgUserMailFolderRule -UserId \"user@contoso.com\" -MailFolderId \"Inbox\" |\n    Where-Object { $_.Actions.ForwardTo -ne $null -or $_.Actions.RedirectTo -ne $null }\n```\n\n### Step 6: Implement Continuous Access Evaluation (CAE)\n\nEnable CAE to revoke tokens in near-real-time when conditions change:\n\n```\nEntra Admin Center > Protection > Conditional Access > Continuous Access Evaluation\n\nSettings:\n  Strictly enforce location policies: Enabled\n\nCAE ensures that when you revoke a user's session or change their\nrisk level, the enforcement happens within minutes rather than waiting\nfor the access token to naturally expire (60-90 minutes).\n\nCritical events that trigger immediate token revocation with CAE:\n- User account disabled or deleted\n- Password changed or reset\n- MFA enabled for the user\n- Admin explicitly revokes refresh tokens\n- Azure AD Identity Protection detects elevated user risk\n- Network location change violates conditional access policy\n```\n\n### Step 7: Configure Defender for Cloud Apps Session Policies\n\nSet up real-time session monitoring to detect and block suspicious token usage:\n\n```\nMicrosoft Defender for Cloud Apps > Policies > Session Policies\n\nPolicy: \"Block download from unmanaged device with stolen token\"\n  Session Control Type: Monitor and block activities\n  Activity Source: App = Office 365, SharePoint Online\n  Activity Filter: Device tag does not equal \"Compliant\"\n  Activity Type: Download\n  Action: Block\n\nPolicy: \"Alert on mass file download (exfiltration via stolen token)\"\n  Session Control Type: Monitor only\n  Activity Source: App = Office 365\n  Activity Filter: Repeated activity > 10 downloads in 5 minutes\n  Action: Alert administrators\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Primary Refresh Token (PRT)** | A long-lived token issued to a registered device that provides SSO to all Azure AD-integrated applications, cryptographically bound to the device's TPM |\n| **Token Protection** | Entra ID conditional access feature that binds sign-in session tokens to the device, preventing replay from other devices |\n| **Continuous Access Evaluation (CAE)** | Protocol that enables near-real-time enforcement of security policies by allowing resource providers to subscribe to Entra ID critical events |\n| **AitM (Adversary-in-the-Middle)** | Phishing technique where an attacker proxies the legitimate authentication flow to capture session cookies after the victim completes MFA |\n| **Device Code Flow** | OAuth 2.0 authorization grant for input-constrained devices; abused by attackers who send device codes to victims via phishing |\n| **Proof of Possession (PoP)** | Cryptographic mechanism where a token includes a claim tied to a device key, ensuring the token can only be used by the device that obtained it |\n| **Refresh Token** | Long-lived OAuth token (up to 90 days) used to obtain new access tokens without re-authentication; primary target for persistent access |\n\n## Verification\n\n- [ ] Identity Protection risk detections are enabled and generating alerts for anomalous token activity\n- [ ] Conditional access policies block high-risk sign-ins and require MFA for medium-risk\n- [ ] Token Protection policy is applied to pilot group and confirmed working (test from unregistered device fails)\n- [ ] KQL queries in Sentinel return results when tested against synthetic token anomaly events\n- [ ] Continuous Access Evaluation is enabled and verified (revoke session, confirm access blocked within minutes)\n- [ ] Defender for Cloud Apps session policies are active and monitoring download activity\n- [ ] Device code flow is restricted via conditional access (block or require compliant device)\n- [ ] Incident response runbook includes token revocation, password reset, and OAuth consent review steps\n- [ ] Mail forwarding rules and OAuth app grants are audited for compromised accounts\n","# Detecting OAuth Token Theft\n\n## When to Use\n\n- Investigating alerts for impossible travel or anomalous token usage in Microsoft Entra ID\n- Responding to a suspected session hijacking or pass-the-cookie attack\n- Configuring proactive defenses against OAuth token theft in an Azure\u002FM365 environment\n- Detecting OAuth device code phishing campaigns that bypass MFA\n- Analyzing sign-in logs for token replay indicators\n- Implementing Token Protection conditional access policies to bind tokens to devices\n\n**Do not use** for on-premises Kerberos ticket attacks (pass-the-ticket, golden ticket); use Active Directory-specific investigation techniques for those scenarios.\n\n## Prerequisites\n\n- Microsoft Entra ID P2 license (required for Identity Protection risk detections and conditional access)\n- Global Administrator or Security Administrator role in the Entra admin center\n- Microsoft Defender for Cloud Apps (MDCA) license for session anomaly detection\n- Access to Entra ID Sign-in Logs and Audit Logs (requires Diagnostic Settings configured to Log Analytics or Sentinel)\n- Familiarity with OAuth 2.0 authorization flows (authorization code, device code, client credentials)\n- Microsoft Sentinel or equivalent SIEM ingesting Entra ID sign-in and audit logs\n\n## Workflow\n\n### Step 1: Understand the Token Theft Attack Surface\n\nIdentify which token types are at risk and how they are stolen:\n\n```\nToken Type            | Lifetime     | Theft Vector                    | Impact\n----------------------|-------------|----------------------------------|------------------\nAccess Token          | 60-90 min   | Memory dump, proxy interception  | API access for token lifetime\nRefresh Token         | Up to 90 days| Browser cookie theft, malware   | Persistent access, new access tokens\nPrimary Refresh Token | Session-based| Mimikatz, AADInternals, malware | Full SSO to all M365\u002FAzure apps\nSession Cookie        | Varies      | XSS, browser exploit, AitM proxy | Full session hijacking\nDevice Code Token     | 15 min auth | Phishing (device code flow abuse)| Attacker gets refresh token via social engineering\n```\n\nCommon attack techniques:\n- **AitM Phishing (Adversary-in-the-Middle)**: Attacker proxies the legitimate login page via tools like Evilginx2, capturing session cookies and tokens after the user completes MFA\n- **Device Code Phishing**: Attacker generates a device code, sends it to the victim via email\u002FTeams, victim authenticates, attacker receives the token\n- **PRT Extraction**: Attacker with local admin on a device extracts the Primary Refresh Token using Mimikatz (`sekurlsa::cloudap`) or AADInternals\n- **Browser Cookie Theft**: Malware or infostealer exfiltrates browser cookies containing session tokens\n\n### Step 2: Configure Entra ID Sign-in Risk Detection\n\nEnable Identity Protection to flag anomalous token usage:\n\n```\nEntra Admin Center > Protection > Identity Protection > Risk Detections\n\nKey risk detections for token theft:\n- Anomalous Token        : Token has unusual characteristics (claim anomalies)\n- Token Issuer Anomaly   : Token issued by an unusual token issuer\n- Unfamiliar Sign-in     : Sign-in from a location not seen before for the user\n- Impossible Travel      : Sign-ins from geographically distant locations in impossible time\n- Malicious IP Address   : Sign-in from a known malicious IP\n- Suspicious Browser     : Sign-in from a suspicious or attacker-controlled browser\n```\n\nConfigure risk-based conditional access:\n\n```\nEntra Admin Center > Protection > Conditional Access > New Policy\n\nPolicy Name: \"Block High-Risk Sign-ins - Token Theft Protection\"\nAssignments:\n  Users: All users (exclude break-glass accounts)\n  Cloud Apps: All cloud apps\nConditions:\n  Sign-in Risk: High\nGrant:\n  Block access\n\nPolicy Name: \"Require MFA for Medium-Risk Sign-ins\"\nAssignments:\n  Users: All users\n  Cloud Apps: All cloud apps\nConditions:\n  Sign-in Risk: Medium\nGrant:\n  Require multifactor authentication\n  Require password change\n```\n\n### Step 3: Enable Token Protection (Preview)\n\nConfigure Token Protection to bind sign-in session tokens to the device:\n\n```\nEntra Admin Center > Protection > Conditional Access > New Policy\n\nPolicy Name: \"Enforce Token Protection for Desktop Sessions\"\nAssignments:\n  Users: All users (start with a pilot group)\n  Cloud Apps: Office 365 Exchange Online, Office 365 SharePoint Online\n  Conditions:\n    Device Platforms: Windows\nSession:\n  Require token protection for sign-in sessions (Preview): Enabled\nGrant:\n  Require device to be marked as compliant\n  OR Require Hybrid Azure AD joined device\n```\n\nToken Protection ensures that access tokens are cryptographically bound to the device's Trusted Platform Module (TPM). If an attacker steals a token and replays it from a different device, the token is rejected because the proof-of-possession key does not match.\n\n### Step 4: Detect Token Replay in Sign-in Logs\n\nQuery Entra sign-in logs for indicators of token theft:\n\n```kusto\n\u002F\u002F KQL query for Microsoft Sentinel or Log Analytics\n\u002F\u002F Detect sign-ins where the token was issued in one location and used in another\nSigninLogs\n| where TimeGenerated > ago(7d)\n| where RiskDetail contains \"token\" or RiskEventTypes_V2 has \"anomalousToken\"\n| project TimeGenerated, UserPrincipalName, IPAddress, Location,\n          RiskDetail, RiskLevelDuringSignIn, AppDisplayName,\n          DeviceDetail, ClientAppUsed, TokenIssuerType\n| sort by TimeGenerated desc\n\n\u002F\u002F Detect impossible travel with token reuse\nSigninLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == 0  \u002F\u002F Successful sign-ins only\n| summarize Locations=make_set(Location), IPs=make_set(IPAddress),\n            Count=count() by UserPrincipalName, bin(TimeGenerated, 1h)\n| where array_length(Locations) > 1\n| sort by TimeGenerated desc\n\n\u002F\u002F Detect device code flow abuse (often used in phishing)\nSigninLogs\n| where TimeGenerated > ago(7d)\n| where AuthenticationProtocol == \"deviceCode\"\n| project TimeGenerated, UserPrincipalName, IPAddress, Location,\n          AppDisplayName, DeviceDetail, ResultType\n| sort by TimeGenerated desc\n\n\u002F\u002F Detect token replay: same token used from multiple IPs\nAADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == 0\n| summarize IPs=make_set(IPAddress), IPCount=dcount(IPAddress)\n            by UserPrincipalName, CorrelationId\n| where IPCount > 1\n| sort by IPCount desc\n```\n\n### Step 5: Investigate and Respond to Token Theft\n\nWhen a token theft event is detected, follow this response procedure:\n\n```powershell\n# Step 5a: Revoke all refresh tokens for the compromised user\n# Microsoft Graph PowerShell\nConnect-MgGraph -Scopes \"User.ReadWrite.All\"\nRevoke-MgUserSignInSession -UserId \"user@contoso.com\"\n\n# Step 5b: Force password reset\nUpdate-MgUser -UserId \"user@contoso.com\" -PasswordProfile @{\n    ForceChangePasswordNextSignIn = $true\n}\n\n# Step 5c: Review and revoke OAuth app consent grants\n# Check for malicious app consent (common post-compromise persistence)\nGet-MgUserOauth2PermissionGrant -UserId \"user@contoso.com\" |\n    Select-Object ClientId, ConsentType, Scope\n\n# Remove suspicious OAuth grants\nRemove-MgOauth2PermissionGrant -OAuth2PermissionGrantId \"\u003Cgrant-id>\"\n\n# Step 5d: Review enterprise app registrations for rogue apps\nGet-MgServicePrincipal -Filter \"displayName eq 'Suspicious App'\" |\n    Select-Object AppId, DisplayName, SignInAudience\n\n# Step 5e: Check for mail forwarding rules (common post-compromise action)\nGet-MgUserMailFolderRule -UserId \"user@contoso.com\" -MailFolderId \"Inbox\" |\n    Where-Object { $_.Actions.ForwardTo -ne $null -or $_.Actions.RedirectTo -ne $null }\n```\n\n### Step 6: Implement Continuous Access Evaluation (CAE)\n\nEnable CAE to revoke tokens in near-real-time when conditions change:\n\n```\nEntra Admin Center > Protection > Conditional Access > Continuous Access Evaluation\n\nSettings:\n  Strictly enforce location policies: Enabled\n\nCAE ensures that when you revoke a user's session or change their\nrisk level, the enforcement happens within minutes rather than waiting\nfor the access token to naturally expire (60-90 minutes).\n\nCritical events that trigger immediate token revocation with CAE:\n- User account disabled or deleted\n- Password changed or reset\n- MFA enabled for the user\n- Admin explicitly revokes refresh tokens\n- Azure AD Identity Protection detects elevated user risk\n- Network location change violates conditional access policy\n```\n\n### Step 7: Configure Defender for Cloud Apps Session Policies\n\nSet up real-time session monitoring to detect and block suspicious token usage:\n\n```\nMicrosoft Defender for Cloud Apps > Policies > Session Policies\n\nPolicy: \"Block download from unmanaged device with stolen token\"\n  Session Control Type: Monitor and block activities\n  Activity Source: App = Office 365, SharePoint Online\n  Activity Filter: Device tag does not equal \"Compliant\"\n  Activity Type: Download\n  Action: Block\n\nPolicy: \"Alert on mass file download (exfiltration via stolen token)\"\n  Session Control Type: Monitor only\n  Activity Source: App = Office 365\n  Activity Filter: Repeated activity > 10 downloads in 5 minutes\n  Action: Alert administrators\n```\n\n## Key Concepts\n\n| Term | Definition |\n|------|------------|\n| **Primary Refresh Token (PRT)** | A long-lived token issued to a registered device that provides SSO to all Azure AD-integrated applications, cryptographically bound to the device's TPM |\n| **Token Protection** | Entra ID conditional access feature that binds sign-in session tokens to the device, preventing replay from other devices |\n| **Continuous Access Evaluation (CAE)** | Protocol that enables near-real-time enforcement of security policies by allowing resource providers to subscribe to Entra ID critical events |\n| **AitM (Adversary-in-the-Middle)** | Phishing technique where an attacker proxies the legitimate authentication flow to capture session cookies after the victim completes MFA |\n| **Device Code Flow** | OAuth 2.0 authorization grant for input-constrained devices; abused by attackers who send device codes to victims via phishing |\n| **Proof of Possession (PoP)** | Cryptographic mechanism where a token includes a claim tied to a device key, ensuring the token can only be used by the device that obtained it |\n| **Refresh Token** | Long-lived OAuth token (up to 90 days) used to obtain new access tokens without re-authentication; primary target for persistent access |\n\n## Verification\n\n- [ ] Identity Protection risk detections are enabled and generating alerts for anomalous token activity\n- [ ] Conditional access policies block high-risk sign-ins and require MFA for medium-risk\n- [ ] Token Protection policy is applied to pilot group and confirmed working (test from unregistered device fails)\n- [ ] KQL queries in Sentinel return results when tested against synthetic token anomaly events\n- [ ] Continuous Access Evaluation is enabled and verified (revoke session, confirm access blocked within minutes)\n- [ ] Defender for Cloud Apps session policies are active and monitoring download activity\n- [ ] Device code flow is restricted via conditional access (block or require compliant device)\n- [ ] Incident response runbook includes token revocation, password reset, and OAuth consent review steps\n- [ ] Mail forwarding rules and OAuth app grants are audited for compromised accounts\n",{"name":5,"tags":49,"author":52,"domain":43,"license":15,"version":53,"mitre_f3":54,"nist_csf":80,"subdomain":26,"description":7,"mitre_attack":85},[50,31,32,33,51,29,28,27],"oauth","conditional-access","mahipal","1.0.0",{"tactics":55,"version":58,"techniques":59},[56,57],"initial-access","positioning","1.1",[60,64,68,71,74,77],{"id":61,"name":62,"source":63,"tactic":56},"F1004","Access with Stolen Session Cookie","f3",{"id":65,"name":66,"source":67,"tactic":57},"T1539","Steal Web Session Cookie","attack",{"id":69,"name":70,"source":67,"tactic":56},"T1557","Adversary-in-the-Middle",{"id":72,"name":73,"source":67,"tactic":56},"T1550.001","Use Alternate Authentication Material: Application Access Token",{"id":75,"name":76,"source":63,"tactic":56},"F1006","Account Takeover",{"id":78,"name":79,"source":67,"tactic":57},"T1185","Browser Session Hijacking",[81,82,83,84],"PR.IR-01","ID.AM-08","GV.SC-06","DE.CM-01",[86,87,88,89],"T1078.004","T1530","T1537","T1580","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fdetecting-oauth-token-theft",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":101,"prompt":111,"zipAvailable":112},[102,105,108],{"tool":103,"command":104},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-oauth-token-theft",{"tool":106,"command":107},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-oauth-token-theft",{"tool":109,"command":110},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill detecting-oauth-token-theft","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-oauth-token-theft\u002FSKILL.md",true,[114,119,125],{"path":115,"resourceType":115,"resourceTypeDesc":116,"sizeBytes":117,"sourceHtmlUrl":118},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-oauth-token-theft\u002FLICENSE",{"path":120,"resourceType":121,"resourceTypeDesc":122,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fapi-reference.md","REFERENCE","参考文档",1629,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-oauth-token-theft\u002Freferences\u002Fapi-reference.md",{"path":126,"resourceType":127,"resourceTypeDesc":128,"sizeBytes":129,"sourceHtmlUrl":130},"scripts\u002Fagent.py","SCRIPT","脚本",7214,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdetecting-oauth-token-theft\u002Fscripts\u002Fagent.py",[132,156,180,208,233,260],{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":44},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[138],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[140,141,142,143,34,43,144,40,37,145,146,147,148,149,150,151,152,153,154,155],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":163,"publishedAt":44},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[162],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[164,152,165,166,34,167,43,37,168,169,170,171,172,173,174,175,176,177,178,179],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":190,"publishedAt":44},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[186,189],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[174,191,192,193,194,43,195,196,168,197,198,199,200,201,202,203,204,205,206,207],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":215,"publishedAt":44},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[214],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[216,217,218,43,219,35,220,221,222,223,224,225,226,227,228,229,171,230,231,232],"windows","kape","triaging windows with kape","registry","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":240,"publishedAt":44},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[239],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[241,242,243,43,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":261,"name":262,"nameZh":6,"description":263,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":264,"categories":265,"keywords":267,"publishedAt":44},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[266],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[34,268,43,269,270,271,272,273,274,275,276,203,277,204,278,279,280,281,282,283],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]