Skip to main content
Corgea AI Pentest ejecuta pruebas de penetración autónomas contra tus aplicaciones web en funcionamiento. Mientras que el SAST razona sobre el código fuente, un pentest ataca la aplicación desplegada tal y como lo haría un adversario: enumera la superficie de ataque, encadena debilidades entre sí y demuestra cada hallazgo con un exploit que funciona. Cada ejecución genera hallazgos con una prueba de concepto reproducible y un informe PDF que puedes compartir con un cliente, un auditor o tu propio equipo de ingeniería.
El pentesting está en beta y se ofrece como complemento. Si no ves Pentests en la barra lateral, contacta con el administrador de Corgea de tu organización o escribe a sales@corgea.com.

​
Cómo funciona un pentest

Todas las ejecuciones siguen las mismas tres etapas.
1

Reconocimiento

Los agentes trazan la superficie de ataque de tu objetivo: endpoints, flujos de autenticación, parámetros y rutas que no están enlazadas desde ningún sitio evidente.
2

Ataque

Varios agentes especializados trabajan sobre el objetivo en paralelo, cada uno a cargo de un dominio. En lugar de limitarse a buscar coincidencias de patrones, intentan una explotación real y encadenan debilidades de distintos dominios para llegar a resultados de mayor impacto.
3

Informe

Los hallazgos confirmados se documentan con una descripción, el impacto de negocio, la cadena de ataque, el script de explotación y las pautas de remediación, y se recopilan en un informe descargable.
Todas las ejecuciones utilizan estos agentes: Una ejecución Deep añade un agente de red team ampliado que explora más allá de esos dominios y construye cadenas de ataque de varios pasos que los combinan.
Corgea solo informa de los hallazgos que sus agentes han podido validar contra la aplicación en funcionamiento. Todo hallazgo que aparece en el informe se ha reproducido, no es una simple sospecha.

​
Antes de empezar

Ejecuta pentests únicamente contra aplicaciones que tu organización posea o esté autorizada de forma explícita a probar. Un pentest envía tráfico de ataque real y puede crear, modificar o eliminar datos. Dirige las ejecuciones a staging o a un entorno de pruebas específico, salvo que hayas asumido el riesgo de probar en producción.
La URL de tu objetivo debe ser accesible públicamente por http o https. Corgea rechaza los objetivos que:
  • Usan un esquema distinto de http o https
  • Incluyen credenciales directamente en la URL, como https://user:pass@example.com
  • Resuelven a localhost, a un rango de red privada o a una dirección de metadatos de la nube
Si tu aplicación no es accesible desde internet, expón una instancia de pruebas o escríbenos para valorar opciones.

​
Objetivos

Un objetivo es una configuración reutilizable: dónde atacar, qué credenciales usar y las instrucciones permanentes que quieras dejar fijadas. Cada ejecución se lanza contra un objetivo, así que lo configuras una vez y lo vuelves a lanzar cada vez que despliegues.
La página de Pentesting con la pestaña de objetivos y una lista de objetivos configurados, cada uno con su URL, la hora de su última ejecución y quién lo creó, además de la cuota restante de Standard y Deep en la esquina superior derecha
La cabecera muestra cuánta cuota de pentest te queda en cada modo de escaneo. La pestaña Pentest runs lista todas las ejecuciones de todos los objetivos, y puedes buscar entre ellas y filtrarlas por estado.

​
Crear un objetivo

1

Abre Pentests

Selecciona Pentests en la barra lateral y haz clic en New target.
2

Ponle nombre al objetivo e introduce su URL

Usa un nombre que tu equipo reconozca, como Acme Public API. La URL es la raíz de la aplicación desde la que arrancan los agentes.
3

Añade credenciales si quieres pruebas autenticadas

Las credenciales son texto libre que se comparte con los agentes: lo mismo que necesitaría una persona para iniciar sesión. Basta con una línea como demo@example.com / hunter2. Sin credenciales, los agentes prueban la aplicación como un atacante externo anónimo.
4

Añade instrucciones, si tienes alguna

Utiliza Additional instructions para las reglas de compromiso, las exclusiones de alcance o los endpoints en los que quieres que se concentren los agentes.
5

Elige un modo de escaneo predeterminado

Balanced o Deep. Puedes cambiarlo en cada ejecución.
El cuadro de diálogo New target con campos para el nombre del objetivo, la URL del objetivo, credenciales opcionales, instrucciones adicionales opcionales y un selector de modo de escaneo predeterminado
Las credenciales se cifran en reposo y solo se descifran mientras hay una ejecución en curso contra ese objetivo.

​
Editar y archivar

Abre el menú de acciones de un objetivo para iniciar una ejecución, editarlo o archivarlo. Las ediciones se aplican solo a las ejecuciones futuras. Cada ejecución guarda la configuración del objetivo con la que arrancó, de modo que las ejecuciones históricas y sus hallazgos siempre reflejan la configuración que los produjo. Cambiar una URL o rotar credenciales nunca reescribe lo que reportó una ejecución anterior. Al editar un objetivo, si dejas el campo de credenciales en blanco, las credenciales guardadas se mantienen tal cual. Para eliminarlas por completo, selecciona Clear stored credentials. Archivar oculta un objetivo de la lista, pero mantiene consultables todas sus ejecuciones históricas.

​
Iniciar una ejecución

En el menú de acciones de un objetivo, elige Start new run.
Una evaluación más rápida que cubre autenticación y autorización, lógica de negocio e inyección. Úsala para pruebas rutinarias con una cadencia regular.
Instruction override sustituye las instrucciones permanentes del objetivo solo en esa ejecución. Déjalo en blanco para usar las que ya tenga el objetivo. Resulta útil cuando quieres que una ejecución concreta se centre en una funcionalidad recién desplegada sin acotar el objetivo de forma permanente. Las ejecuciones Balanced y Deep consumen cuotas independientes. El desplegable de modo de escaneo muestra cuántas te quedan de cada una, y no se puede seleccionar un modo que se haya quedado sin cuota. Para ampliar tu cuota, escribe a sales@corgea.com.

​
Seguir una ejecución

Las ejecuciones tardan unas horas según el modo de escaneo y el tamaño de la aplicación. No hace falta que dejes la página abierta: los hallazgos se guardan a medida que se confirman y los administradores pueden recibir un correo cuando la ejecución termina. Mientras una ejecución está activa, su página se actualiza sola. Los hallazgos aparecen conforme los agentes los validan, así que puedes empezar a clasificar los problemas críticos antes de que la ejecución termine. Haz clic en Logs para ver trabajar a los agentes.
La vista de agentes de Corgea Pentest con un árbol de agentes trabajando en paralelo, los totales acumulados de llamadas a herramientas y hallazgos, y un panel lateral que describe la tarea actual y la última actividad del agente seleccionado
El árbol muestra cada agente, en qué está trabajando y cuántos hallazgos ha confirmado. Al seleccionar un agente se abre su tarea actual y su última actividad. Los agentes van creando agentes hijo sobre la marcha: cuando uno encuentra algo que merece la pena investigar, delega un seguimiento específico en lugar de abandonar su propia línea de ataque.

​
Revisar los hallazgos

Cuando una ejecución termina, su página resume lo que se ha encontrado.
Una ejecución de pentest finalizada con 76 hallazgos en total, desglosados en tarjetas de categoría Auth and AuthZ, Business Logic e Injection con recuentos por gravedad, sobre una lista de hallazgos agrupada por CWE
Las tarjetas de la parte superior reparten los hallazgos en categorías según su CWE. Haz clic en una para filtrar la lista que aparece debajo.
  • All findings — todo lo que confirmó la ejecución, con recuentos por gravedad
  • Auth & AuthZ — problemas de control de acceso roto, autenticación y sesiones
  • Business Logic — problemas de integridad en flujos de trabajo y transacciones
  • Injection — problemas de inyección, traversal y entrada no confiable
  • Validated SAST — próximamente; cruzará los hallazgos SAST confirmados con su explotabilidad en tiempo de ejecución
Los hallazgos cuyo CWE no encaja en ninguna de estas categorías siguen apareciendo en All findings.

​
Filtrar y agrupar

La barra de herramientas situada sobre la lista de hallazgos te ofrece:
  • Pastillas de estado — Open, Fixed, Closed y False Positive, cada una con un recuento en vivo. More añade Accepted Risk, Duplicate y todos los estados.
  • Búsqueda — busca por título, CWE y endpoint
  • Gravedad — filtra por Critical, High, Medium, Low o Info
  • Selector CWE / Endpoint — agrupa los hallazgos por tipo de debilidad o por el endpoint al que afectan
Agrupar por CWE responde a «qué clases de fallo tiene esta aplicación». Agrupar por endpoint responde a «qué parte de la aplicación está peor», que suele ser la vista más útil a la hora de repartir el trabajo de remediación.

​
Detalles del hallazgo

Abre cualquier hallazgo para consultar la documentación completa, repartida en cinco pestañas.

​
Detalles del hallazgo

La descripción, el impacto de negocio, los roles y usuarios afectados y el análisis técnico de la causa raíz. La barra lateral recoge el identificador CWE, la gravedad, la puntuación CVSS, el objetivo, el endpoint y cuántas veces se ha vuelto a detectar el hallazgo en distintas ejecuciones.
La pestaña de detalles de un hallazgo crítico de toma de control de cuenta, con la descripción, el impacto y los roles afectados, y una barra lateral que indica CWE-639, gravedad crítica, una puntuación CVSS de 9.4 y el objetivo y el endpoint afectados

​
Cadena de ataque

La secuencia exacta que siguió el agente, en pasos numerados. Cada paso indica la petición que envió y lo que devolvió la aplicación, de modo que cualquier ingeniero pueda recorrer el mismo camino sin conjeturas.
La pestaña de cadena de ataque con cuatro pasos consecutivos que reproducen una toma de control de cuenta, desde el registro de la cuenta de la víctima hasta la verificación del control total

​
Script de explotación

Un script ejecutable que reproduce el hallazgo. Lánzalo contra tu objetivo para comprobar el problema por ti mismo y vuelve a lanzarlo después de corregirlo para confirmar que la solución aguanta.
La pestaña del script de explotación con un script de Python que reproduce el hallazgo contra la aplicación objetivo
Los scripts de explotación realizan ataques reales. Ejecútalos solo contra sistemas que estés autorizado a probar y cuenta con que pueden crear o modificar datos.

​
Remediación

Pasos de remediación concretos para ese hallazgo en particular, además de referencias a los estándares y las guías pertinentes.
La pestaña de remediación con cuatro pasos de remediación consecutivos y una sección de referencias que enlaza con las guías de OWASP

​
Historial

Una cronología del hallazgo que abarca todas las ejecuciones: cuándo se detectó por primera vez, cuándo se volvió a detectar y cada cambio de estado y comentario, con la persona que lo hizo. Corgea reconoce el mismo problema de fondo de una ejecución a otra. Si un hallazgo reaparece en un pentest posterior, se vincula al original en lugar de registrarse como algo nuevo, así que el historial cuenta una única historia continua.

​
Clasificar los hallazgos

Utiliza Current Status en un hallazgo para dejar constancia de una decisión. Puedes asignar: Un cambio de estado se aplica a todas las detecciones de ese mismo problema, así que clasificarlo una vez actualiza el historial completo y no solo la fila que abriste. También puedes añadir comentarios para dejar contexto a tus compañeros.
Closed aparece como estado, pero no se puede asignar a mano. Corgea lo aplica automáticamente cuando una ejecución de revalidación ya no consigue reproducir un hallazgo.

​
Exportar un informe

Cuando una ejecución termina, Export report ofrece dos PDF.

Technical report

La evaluación completa, con el análisis técnico, la prueba de concepto, el código de explotación y las pautas de remediación de cada hallazgo. Pensado para tu equipo de ingeniería.

Executive report

La misma evaluación y los mismos hallazgos, pero sin el análisis técnico en profundidad, la prueba de concepto ni el detalle de remediación. Pensado para clientes, auditores y dirección.
Ambos informes incluyen:
  • Una declaración de confidencialidad y un índice
  • Un resumen ejecutivo y un panel de hallazgos
  • El alcance y la metodología, con los agentes que se ejecutaron y lo que cubrió cada uno, además de una declaración explícita de lo que queda fuera de alcance
  • Las definiciones de gravedad y la acción recomendada para cada nivel
  • Una tabla resumen con todos los hallazgos
  • Los hallazgos detallados agrupados por gravedad
Los informes pueden servir como evidencia de pruebas de penetración en auditorías de SOC 2 e ISO 27001, y están pensados para compartirse tal cual con clientes y auditores. Que un informe cumpla un requisito concreto depende del alcance de tu auditoría, de los controles que hayas seleccionado y de tu auditor.

​
Revalidar después de corregir

Cuando hayas desplegado las correcciones, vuelve a probarlas sin gastar un pentest completo sobre toda la aplicación. En una ejecución finalizada, abre el menú New run y elige Revalidate Findings. Una ejecución de revalidación vuelve a probar únicamente los hallazgos de la ejecución de origen e informa de:
  • Still open — los hallazgos que ha vuelto a reproducir
  • Closed by this run — los hallazgos que ya no ha podido reproducir, que pasan automáticamente a Closed
1

Corrige los hallazgos

Ve siguiendo los pasos de remediación y marca los hallazgos como Fixed conforme avances.
2

Revalida

Desde la ejecución finalizada, elige New run y luego Revalidate Findings.
3

Confirma

Los hallazgos que ya no se pueden reproducir pasan a Closed. Todo lo que siga siendo reproducible permanece abierto y con evidencia nueva.
La revalidación requiere una ejecución finalizada con al menos un hallazgo en Open o Fixed. Una ejecución de revalidación no se puede revalidar a su vez: lanza otra revalidación desde la ejecución original.
La revalidación es la forma más rápida de demostrar la remediación ante un auditor o un cliente: enseña que la misma prueba que encontró el problema ya no consigue reproducirlo.

​
Notificaciones

Los administradores de la empresa pueden recibir un correo AI Pentest Completed cuando termina una ejecución, con el objetivo, el modo de escaneo, el total de hallazgos y el desglose por gravedad. Es una preferencia de correo individual, así que quien prefiera no recibirlo puede desactivarlo sin afectar al resto. Corgea también dispara un webhook al finalizar, que puedes usar para publicar los resultados en Slack, abrir tickets o condicionar un pipeline de release. Consulta Webhooks para ver la configuración y el detalle del payload. Las ejecuciones de revalidación no envían notificaciones de finalización.

​
Preguntas frecuentes

Unas horas, según el modo de escaneo y el tamaño y la complejidad de tu aplicación. Las ejecuciones Deep tardan más que las Balanced. No hace falta que vigiles la ejecución: los hallazgos se guardan a medida que se confirman y los administradores pueden recibir un correo cuando termina.
Sí. Añade credenciales al objetivo y los agentes probarán las áreas autenticadas como un usuario con la sesión iniciada. Las ejecuciones incluyen además pruebas sin autenticar, así que obtienes tanto la perspectiva del atacante externo como la del usuario autenticado.
Los agentes realizan ataques reales, que pueden crear, modificar o eliminar datos. Las pruebas de denegación de servicio y de carga volumétrica quedan explícitamente fuera de alcance, pero aun así conviene apuntar las ejecuciones rutinarias a staging o a un entorno de pruebas específico.
Los objetivos deben usar http o https, no pueden llevar credenciales incrustadas en la URL y no pueden resolver a localhost, a un rango de red privada ni a una dirección de metadatos de la nube. En su lugar, expón una instancia de pruebas accesible.
Ese modo se ha quedado sin cuota. Balanced y Deep se contabilizan por separado, y las cantidades restantes aparecen en la cabecera de la página y en el desplegable de modo de escaneo. Escribe a sales@corgea.com para ampliarla.
El estado de la ejecución indica el motivo. Las causas más habituales son un objetivo que dejó de ser accesible a mitad de la ejecución y unas credenciales que dejaron de funcionar. Comprueba que el objetivo está operativo y que las credenciales siguen vigentes, y lanza una nueva ejecución.
No necesariamente. Significa que los agentes no pudieron validar ningún problema explotable dentro del alcance. Si esperabas hallazgos, revisa que las credenciales sean correctas para que las áreas autenticadas fueran accesibles, y valora una ejecución Deep para ampliar la cobertura.
El SAST razona sobre el código fuente y detecta problemas antes de desplegar. Un pentest ataca la aplicación en funcionamiento y demuestra qué es explotable de verdad en tu configuración desplegada. Cada uno detecta cosas distintas, y en Corgea los hallazgos de ambos se registran por separado.

​
Relacionado

BLAST

SAST nativo de IA para detectar vulnerabilidades en el código fuente antes del despliegue.

Webhooks

Recibe los eventos de finalización de pentest en tus propios sistemas.

Informes

Haz seguimiento de la postura de seguridad de tu organización a lo largo del tiempo.

Políticas

Define cómo se priorizan y se gestionan los problemas.