detecting-oauth-token-theft

Overview of detecting-oauth-token-theft skill

The detecting-oauth-token-theft skill helps you investigate and reduce OAuth token theft, replay, and session hijacking in cloud identity environments, especially Microsoft Entra ID and related M365 security workflows. It is most useful for a Security Audit, incident response, or hardening review when you need to turn sign-in evidence into a concrete detection or containment plan.

What this skill is for

Use the detecting-oauth-token-theft skill when the question is not “what is OAuth?” but “how do I prove token abuse, find the blast radius, and detect it earlier next time?” It focuses on practical indicators such as impossible travel, unfamiliar devices, repeated token use from multiple IPs, risky scopes, and sign-in anomalies.

Best-fit readers and teams

This skill is a good fit for cloud security engineers, identity defenders, SOC analysts, and auditors working in Microsoft Entra ID-heavy environments. It is especially relevant when you already have sign-in logs, conditional access policies, or identity protection telemetry and need a guided way to interpret them.

Why it stands out

Unlike a generic prompt, this detecting-oauth-token-theft skill is anchored to a workflow and detection logic, not just advice. The repo includes a script, a reference document with log fields and scope mappings, and concrete attack patterns such as access token theft, refresh token replay, Primary Refresh Token abuse, and pass-the-cookie attacks.

How to Use detecting-oauth-token-theft skill

Install and load it in your workflow

Install the detecting-oauth-token-theft skill with:

npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill detecting-oauth-token-theft

After install, start by reading SKILL.md, then references/api-reference.md, and scripts/agent.py. Those three files tell you what the skill detects, what data it expects, and how its detection logic is implemented.

Give it the right incident context

The skill works best when you provide structured input: tenant type, identity platform, alert source, time window, affected user(s), suspicious IPs, and any known token or device clues. A weak prompt says “check for OAuth theft”; a stronger one says:

“Investigate possible OAuth token theft in Microsoft Entra ID for user alice@contoso.com between 08:00 and 12:00 UTC. We saw impossible travel, a new device, and repeated sign-ins from two countries. Recommend likely abuse path, log queries, and containment steps.”

That kind of prompt gives the skill enough detail to return usable detection guidance instead of broad theory.

Read the files in this order

Start with SKILL.md for scope and prerequisites, then references/api-reference.md for log fields, sensitive scopes, and example queries. Use scripts/agent.py as the implementation clue: it shows which conditions matter most, including geo/time speed checks, device novelty, and repeated use patterns.

Practical usage tips

Feed the skill real sign-in evidence, not just an alert title. The output improves when you include timestamps, source IPs, device IDs, resource names, and sign-in status codes. If you are using the skill for Security Audit work, ask it to separate detection controls, investigation steps, and prevention controls so the result is easier to turn into a report or runbook.

detecting-oauth-token-theft skill FAQ

Is this only for Microsoft Entra ID?

No. Microsoft Entra ID is the main design center, but the detection ideas also map to other identity providers if they expose equivalent sign-in, device, and token-use telemetry. If your platform does not provide those fields, the skill is a weaker fit.

How is this different from a normal prompt?

A normal prompt may produce generic identity-security advice. The detecting-oauth-token-theft skill is better when you want a repeatable workflow that starts from logs, looks for specific replay indicators, and connects findings to conditional access or token protection decisions.

Is it beginner-friendly?

Yes, if you already know basic identity terminology. It is beginner-friendly for investigation because it points you toward the right evidence, but it is not a substitute for access to your tenant logs or a working understanding of Entra ID sign-in data.

When should I not use it?

Do not use it for Kerberos ticket abuse, domain controller compromise, or other on-premises AD attacks. Those problems need different investigation techniques and different telemetry than detecting-oauth-token-theft focuses on.

How to Improve detecting-oauth-token-theft skill

Provide higher-quality evidence

The biggest improvement comes from better input data. Include exact timestamps, tenant name, user principal names, IP addresses, device IDs, geo hints, and whether MFA or conditional access succeeded. When you can, paste a small log sample rather than summarizing it.

Ask for one output type at a time

The skill performs better when you separate goals. For example, ask first for “likely abuse hypothesis and supporting indicators,” then ask for “log queries,” then ask for “containment and prevention controls.” That keeps the detecting-oauth-token-theft guide focused and reduces vague mixed outputs.

Tune for your environment

If your organization uses Okta, hybrid identity, or multiple M365 tenants, state that up front. The underlying detection logic in references/api-reference.md and scripts/agent.py is useful, but you may need to adapt field names, log sources, and risk thresholds before the result is operational.

Iterate with the first answer

Treat the first output as a draft investigation path. If it misses a key sign-in, add more telemetry and rerun it with a narrower window or a stronger hypothesis, such as “token replay after device change” or “scope abuse after consent.” That is the fastest way to get better results from detecting-oauth-token-theft for Security Audit or incident response work.