Seguridad ofensiva
Antes de que lo encuentre otro, nosotros lo encontramos.
Pruebas ofensivas reales sobre tu infraestructura, tus aplicaciones y APIs, tus identidades y tu nube, ejecutadas por operadores con experiencia. Comprobamos qué puede explotarse, hasta dónde permite avanzar y qué corregir primero, con la evidencia para hacerlo.
OSCP · CEH · eCPPT · eWPTX · eJPT en el equipo. Y operamos el SOC que también ponemos a prueba.
Salud · Servicios financieros · Fintech · Cobranza · Call center · Turismo · Aviación ejecutiva · Aeropuertos · Autopistas · Tecnología
Lo que te trae
Casi nadie pide un pentest por curiosidad
Un cliente o una auditoría lo pidió
El cuestionario de seguridad pregunta cuándo fue la última prueba de intrusión, o una auditoría quiere ver cómo se validaron los controles.
Vas a sacar algo a producción, o algo cambió
Un portal, una API, una migración a la nube, una integración con un tercero. Quieres verlo antes que todo el mundo.
Ya tuviste un susto
Un intento detenido a tiempo, un proveedor comprometido. ¿Por dónde más podrían entrar?
El directorio o un inversionista quiere una respuesta con evidencia
"¿Qué tan expuestos estamos?" no se responde con una opinión. Se responde probando, con alguien que no es el equipo que lo construyó.
En todos los casos la pregunta es la misma: ¿qué puede hacer hoy un atacante con lo que tenemos expuesto? Y la única forma de responderla con evidencia es intentarlo.
Qué necesitas comprobar
Parte por lo que te preocupa. La prueba sale sola.
Una empresa puede probar lo que expone a Internet, sus aplicaciones y APIs, lo que alguien podría hacer desde adentro, hasta dónde llegaría un adversario y si sus defensas lo verían. Cada pregunta tiene una prueba que la responde.
Pentest externo
¿Qué tengo expuesto desde Internet?
Todo lo que se ve desde afuera: servicios publicados, VPN, correo, portales y lo que quedó abierto sin que nadie lo recuerde. Responde qué puede hacer un atacante sin ninguna credencial.
Pentest web y API
¿Pueden comprometer mi aplicación o mi API?
Las aplicaciones que sostienen el negocio, con foco en lo que un escáner no ve: lógica de negocio, control de acceso entre usuarios y entre clientes, flujos de pago y de datos.
Pentest interno e identidades
¿Qué podría hacer alguien que ya obtuvo acceso?
Se parte de que alguien ya entró: un equipo comprometido, un proveedor con acceso, una credencial filtrada. Se mide hasta dónde llega por la red, el directorio, las identidades y la nube.
Red team
¿Hasta dónde podría llegar un adversario real?
Un ejercicio con objetivo, sin avisar al equipo que defiende, que reproduce las técnicas de los actores que atacan a tu sector. Mide si la detección y la respuesta funcionan cuando importa.
Purple team
¿Mi EDR y mi SOC detectarían el ataque?
Atacantes y defensores en la misma sala. Cada técnica se ejecuta, se verifica qué vio la plataforma y el SOC, y se ajusta la detección en el momento.
No hace falta probar todo a la vez, ni saber de antemano cuál corresponde. El alcance se define según lo que quieras responder; lo demás se programa. Qué es un pentest, qué incluye y cómo elegir uno.
Un escaneo de vulnerabilidades no es un pentest.
Un escáner encuentra vulnerabilidades conocidas y señales de que algo podría estar mal. Es útil y conviene hacerlo de forma continua. Lo que no puede hacer es decidir.
En un pentest, un operador interpreta, valida, combina condiciones que por separado parecen menores y las explota de forma controlada para determinar el impacto real. La diferencia es automatización contra juicio, contexto y explotación controlada.
| Escaneo de vulnerabilidades | Pentest con JanusNet | |
|---|---|---|
| Qué encuentra | Vulnerabilidades conocidas y señales, con un puntaje genérico | Qué puede explotarse en tu entorno y qué permite en tu negocio |
| Quién decide | Una base de firmas | Un operador que interpreta, valida y encadena condiciones |
| Qué demuestra | Que algo podría estar mal | Hasta dónde se llegó, con evidencia de cada paso |
| Qué recibes | Un listado exportado | Rutas de ataque priorizadas y cómo cerrarlas |
Cómo trabajamos
Una persona con contexto, de principio a fin
Cada prueba tiene un operador asignado: el mismo que acuerda el alcance ejecuta, interpreta, encadena los hallazgos y presenta el informe. Las herramientas sirven para cubrir terreno más rápido; el criterio y la decisión de hasta dónde llegar son siempre de esa persona, que responde por lo que dice el informe.
- Alcance
- Reconocimiento
- Validación
- Explotación controlada
- Impacto
- Evidencia
- Remediación
- Retest
Etapa 1
Alcance y reglas de enfrentamiento
Qué se prueba y qué no, desde dónde, en qué ventanas, con qué límites y a quién se llama si algo se sale del plan. Todo por escrito y autorizado antes de tocar nada.
Etapa 2
Reconocimiento e hipótesis
Se recorre el alcance como lo haría un atacante: qué está expuesto, qué versiones corren, qué cuentas existen, qué se filtró alguna vez. Con eso, una persona arma hipótesis sobre por dónde intentar.
Etapa 3
Validación y explotación controlada
Cada hipótesis se valida y, dentro de los límites acordados, se avanza: si un hallazgo permite entrar, se entra; si permite moverse, se documenta hasta dónde; si permite llegar a datos, se prueba sin extraerlos. Un hallazgo crítico se avisa el mismo día.
Etapa 4
Impacto, evidencia e informe en dos niveles
La narrativa de ataque cuenta el camino completo para la gerencia. El detalle técnico trae cada hallazgo con cómo se reproduce, su evidencia y cómo se cierra, priorizado por lo que un atacante haría con él.
Después
Remediación y retest
Sesión de resultados con tu equipo técnico y, si corresponde, con tu gerencia. Plan de corrección ordenado por riesgo y esfuerzo, y retest sobre lo corregido cuando está contemplado en el alcance.
Las pruebas se apoyan en referencias públicas reconocidas: OWASP para aplicaciones y APIs y MITRE ATT&CK para describir las técnicas de un adversario. Son referencias metodológicas, no certificaciones. Ningún plazo se compromete acá: depende del alcance y de las ventanas que tu operación permita, y se define en la propuesta.
Qué puede descubrirse
Buscamos rutas de ataque, no vulnerabilidades sueltas
Una ruta de ataque es la cadena de condiciones que permite a un atacante avanzar desde un punto expuesto hasta un activo crítico. Una vulnerabilidad aislada puede parecer menor; varias encadenadas son la forma en que ocurren los incidentes. Encontrarlas exige entender el entorno, no solo escanearlo.
Ejemplo hipotético de una ruta, no un caso real
- Servicio expuesto
- Credencial
- Usuario
- Movimiento lateral
- Privilegio
- Activo crítico
Lo que necesita entender gerencia
- Qué permitió la ruta: un servicio publicado con una credencial reutilizada y un permiso heredado que nadie revisaba.
- Cuál sería el impacto: acceso a información de clientes y a un sistema del que depende la operación.
- Qué decisión toca: qué cerrar primero, qué revisar en el resto del entorno y qué control faltó.
Lo que necesita TI
- Dónde ocurrió cada paso, con la evidencia de que se realizó y hasta dónde se llegó.
- Qué condiciones fueron necesarias: la exposición, la credencial, el permiso y la falta de segmentación.
- Cómo se cierra cada condición, en qué orden, y qué debería haber alertado en el camino.
El mismo ejercicio produce las dos lecturas. Gerencia decide con la primera; TI corrige con la segunda.
Dónde suelen aparecer las condiciones de una ruta, según lo que cubra el alcance:
- Exposición inicial: servicios, portales y accesos remotos que se ven desde afuera y no deberían.
- Autenticación y autorización: credenciales débiles o reutilizadas, sesiones mal gestionadas, accesos entre usuarios que no se separan.
- Aplicaciones y APIs: lógica de negocio que se puede abusar, validaciones que faltan, datos que se exponen de más.
- Configuración y segmentación: sistemas con más superficie de la necesaria y redes donde todo alcanza a todo.
- Identidades y privilegios: permisos heredados, cuentas de servicio con más privilegio del necesario, delegaciones olvidadas.
- Nube: configuraciones, permisos, secretos expuestos y relaciones de confianza que abren rutas de escalamiento.
- Movimiento lateral y escalamiento: qué permite pasar de un equipo cualquiera a los que importan.
- Acceso a información y persistencia: hasta dónde llega el acceso y si podría mantenerse, cuando el alcance lo permite.
Entregables
Evidencia para decidir y para corregir, no un PDF
Después de un pentest recibes un resumen ejecutivo con la narrativa de ataque, los hallazgos priorizados con evidencia e impacto, las recomendaciones con el detalle técnico para cerrarlos y una sesión de resultados. Lo que depende del alcance, se dice.
Incluido
Resumen ejecutivo y narrativa de ataque
El camino completo, de la primera puerta al objetivo, contado para que la gerencia lo entienda sin traductor.
Incluido
Hallazgos priorizados con evidencia
Cada uno con cómo se reproduce, qué se alcanzó, la prueba de explotación y su impacto. Ordenados por lo que permiten.
Incluido
Recomendaciones y detalle técnico
Cómo cerrar cada condición, en qué orden y con qué esfuerzo.
Incluido
Sesión de resultados
Con tu equipo técnico y, si corresponde, con tu gerencia.
Cuando está contemplado en el alcance
Retest
Una segunda pasada sobre lo corregido, para poder decir con evidencia que quedó cerrado.
Después del informe
El objetivo no es acumular hallazgos. Es reducir rutas explotables.
El ciclo completo es encontrar, entender, priorizar, corregir y validar. El informe cubre los tres primeros. La corrección la ejecuta tu equipo con esas recomendaciones, y el retest, cuando está contemplado en el alcance, comprueba con evidencia que lo cerrado quedó cerrado.
Si prefieres que la remediación no dependa de tu agenda, dentro de la Oficina de Seguridad la opera el mismo equipo que encontró el problema, y las pruebas se repiten con la frecuencia de cada nivel.
La conexión que casi nadie hace
Un pentest también prueba a quien vigila
Un pentest sirve para probar un EDR o un SOC cuando el alcance contempla la validación de detecciones. En ese caso, cada técnica ejecutada se contrasta con lo que las defensas observaron: qué bloqueó el EDR, qué registró el SIEM, qué alertas llegaron al SOC. Si una actividad que esperábamos detectar pasó inadvertida, eso también es un hallazgo, y de los más útiles del informe.
Operamos un SOC y hacemos las pruebas, así que sabemos leer las dos mitades del resultado. Cuando la pregunta es justamente esa, el purple team la responde en la misma sala, técnica por técnica.
Preguntas frecuentes
¿Necesito saber qué tipo de prueba contratar?
¿Qué sistemas se pueden probar?
¿Un pentest puede afectar producción?
¿Qué pasa si encuentran algo grave a mitad de la prueba?
¿Qué diferencia hay entre pentest y red team?
¿Se realiza retest?
¿ISO 27001 o la Ley 21.719 exigen un pentest?
¿Quién hace las pruebas?
Parte por definir qué conviene probar
Cuéntanos qué te preocupa y qué tienes expuesto. Te ayudamos a definir el tipo de prueba y el alcance, y con eso cotizamos.
Que funcione. Y que puedas demostrarlo.