okta-attack

⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Portão de confirmação obrigatório Antes de executar qualquer comando que sonde, explore, altere, persista em, extraia dados de ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL exato do alvo, IP, conta ou recurso.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Quando usar esta habilidade

Ativar quando:

• O DNS mostra <tenant>.okta.com ou <tenant>.okta-emea.com (região EMEA)
• O fluxo de login redireciona para <tenant>.okta.com/login ou /app/<app_id>/sso/saml
• Páginas da web referenciam /signin/customize, oktapreview.com ou auth-js-sdk
• Notas de reconhecimento "usa Okta para SSO"
• Um alvo tem *.okta.com SAN no certificado TLS
• O mapeamento de identidade-fabric retorna Okta como IdP para um aplicativo corporativo

NÃO usar para:

• Entra ID (use m365-entra-attack em vez disso)
• Google Workspace (use google-workspace-attack — ainda não construído)
• ADFS (protocolo diferente, on-premise)

Descoberta de tenant

Palpites diretos

# 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

Cruzamento de referência do 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

Cruzamento de referência do fluxo HTTP do aplicativo

# 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

Enumeração de usuários

Método 1 — Diferencial de /api/v1/authn

A API de autenticação retorna erros diferentes para usuários inválidos versus senhas inválidas. Ligeiramente diferencial.

# 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 se fortaleceu contra a enumeração direta de existência de usuário via /api/v1/authn — a mensagem de erro é tipicamente uniforme "Falha na autenticação". A enumeração de usuários por este endpoint é não confiável em 2024+.

Método 2 — Tempo de /api/v1/users/me/factors

Alguns fluxos expõem a existência do usuário através de diferencial de tempo de resposta. Menos confiável que a técnica do OneDrive do M365.

Método 3 — Endpoint JS do widget de login

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

Método 4 — Sondagem de identificador específico da organização

Algumas organizações Okta usam e-mail como nome de usuário; outras usam firstname.lastname ou employee-id. Teste padrões de palpites:

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

Método 5 — OIDC /v1/authorize com 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

Análise do fluxo de autenticação (sempre faça isso primeiro)

# Autenticação inicial — observe quais fatores retornam

…