Pentest de caja negra (black box): guía para SaaS y fintech

El pentest de caja negra — o black box — es la modalidad en la que el investigador de seguridad recibe cero conocimiento previo sobre el objetivo. Sin credenciales, sin documentación, sin acceso al código, sin diagramas de arquitectura. Solo el nombre de dominio, la URL pública o una dirección IP. A partir de ahí, simula exactamente lo que haría un atacante externo real: descubrir, mapear, enumerar, explotar.

Es la modalidad más “cinematográfica” de las tres — la que más se parece a la imagen mental que el fundador de un SaaS o de una fintech tiene de un “hacker ético”. También es la que con más frecuencia se contrata mal, porque la mayoría de las empresas elige caja negra sin entender qué cubre y qué no cubre.

Esta guía explica a fondo qué es la caja negra en 2026, cómo funciona en la práctica, cuándo contratarla, cuándo NO, y cómo se compara, a grandes rasgos, con la caja gris (grey box) y la caja blanca (white box).

Qué es un pentest de caja negra, en una definición

El pentest de caja negra es la simulación controlada de un ataque externo, realizada por un investigador de seguridad que opera con el mismo nivel de acceso e información que tendría sobre el objetivo cualquier persona anónima de internet. Sin credenciales, sin documentación, sin código, sin infraestructura. El alcance empieza donde termina la internet pública: dominio, subdominios, endpoints expuestos, APIs públicas, formularios de registro, flujos de OAuth, integraciones de terceros visibles desde afuera.

Junto a la caja gris (que recibe credenciales y documentación básica) y la caja blanca (que recibe acceso completo a código, base de datos e infraestructura), la caja negra ocupa el extremo de menor conocimiento previo del espectro — y, en consecuencia, el que más tiempo dedica al descubrimiento antes de que empiece la explotación propiamente dicha.

Diferencias rápidas: black box vs. grey box vs. white box

Si eres nuevo en el tema, aquí va una tabla de referencia rápida. El foco de esta guía es la caja negra, pero vale la pena ubicarla dentro del espectro:

Para profundizar en la caja gris, consulta Pentest de caja gris (grey box): guía 2026 para SaaS y fintech. Para la visión comparativa completa, que también cubre la caja blanca, consulta Pentest de caja negra, gris o blanca: cuál elegir en 2026.

Cómo funciona la caja negra en la práctica: metodología

Un pentest de caja negra bien hecho sigue cuatro fases distintas. La forma en que se reparte el tiempo entre ellas es lo que define la modalidad — y lo que más sorprende a quien la contrata por primera vez.

Fase 1 — Reconocimiento y OSINT (40–60% del proyecto)

El investigador empieza sin nada más que el nombre de dominio. De ahí en adelante, descubre todo lo que puede descubrir sin tocar el sistema:

• Enumeración de subdominios — vía DNS, certificados (crt.sh), servicios pasivos (Shodan, Censys), wordlists activas (Amass, Subfinder). Un subdominio olvidado = vector clásico de subdomain takeover.
• Mapeo de tecnologías — fingerprint del framework, el CMS, el servidor web y las librerías del lado del cliente. Cada versión desactualizada es candidata a un CVE conocido.
• Inventario de la superficie externa — todas las URLs públicas, APIs documentadas (Swagger, OpenAPI, GraphQL introspection), endpoints REST mapeados, formularios, flujos de registro, login, OAuth, integraciones.
• OSINT corporativo — filtraciones públicas (GitHub, pastebin, dumps), credenciales ya comprometidas en brechas conocidas, perfiles del equipo de ingeniería de la empresa en LinkedIn (stack confirmado), archivos olvidados en buckets S3 públicos.
• Análisis de comportamiento — cómo responde el sistema a entradas inesperadas, encabezados de seguridad presentes o ausentes, métodos HTTP aceptados, rate limiting observable.

Esta fase es desproporcionadamente larga y es la mayor diferencia práctica de la caja negra. En la caja gris, el cliente entrega el inventario en 1 reunión. En la caja negra, el investigador lo descubre todo por su cuenta — y encuentra cosas que el cliente olvidó que existían.

Fase 2 — Enumeración activa y fingerprinting profundo

Ya con el mapa, el investigador empieza a sondear activamente cada endpoint:

• Comportamiento de la autenticación en cada flujo (login, registro, reset, OAuth)
• Parámetros aceptados por cada endpoint, métodos HTTP, content-types
• Mensajes de error reveladores (verbose errors, stack traces, versiones filtradas en banners)
• Comportamiento bajo carga (rate limiting real, colas, fingerprint del WAF)
• Diferencias de comportamiento entre subdominios (staging expuesto, entorno de desarrollo accesible, instancias antiguas olvidadas)

Fase 3 — Explotación de vulnerabilidades visibles desde afuera

Con la superficie mapeada, la explotación se enfoca en las clases de bugs que la caja negra puede alcanzar:

• Autenticación y sesión — bypass del login, manipulación del flujo OAuth (state confusion, fuzzing del redirect URI, bypass de PKCE), forja de JWT (algorithm confusion, kid path traversal), enumeración de usuarios
• Autorización alcanzable desde afuera — BOLA vía registro, IDOR en endpoints de uso público, abuso de tenants mediante registros paralelos
• Inyecciones — SQLi en parámetros expuestos, XSS en campos públicos, SSRF en webhooks/integraciones configurables
• Lógica de negocio externa — manipulación de precios/cupones en un checkout público, race condition en el registro o la creación de cuentas, downgrade del flujo de MFA mediante parámetros, abuso de promociones de un solo uso
• Configuraciones incorrectas expuestas — buckets S3 públicos, GraphQL con introspection activa, paneles administrativos olvidados en subdominios, .env servido por error, composer.lock / package.json que revelan librerías vulnerables

Fase 4 — Post-explotación limitada e impacto demostrado

En la caja negra, la post-explotación es deliberadamente limitada: el investigador demuestra que el bug existe y cuál es el impacto posible, pero no pivotea hacia la red interna ni exfiltra datos reales. El foco es una prueba de concepto reproducible: una captura de pantalla, un cURL como evidencia, un informe que describe cómo y hasta dónde podría llegar un atacante si alguien malintencionado explotara el bug.

Lo que la caja negra cubre bien

La caja negra es excelente en tres cosas:

1. La superficie externa real

Todo lo que está expuesto en la internet pública pasa por la lente del investigador exactamente como pasaría por la de un atacante. Subdominios olvidados, endpoints de admin no documentados, paneles legacy, instancias de staging con datos de producción: la caja negra los encuentra. El equipo interno no los encontraría, porque no sabe que existen.

2. Validación de la autenticación y de los flujos sin login

OAuth, OIDC, restablecimiento de contraseña, registro público, desafío de MFA, magic link: todos tienen versiones vulnerables que solo aparecen al probar sin credenciales. La caja negra es la única modalidad que valida esos flujos exactamente como los explota un atacante real.

3. La postura de defensa visible

¿El WAF es efectivo? ¿Hay rate limiting en los endpoints sensibles? ¿Los encabezados de seguridad están configurados? ¿Hay encabezados que filtran versiones? ¿Mensajes de error reveladores? La caja negra muestra la foto de la defensa que vería el atacante real antes de intentar atacar — y eso es información accionable para el equipo de seguridad.

Lo que la caja negra NO cubre

Y aquí es donde se equivoca la mayoría de quienes contratan. La caja negra no ve prácticamente nada de lo que pasa después del login. Si el 90% de tu complejidad técnica está en rutas autenticadas — área de clientes, panel de admin, dashboards internos, APIs autenticadas, multi-tenant —, la caja negra deja casi todo eso afuera.

Cobertura baja en autorización después del login (BOLA, BFLA, BOPLA)

BOLA cross-tenant, BFLA (Broken Function Level Authorization), BOPLA (Broken Object Property Level Authorization): las tres fallas que dominan las APIs en 2026 exigen varias cuentas autenticadas en tenants distintos. La caja negra puede llegar a crear cuentas (si el registro es público), pero la prueba cross-tenant autenticada es más sistemática en la caja gris. Consulta el detalle en BOLA, BOPLA y BFLA: las 3 fallas que dominan las APIs en 2026.

Lógica de negocio interna

Flujos financieros internos, reglas de aprobación en varios pasos, automatizaciones de backoffice, jobs asíncronos, integraciones server-to-server: toda esa capa queda invisible en la caja negra. El investigador no logra descubrirla y, cuando encuentra alguna pista desde afuera, rara vez tiene tiempo de explorarla a fondo (el reconocimiento ya consumió el 40–60% del presupuesto).

Bugs de código (race conditions, mass assignment, deserialización)

Varias clases solo aparecen leyendo el código u observando desde adentro: una race condition sutil en una transacción financiera, mass assignment en endpoints de actualización, deserialización insegura en parsers internos, PHP Object Injection, SSRF encadenado en jobs internos. La caja blanca detecta todo eso en horas. La caja negra tarda días y, aun así, se le escapan varios.

Configuraciones de la infraestructura interna

Permisos de IAM excesivos, secrets en variables de entorno, S3/RDS sin cifrado en reposo, seguridad de contenedores (privileged, montajes hostPath), red interna mal segmentada: todo eso queda afuera. La caja negra solo ve lo que está expuesto. La caja gris y la caja blanca ven lo que está mal configurado por dentro.

Cuándo contratar un pentest de caja negra

La caja negra tiene sentido en escenarios específicos. Los más comunes:

1. Antes de lanzar un producto público

Estás por lanzar (o abrir al público) un producto SaaS, fintech o e-commerce. Antes de que entre el primer cliente real, quieres validar que la superficie externa es más defendible que el promedio del mercado. La caja negra te da esa foto rápida.

2. Due diligence que simula un ataque real

Un inversionista, un posible comprador o un socio enterprise te pidió evidencia de seguridad. Quieres demostrar que tu aplicación resiste una simulación realista de un atacante externo — no un cuestionario de SOC 2 completado. La caja negra genera el tipo de evidencia que importa en ese contexto.

3. Primera colaboración con un proveedor de pentest (prueba)

Nunca contrataste un pentest, estás evaluando proveedores y quieres un proyecto de bajo riesgo y plazo corto para conocer su metodología y su estándar de informe. Una caja negra de 40–60 h es una prueba natural: no necesitas abrir el código ni compartir credenciales, y un NDA bilateral cubre todo el riesgo.

4. Validación continua de la superficie (recurrente)

Una empresa madura ejecuta caja negra de forma recurrente (mensual o bimestral), enfocada específicamente en la superficie externa, solo para capturar subdominios nuevos, funcionalidades recién expuestas y endpoints agregados desde el último ciclo. No reemplaza a un pentest profundo, pero mantiene activo el radar externo.

5. Threat intel y preparación para bug bounty

Antes de abrir un programa público de bug bounty (HackerOne, Bugcrowd, Intigriti, YesWeHack), los equipos maduros hacen una caja negra interna para identificar lo que caería en el primer mes. Ahorra pagos de recompensas y da tiempo para corregir antes de que lo encuentre la audiencia global.

Cuándo NO contratar caja negra

Y aquí es donde se equivoca casi la mitad de las contrataciones:

1. Cuando necesitas cobertura completa

Si el objetivo es “auditar todo el sistema”, la caja negra sola no alcanza. La cobertura típica queda en el 30–50%: todo lo que está después del login y el código quedan afuera. Para una cobertura amplia, combínala con caja gris (e, idealmente, con caja blanca en las áreas críticas).

2. Cuando te estás preparando para SOC 2 / ISO 27001

Las auditorías formales exigen evidencia de un pentest amplio. La caja negra sola no cubre los requisitos de control de acceso interno (CC6 de SOC 2, A.9 de ISO 27001). Para esas certificaciones, contrata caja gris o caja blanca.

3. Cuando el 90% del producto es autenticado

Un SaaS B2B con poca superficie pública y todo lo importante detrás del login (que es la mayoría) tiene poco que ganar con una caja negra pura. En ese caso, la caja gris es casi siempre la opción correcta. Consulta el análisis por tamaño en Cuánto cuesta un pentest según el tamaño del SaaS B2B en 2026.

4. Cuando el presupuesto exige la máxima profundidad

De cada hora invertida en caja negra, ~50% se va en reconocimiento. En caja blanca, el reconocimiento dura minutos. Si el presupuesto es ajustado y buscas la máxima profundidad técnica por dólar invertido, la caja blanca es matemáticamente más eficiente — siempre que aceptes abrir el código.

Cuánto cuesta un pentest de caja negra en 2026

Como referencia, estos son los rangos de 2026 en el mercado brasileño, para SaaS y fintechs pyme:

• Caja negra liviana (20–40 h): R$ 6.000 – R$ 14.000 — superficie externa mapeada, vulnerabilidades comunes probadas, informe consolidado. Adecuada para un MVP, un prelanzamiento o una prueba.
• Caja negra estándar (60–80 h): R$ 16.000 – R$ 28.000 — reconocimiento profundo, explotación completa de la superficie externa, post-explotación demostrada, informe técnico + ejecutivo. Adecuada para un SaaS en producción con tráfico de cientos a miles de usuarios.
• Caja negra extendida (120 h+): R$ 32.000 – R$ 54.000+ — alcance amplio (varios subdominios/productos), tiempo extra dedicado a la lógica de negocio alcanzable desde afuera, integraciones de terceros probadas. Adecuada para una fintech con volumen relevante o un SaaS multiproducto.

Para rangos por tamaño y sector, consulta Cuánto cuesta un pentest en Brasil en 2026.

Cómo combinar la caja negra con la caja gris y la caja blanca

Una empresa madura rara vez contrata solo caja negra. La combinación típica que vemos en SaaS B2B brasileños consolidados:

• Anual: caja blanca completa (cubre código + infraestructura + acceso total)
• Trimestral: caja gris enfocada (autorización entre tenants, lógica de negocio, APIs autenticadas)
• Mensual/bimestral: caja negra liviana sobre la superficie externa (para capturar cómo va cambiando la superficie con el tiempo)

Esta combinación alcanza ~85% de cobertura efectiva a lo largo del año, con un costo total significativamente menor que el de 4 pentests de caja blanca trimestrales. La guía de caja gris y la comparación de las tres modalidades explican cómo contribuye cada una a este mosaico.

Qué hacer ahora

1. Mapea tu superficie externa real — ¿qué porción de tu producto está realmente expuesta sin login? Si es > 30%, la caja negra tiene un ROI directo. Si es < 10%, enfócate en la caja gris.
2. Define el objetivo — ¿prueba de proveedor, due diligence, prelanzamiento, monitoreo de la superficie? Cada uno requiere un dimensionamiento distinto de horas y profundidad.
3. Considera la combinación — la caja negra pura rara vez es la mejor opción en un SaaS consolidado. Combínala con caja gris o blanca según la etapa del producto y el tamaño del presupuesto.

Para entender la hoja de ruta completa de seguridad en SaaS, consulta seguridad para SaaS. Para el alcance técnico específico del pentest, consulta pentest para SaaS. Para fintech, consulta pentest para fintech.

Otras guías de la serie: caja gris, que cubre la modalidad con una profundidad comparable y la misma estructura (definición, metodología, cobertura real, cuándo contratarla, cuándo no y costo), y la comparación de las tres modalidades, que también cubre la caja blanca.

Si ya quieres pasar a la acción: solicita un pentest. NDA bilateral en 24h.