⌘K
ENES
GitHub
playbookPlaybooks de Seguridad~1 min de lecturaActualizado Apr 23, 2026

Break JWT Validation

Objetivo

Identificar si el manejo de JWT es lo suficientemente débil como para aceptar tokens inválidos, viejos, mal scopeados o influenciados por un atacante.

Supuestos

  • la app usa JWTs para auth o estado tipo sesión
  • la lógica de validación puede ser inconsistente entre servicios
  • los developers pueden confundir presencia del token con autorización válida

Prerrequisitos

  • tokens de muestra de flujos autenticados
  • capacidad de replay de requests
  • comprensión básica de la estructura JWT

Pasos de recon

  1. Determiná dónde se emiten y consumen los tokens.
  2. Mapeá claims que parecen influir en la autorización.
  3. Identificá si múltiples servicios validan el mismo token de forma diferente.

Pasos de exploit / testing

  1. Reproducí tokens expirados o viejos.
  2. Eliminá o alterá claims no críticos para observar qué tan estricta es la validación.
  3. Probá si audience, issuer o scope checks parecen aplicarse.
  4. Compará comportamiento entre entradas web, mobile y API.
  5. Verificá si logout o cambios de privilegio realmente revocan la utilidad del token.

Señales de validación

  • tokens expirados siguen funcionando
  • claims cambiados o faltantes son aceptados
  • servicios distintos aceptan estados distintos del token
  • las decisiones de autorización dependen de claims débiles o stale

Mitigación

  • validar firma, issuer, audience, expiry y claims relevantes de forma consistente
  • separar authentication de authorization checks
  • minimizar lifetime y scope del token
  • diseñar estrategias explícitas de revocación cuando haga falta

Logging / detección

  • uso repetido de tokens expirados
  • anomalías de claims en tokens
  • decisiones auth inconsistentes entre servicios para el mismo subject

Notas relacionadas

Referencias

  • Fundamental: OWASP Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
  • Testing / Lab: PortSwigger Web Security Academy — https://portswigger.net/web-security
  • Fundamental: OWASP WSTG — https://owasp.org/www-project-web-security-testing-guide/latest/

Notas relacionadas

Playbooks de SeguridadDetectar la recolección de BloodHoundDetectar la enumeración de Active Directory por colectores de la familia BloodHound (SharpHound / BloodHound-CE y sucesores como SOAPHound) lo suficientemente temprano como para identificar el host de origen, el principal de origen y el método de recolección antes de que el operador convierta el grafo de ataque resultante en una cadena Kerberoast → DCSync → Domain Admin — y con suficiente fidelidad como para sobrevivir a las evasiones realistas de 2026 (LDAP paginado/throttleado, recolección DCOnly, abuso de AD Web Services, colectores custom en memoria). Playbooks de SeguridadDetectar DCSync y acceso a ntds.ditDetectar las dos formas de extracción masiva de credenciales de Active Directory — DCSync (IDLDRSGetNCChanges vía la interfaz RPC DRSUAPI) y extracción offline de ntds.dit (acceso a nivel archivo, abuso de shadow-copy VSS, invocaciones de ntdsutil) — con fidelidad suficiente para identificar el principal origen, las cuentas afectadas y la ventana posterior a la extracción antes de que puedan usarse tickets falsificados (Golden Ticket o Silver Ticket). Playbooks de SeguridadDetect External Recon Scan PipelineDetectar a un operador externo corriendo un pipeline de recon de dos fases Masscan → Nmap-NSE (el playbook ofensivo Run External Recon Scan Pipeline) contra tu perímetro, con fidelidad suficiente para identificar fuente, scope e intención en minutos — antes de que los hallazgos de la fase de profundidad se conviertan en explotación posterior. Playbooks de SeguridadDetectar Kerberoasting y AS-REP RoastingDetectar las dos familias de ataques de credenciales Kerberos en Active Directory (Kerberoasting y AS-REP Roasting) mediante análisis behavioral sobre Event IDs 4768/4769 y telemetría complementaria, con fidelidad suficiente para identificar la cuenta origen, el host atacante y el alcance en minutos, y con durabilidad suficiente para sobrevivir pequeñas variaciones de tradecraft del operador (tipo de cifrado, tasa de requests, selección de cuentas). Playbooks de SeguridadExploit IDORDeterminar si los identificadores de objetos pueden manipularse para acceder a datos o acciones de otro usuario. Playbooks de SeguridadExploit SQL InjectionDeterminar si input controlado por el usuario puede alterar la lógica de queries SQL de forma que cambie acceso, datos o comportamiento.