Basilisk
BASILISK
[cases_index]REAL ENGAGEMENTS · ANONYMIZED

Before it became a headline, it became a fix.

Todos los casos siguientes fueron anonimizados bajo NDA. Las cifras, el sector y el vector son reales — el nombre del cliente no.

200+
engagements delivered
4,500+
fallos explotables reportados
R$ 180M+
impacto potencial evitado
sector
Fintech · Open Finance
vector
API misconfig + IDOR
fix
72h
case/01

Acceso total a producción mediante una API interna sin autenticación

Un endpoint de administración quedó expuesto por una mala configuración del gateway de API. Combinado con IDOR en las rutas de transferencia, permitía llegar a cualquier cuenta. Detectado el día 2 del engagement.

impact avoided:R$ 48 M en movimientos potenciales bloqueados
sector
Healthtech · SaaS
vector
Cloud misconfig
fix
24h
case/02

Exposición de 1,2 M de historiales clínicos por un bucket S3 de staging

El bucket de staging replicaba datos de producción sin cifrado ni control de acceso. Corregido antes de la auditoría ISO externa.

impact avoided:Multa de protección de datos evitada · incidente no notificable
sector
Industry · OT
vector
Segmentación + credenciales heredadas
fix
2 weeks
case/03

Movimiento lateral desde TI hasta la planta industrial por una VPN heredada

Engagement de Red Team que empezó con phishing. Salto desde una estación de ingeniería a la red OT a través de una VPN con credenciales por defecto. Resuelto con segmentación, jump host y MFA.

impact avoided:Parada de línea estimada en 8 días evitada
sector
E-commerce · B2C
vector
XSS + sesión sin rotación
fix
96h
case/04

Cadena de explotación: XSS → toma de cuenta admin → saldo

Un XSS reflejado en la página de búsqueda, junto con una política de cookies permisiva, permitía robar la sesión de administrador. Detectado en un pentest estándar.

impact avoided:Fraude bloqueado, estimado en R$ 2,3 M al mes

Por qué todos los casos aquí son anónimos

Publicar el nombre de un cliente junto al fallo que tuvo lo expone dos veces: una durante el incidente y otra para siempre. Describir el vector y el impacto enseña; identificar a la víctima solo sirve de escaparate, y desalinea el incentivo, porque la empresa dispuesta a autorizar la divulgación pasa a ser la que menos tenía que perder.

  • Nombre, marca y cualquier detalle que permita identificar a la empresa quedan fuera.
  • El vector técnico se mantiene, porque es la parte con valor para quien lee.
  • Nada se publica antes de que la corrección esté concluida y confirmada en reprueba.
  • Todo el material pasa por autorización del cliente antes de convertirse en texto público.

Patrones que se repiten

Sectores distintos, arquitecturas distintas, y aun así los caminos que funcionan se parecen. Estos son los que aparecen con más frecuencia, y conviene mirarlos antes de contratar cualquier test.

// un entorno que no debería existir

Preproducción con copia de producción, un panel de administración antiguo, un servicio levantado para una demostración y nunca apagado. Suele faltar en el inventario y, por eso, queda fuera de toda protección aplicada al resto.

// autorización a nivel de objeto

El sistema comprueba que estás autenticado, pero no que ese registro sea tuyo. Es el fallo que más se le escapa a la herramienta automática, porque la petición parece perfectamente legítima.

// permiso temporal permanente

Acceso amplio concedido para desbloquear una entrega, con la promesa de ajustarlo después. Meses más tarde sigue ahí, ahora heredado por gente que nunca supo que lo tenía.

// un secreto en el lugar equivocado

Una clave en una variable de entorno expuesta, una credencial en el historial del repositorio, un token en un archivo de configuración versionado. Es el camino más corto hacia dentro y el más fácil de cerrar.

// confianza entre sistemas

Dos aplicaciones que se autentican por posición de red o por un secreto compartido. Comprometer la menos protegida entrega la más protegida, y la segmentación que debería contenerlo rara vez se ha probado.

// detección que no llega a nadie

El evento se registró, la alerta saltó, y acabó en una cola que nadie lee. Técnicamente detectado, en la práctica invisible: la diferencia solo aparece en un ejercicio sin aviso.

Preguntas frecuentes

01¿Por qué no hay nombres de clientes aquí?

Porque la autorización para publicar vendría de quien menos tiene que perder, no de quien tuvo el caso más instructivo. Todo el material se anonimiza bajo acuerdo de confidencialidad, y el vector técnico —la parte útil— se conserva.

02¿Servís como referencia en nuestro proceso de compra?

Sí, con autorización de las partes implicadas. Para la mayoría de los procesos, no obstante, lo que resuelve es la carta de conclusión de tu propio encargo, emitida tras la reprueba: es evidencia directa, y no la opinión de un tercero sobre otro trabajo.

03¿Un caso parecido al nuestro significa que el test sería igual?

No. El camino depende de la arquitectura, de las integraciones y de decisiones que solo aparecen en tu entorno. Los casos muestran el tipo de cosa que suele encontrarse, no un guion que se repite.

04¿Publicáis un fallo antes de que esté corregido?

Nunca. Nada se convierte en texto público antes de que la corrección esté concluida y confirmada en reprueba, y aun así solo con autorización. El mismo criterio rige nuestra propia investigación, descrito en la política de divulgación responsable.

// contacto

¿Listo para descubrir tus fallas?

La primera call de scoping es gratuita y cubierta por NDA. En 48 horas recibes propuesta técnica, alcance y cronograma. Sin formularios burocráticos.