El hacking ético es la práctica autorizada de atacar un sistema como lo haría un adversario: encontrar vulnerabilidades, explotarlas en condiciones controladas y demostrar hasta dónde podría llegar realmente un atacante. El propietario aprueba el alcance antes de que empiece cualquier prueba y sigue siendo responsable de corregir lo que la prueba encuentre. La autorización es lo que separa el hacking ético de un ataque.
En el benchmark de Fluid Attacks de 36 herramientas de AppSec de terceros, ejecutado contra una aplicación web con 1.201 vulnerabilidades conocidas en 105 categorías CWE, un pentester encontró 1.076: 89,6 % de recall con 100 % de precisión. La mejor herramienta de terceros encontró 260 y reportó 102 falsos positivos. Ponderado por severidad, el hacking ético alcanzó el 98,9 % de la exposición al riesgo; la mejor herramienta, el 4,0 %.
Esta página cubre qué es y qué no es el hacking ético, en qué se diferencia de un pentest y de un ejercicio de red team, las cinco fases de una evaluación, las reglas bajo las que corre un trabajo real, qué encuentra el hacking ético que un escáner no alcanza, y cómo se reportan y divulgan los hallazgos.
¿Qué es el hacking ético?
El hacking ético es una metodología de pruebas de seguridad en la que especialistas autorizados copian las tácticas, técnicas y procedimientos de atacantes reales contra un objetivo definido. El propósito es ofensivo, la intención es defensiva. Lo que lo separa de una intrusión criminal no es la técnica, sino el consentimiento, el alcance y la rendición de cuentas.
Se apoya en tres condiciones. El propietario aprueba un objetivo de evaluación, que puede ser parte o la totalidad de la superficie de ataque. Ambas partes acuerdan qué pueden y qué no pueden hacer los evaluadores. Y cada hallazgo vuelve al propietario con la evidencia necesaria para corregirlo.
Los hackers maliciosos y los hackers éticos se apoyan en las mismas aptitudes: curiosidad, paciencia y la costumbre de preguntar qué pasa si. El texto de Fluid Attacks sobre la ética del hacking sostiene que la diferencia aparece en los efectos de la práctica de cada grupo, no en su habilidad.
Qué no es el hacking ético
Correr un escáner no es hacking ético. El escaneo de vulnerabilidades compara patrones conocidos y reporta candidatos; un hacker ético decide qué atacar, lo intenta y muestra la consecuencia.
Tampoco es un ataque sin límites. Una prueba sin objetivo de evaluación escrito, sin reglas acordadas y sin una vía de escalamiento no es hacking ético de alcance más amplio. Es un incidente esperando que alguien lo explique.
Por qué importa el hacking ético
Las pruebas automatizadas encuentran vulnerabilidades que se parecen a algo que ya vieron antes. El hacking ético encuentra las que dependen del contexto: para qué sirve la aplicación, quién puede hacer qué, y cuáles dos fallas de apariencia inofensiva se convierten en un problema serio cuando se encadenan.
Lo que el escaneo automatizado deja sobre la mesa
La documentación de Fluid Attacks le pone número al techo. El escaneo de vulnerabilidades por sí solo "finds only 10% to 30% of the total risk exposure of a system", y solo las pruebas manuales pueden confirmar el resto, incluidos los "business flows that need an environment, authentication, or test data".
El benchmark coincide. El 73,2 % de las 1.201 vulnerabilidades de la aplicación evaluada estaba detrás de autenticación, que es el territorio al que un escáner llega último y el hacking ético llega primero.
Severidad, no volumen
El volumen es el marcador equivocado para el hacking ético. En el reporte State of Attacks 2026, que cubre 1.119.396 vulnerabilidades reportadas entre el 1 de enero y el 31 de diciembre de 2025, las herramientas automatizadas identificaron el 88,4 % de los hallazgos y el trabajo manual identificó el 11,6 % restante.
Pero el 87 % de las vulnerabilidades de severidad crítica se identificó mediante revisión manual. Los hallazgos de herramientas automatizadas promediaron 15,5 unidades CVSSF; los del trabajo manual promediaron 93,2, seis veces más. Esas cifras corresponden solo al plan Advanced.
Hacking ético, pentesting y red teaming
El hacking ético es la categoría amplia; un pentest y un ejercicio de red team son dos maneras de hacerlo. Uno pregunta qué está roto en este objetivo. El otro pregunta si la organización notaría siquiera a un adversario.
Pentesting | Red teaming | |
|---|---|---|
Pregunta que responde | ¿Qué se puede explotar en este objetivo? | ¿Detectaríamos y responderíamos a un adversario real? |
Alcance | Un objetivo de evaluación definido | Un entorno empresarial más amplio, casi siempre en producción |
Objetivo | Encontrar, explotar y reportar todo lo que abarque el alcance | Alcanzar metas específicas de infiltración e impacto |
Qué se pone a prueba | El sistema | El sistema y las personas que lo defienden |
Conocimiento de los defensores | Suelen estar informados | Suelen no estar informados |
Entregable principal | Hallazgos con evidencia y guía de remediación | Un relato de la ruta de ataque y de la respuesta |
Ambos son hacking ético y ambos los ejecutan hackers éticos. La distinción que vale la pena conservar es la de arriba, no la que ordena las evaluaciones por tipo de objetivo. Ordenar por objetivo — aplicaciones web, aplicaciones móviles, APIs, infraestructura en la nube — describe tipos de pentesting, no tipos de hacking ético.
Hacking ético en Fluid Attacks
Fluid Attacks es una empresa de seguridad ofensiva cuyo hacking ético corre de forma continua sobre los sistemas de sus clientes, bajo el plan Advanced, junto a escáneres propios e IA. Así ocurre ese trabajo, incluido dónde se detiene.
Qué evaluamos y bajo qué reglas
Cada trabajo parte de un objetivo de evaluación que el cliente aprueba y corre bajo controles escritos para cada riesgo que implica probar en producción. Fluid Attacks define la intensidad y el ritmo de cada prueba, no usa técnicas de fuerza bruta no autorizadas y ejecuta primero en un entorno distinto al de producción cualquier prueba que pueda afectar la disponibilidad.
Dos reglas deciden el resto. Fluid Attacks siempre prueba desde sus propias direcciones IP, de modo que una falsa alerta en un WAF o un SOC se resuelve de inmediato. Y, según la documentación, "if a pentester has any doubt during a test, the pentester stops the test". El endpoint y el canal se mantienen bajo control total, con un modelo Zero Trust.
Cómo decidimos dónde atacar después
La cobertura no es el objetivo aquí. Como lo plantea la documentación de la plataforma, "manual techniques and AI-SAST use statistical risk prioritization instead of file coverage as their operating objective". Un método puede probar todos los archivos y aun así dejar pasar una vulnerabilidad crítica.
Unos modelos estadísticos eligen qué sistemas reciben atención, sopesando cuánto y qué tan recientemente cambió un sistema, qué archivos cambian más, cuántos autores los tocaron y su historial de vulnerabilidades frente a otros sistemas.
Esos modelos alimentan cinco equipos de ataque independientes: Systems, Criticals, Escapers, Deterministic y Reattack, y más de uno puede trabajar el mismo sistema a la vez cuando la prioridad de riesgo lo amerita.
Lo que una persona encontró y 36 herramientas no
Evaluador | Verdaderos positivos | Falsos positivos | Precisión | Recall | Recall (CVSSF) |
|---|---|---|---|---|---|
Pentester de Fluid Attacks | 1.076 | 0 | 100 % | 89,6 % | 98,9 % |
Escáner de Fluid Attacks | 273 | 3 | 99 % | 22,7 % | 8,8 % |
Mejor herramienta de terceros | 260 | 102 | 72 % | 21,6 % | 4,0 % |
Las otras 34 herramientas de terceros | — | — | — | 1,7 % en promedio | — |
Benchmark de Fluid Attacks contra una aplicación web con 1.201 vulnerabilidades conocidas equivalentes a 461.500 unidades CVSSF.
La diferencia que importa está en la última columna. El hacking ético encontró 743 vulnerabilidades que ninguna herramienta encontró: el 61,9 % del total, con el 86,8 % de la exposición al riesgo. El pentesting manual profundiza en por qué.
Cada hallazgo se revisa antes de que el cliente lo vea
Un reporte no llega directo al cliente. Entra como borrador y pasa por una revisión entre pares que puede devolverlo con cualquiera de nueve observaciones: redacción, evidencia, puntuación, consistencia, omisión, nomenclatura, falso positivo, duplicado u otra.
Tres de ellas — nomenclatura, falso positivo y duplicado — cierran el ciclo con un rechazo; las demás vuelven para corrección. Los revisores repiten el ciclo "with as many review cycles as necessary", y solo entonces el cliente lo ve. Esta es la mitad poco vistosa del hacking ético, y de lo que está hecho un resultado de 100 % de precisión.
Nueve tipos de observación que un revisor puede devolver antes de que el cliente vea el hallazgo.
Qué no evaluamos
Cuatro límites deciden si este tipo de hacking ético le sirve a un sistema o no.
Sin código fuente no hay prueba: un entorno registrado sin su código fuente queda fuera de alcance.
*Ni plataformas low-code ni servidores de correo*: la metodología necesita código fuente en un repositorio Git.
Sin evaluación versión por versión: las pruebas apuntan a la última versión de cada componente, y cada hallazgo queda atado al commit, el binario o el entorno donde apareció.
Sin SLA formal de tiempo de detección: hay un SLA de exactitud del 90 %, medido con F-scores ponderados por severidad, pero ninguna promesa sobre qué tan rápido se encuentra algo.
Uno más, sobre el benchmark de arriba. La herramienta automatizada con mejor desempeño fue el escáner propio de Fluid Attacks, no un producto de terceros, y un recall del 22,7 % sigue significando que se escapan tres de cada cuatro vulnerabilidades. El objetivo era una aplicación controlada y vulnerable por diseño, no un sistema en producción, así que esas cifras se leen como una comparación entre métodos, no como un pronóstico.
Las cinco fases del hacking ético
El hacking ético corre en cinco fases: reconocimiento, enumeración, análisis, explotación y reporte. Antes de la primera, el propietario define y aprueba el alcance y el objetivo de evaluación, que puede ser aplicaciones web o móviles, APIs y microservicios, clientes pesados, infraestructura en la nube, redes y hosts, dispositivos IoT o tecnología operacional.
Fase | Qué hace el evaluador | Qué produce | Categoría más cercana de OWASP WSTG v4.2 |
|---|---|---|---|
1. Reconocimiento | Recoge inteligencia de fuentes abiertas sin tocar el objetivo y luego establece contacto directo para mapear servicios, sistemas y personas | Un inventario de la superficie y de los vectores de ataque candidatos | 4.1 Information Gathering |
2. Enumeración | Bosqueja el estado de seguridad del objetivo y arma el instrumental según sus características | Una lista de puntos débiles ordenada por prioridad | 4.2 Configuration and Deployment Management Testing |
3. Análisis | Determina el impacto de cada vulnerabilidad sobre la confidencialidad, la integridad y la disponibilidad, y sobre los sistemas vecinos | Escenarios de ataque ordenados por impacto y dificultad | 4.3–4.9 Identidad, autenticación, autorización, sesión, validación de entradas y criptografía |
4. Explotación | Explota las vulnerabilidades, las encadena y pivotea hacia objetivos de alto valor | Prueba de hasta dónde podría llegar realmente un atacante | 4.10 Business Logic · 4.11 Client-side · 4.12 API Testing |
5. Reporte | Escribe un resumen ejecutivo para la gerencia y uno técnico para los desarrolladores, puntúa la severidad y verifica las correcciones | Hallazgos con evidencia, severidad y una ruta de remediación | Reporting |
En el hacking ético, el reconocimiento pasivo casi no deja rastro, mientras que el activo eleva bastante la probabilidad de detección. La cuarta fase es donde, como lo ha dicho Andres Roldan, VP of Hacking de Fluid Attacks, el hacking ético se separa de una herramienta automatizada: la herramienta identifica, la persona explota.
Estas fases no son una convención privada. Fluid Attacks mapea sus requisitos de seguridad a metodologías reconocidas en su Database: 41 definiciones de control de PTES y 12 de NIST SP 800-115, mapeadas a 51 y 25 requisitos.
Lógica de negocio: lo que el hacking ético alcanza y los escáneres no
Las vulnerabilidades de lógica de negocio son fallas en lo que una aplicación tiene permitido hacer, no en cómo está programada. La aplicación funciona exactamente como fue escrita; las reglas que impone están mal. Ninguna herramienta de coincidencia de patrones las reconoce, porque no hay patrón: solo un proceso que el hacking ético demuestra que nunca debió completarse.
La OWASP Web Security Testing Guide v4.2 les dedica una categoría completa, la sección 4.10, cuyas nueve pruebas se leen como cosas que solo una persona puede intentar: falsificar peticiones, romper verificaciones de integridad, abusar de los tiempos de un proceso y saltarse flujos de trabajo por completo.
El catálogo de Fluid Attacks tiene las versiones concretas. La debilidad 013, referencia insegura a objetos, describe un mecanismo de autorización que "does not prevent one user from accessing another users data by modifying the key value that identifies it", mapeada al requisito 176. La debilidad 005 cubre la escalación de privilegios y la debilidad 014 cubre la funcionalidad insegura: una función que forma parte del sistema y que un atacante puede usar para dañarlo.
Una falla de autorización en una aplicación que por lo demás funciona: debilidad 013, requisito 176.
Lo que convierte esto en hallazgos es el pivoting, que la documentación de comparación de Fluid Attacks define como explotar vulnerabilidades "together or one after the other", para encontrar rutas de ataque con impactos más severos que explotar cada una por separado. En el hacking ético, una falla de severidad media suele ser crítica una vez que se demuestra que es el primer paso de una cadena.
Cómo el hacking ético reporta y divulga vulnerabilidades
El reporte cierra el ciclo dentro de la organización del cliente; la divulgación lo cierra con todos los demás. El hacking ético usa marcos públicos para ambos: identificadores CVE para nombrar una vulnerabilidad sin ambigüedad y CVSS para comunicar su severidad.
La investigación sobre software de terceros termina en otro lado. El programa CVE autoriza a unas organizaciones que llama CNAs — "vendor, researcher, open source, CERT, hosted service, bug bounty provider, and consortium organizations" — a asignar identificadores y publicar registros dentro de su propio alcance. Hoy hay 564 CNAs de 43 países.
Fluid Attacks es una de ellas desde el 2 de junio de 2021, admitida por MITRE como CNA de tipo investigador. Como escribió Andres Roldan, VP of Hacking, al analizar el desempeño de los CNAs investigadores:
"Our scope is any software that is not within the scope of other CNAs".
En la práctica eso es el listado público de advisories, filtrable por quién encontró cada vulnerabilidad: el escáner de AI SAST, los pentesters propios de Fluid Attacks o pentesters externos. Las entradas recientes nombran al investigador: Andres Ramos, por una inyección de comandos del sistema operativo en PingTools Network Utilities 4.64, con puntuación 8.6 High. Así se ve encontrar vulnerabilidades de día cero y practicar la divulgación responsable cuando está documentado y no solo declarado.
Cada advisory nombra al investigador que lo encontró y el CVE asignado.
La misma disciplina corre al revés. Fluid Attacks prueba su propia tecnología con técnicas automatizadas y manuales, corre pipelines que incluyen exploits y linters estrictos, y opera un programa de bug bounty abierto a cualquiera, con recompensas según el impacto. Cuando un investigador externo reporta algo, el equipo de respuesta acuerda con él una fecha de publicación y le pregunta si quiere crédito.
Dentro de un trabajo, el hacking ético termina con verificación y no con un PDF: los reataques manuales son ilimitados y una persona vuelve a probar cada hallazgo manual.
Herramientas, habilidades y certificaciones del hacking ético
Las herramientas aceleran el hacking ético; no lo ejecutan. Fluid Attacks publica el instrumental que usan sus analistas — 59 herramientas, actualizado el 3 de noviembre de 2026 — y describe su papel con precisión: "the security analysts of Fluid Attacks use the automation of these tools to make their security testing faster".
El instrumental está publicado y fechado: 59 herramientas, al 3 de noviembre de 2026.
Propósito | Herramientas |
|---|---|
Descubrimiento de superficie de ataque | Amass, DNSRecon, Nmap |
Aplicaciones web | Burp Suite Professional, ffuf, sqlmap, OWASP ZAP, Vega |
Aplicaciones móviles | Frida, MobSF, Objection, jadx, Apktool |
Redes e inalámbricos | bettercap, Aircrack-ng, Wireshark, mitmproxy |
Active Directory | BloodHound, CrackMapExec, Rubeus, mimikatz |
Entornos en la nube | Pacu, enumerate-iam, AWS CLI |
Ghidra, Hopper, dnSpy, x64dbg, reFlutter | |
Credenciales y secretos | hashcat, John the Ripper, Hydra, Gitleaks, TruffleHog |
Desarrollo de exploits | Metasploit, BeEF, GDB-PEDA |
Las habilidades deciden más que cualquiera de ellas. Los pentesters de Fluid Attacks tienen 202 certificaciones de 59 tipos distintos, y sus acreditaciones incluyen penetration testing por CREST además del estatus de CNA. Son empleados, no colaboradores pagados por hallazgo.
▶️ Video: un meetup sobre cómo certificarse en pentesting de IA con las credenciales AIRTP+ y C-AI/MLPen.
Para profundizar: cómo convertirse en un hacker ético cubre el terreno técnico y no técnico que hay detrás del hacking ético como carrera.
Quién necesita hacking ético y cómo elegir un proveedor
Donde un estándar o un regulador pide una prueba de penetración, el hacking ético deja de ser opcional: el servicio de Fluid Attacks valida requisitos de 67 estándares. El caso es más amplio que el cumplimiento: cualquier organización que desarrolle su propio software o exponga productos en Internet es un objetivo, y los ciberataques como el ransomware y el phishing no consultan primero el tamaño de la empresa.
Elegir un proveedor de hacking ético es más fácil con preguntas concretas que con folletos:
¿Quién hace las pruebas? Empleados con contrato, o un grupo rotativo de investigadores independientes.
¿Cuántas certificaciones y de qué tipos? Pide el conteo, no adjetivos.
¿El servicio explota o solo reporta? Explotar y pivotear son capacidades distintas de detectar.
¿Hay investigación propia? Los advisories publicados muestran si un proveedor encuentra vulnerabilidades de día cero o solo lee sobre ellas.
¿Cómo se verifican las correcciones? Pregunta cuántos reataques manuales incluye y quién los ejecuta.
¿Cómo se mide la exactitud? Reportar los propios falsos negativos contra un SLA es una promesa más difícil que reportar hallazgos.
Conclusiones
El hacking ético se gana su lugar en un programa de seguridad por una razón: produce evidencia de explotabilidad que ningún otro método produce. Un escáner te dice que una puerta no tiene cerradura. El hacking ético la cruza y te dice qué hay en el cuarto.
Esa evidencia cuesta tiempo, y fingir lo contrario no ayuda a nadie. Las personas no trabajan al ritmo de una máquina, y por eso el hacking ético va al lado de las pruebas automatizadas y no en su lugar: automatización para amplitud y patrones conocidos, personas para lógica de negocio y para todo lo que está detrás de autenticación.
Los proveedores que vale la pena contratar te muestran su metodología, sus acreditaciones y su investigación publicada antes de que firmes nada.
Preguntas frecuentes
¿Qué puede encontrar un hacker ético que un escáner no?
Vulnerabilidades de lógica de negocio, cadenas de ataque y casi todo lo que está detrás de autenticación. En el benchmark de Fluid Attacks contra una aplicación web con 1.201 vulnerabilidades conocidas, un pentester encontró 743 que ninguna herramienta automatizada encontró: el 61,9 % del total, con el 86,8 % de la exposición al riesgo. El escaneo por sí solo cubre entre el 10 % y el 30 % de la exposición al riesgo de un sistema.
¿Hacking ético y pentesting son lo mismo?
No. Un pentest es una forma de hacking ético, y un ejercicio de red team también; el hacking ético es la categoría más amplia que cubre ambos. Un pentest pregunta qué se puede explotar en un objetivo definido. Un ejercicio de red team pregunta si la organización detectaría a un adversario real y respondería.
¿Qué son las vulnerabilidades de lógica de negocio?
Fallas en lo que una aplicación permite, más que en cómo está escrita. El código corre bien y las reglas que impone están mal: un usuario que aprueba su propia transacción, un flujo completado fuera de orden, una función usada más veces de las permitidas. La OWASP Web Security Testing Guide v4.2 les dedica la sección 4.10 y nueve pruebas distintas.
¿Cómo funciona la divulgación responsable?
El investigador reporta la falla en privado a quien sea dueño del software y acuerda una fecha de publicación para que la corrección salga primero. Antes de reportarla, reúne evidencia. Una CVE Numbering Authority asigna un identificador y el advisory se publica después. El programa lista 564 CNAs de 43 países.
¿Fluid Attacks hace hacking ético y cómo se verifica?
Sí, de forma continua, sobre los sistemas de sus clientes bajo el plan Advanced, que incluye Pentesting as a Service (PTaaS), Secure Code Review e ingeniería inversa. Cada hallazgo pasa una revisión entre pares de nueve puntos antes de que el cliente lo vea, los reataques manuales son ilimitados y el servicio tiene un SLA de exactitud del 90 % medido con F-scores ponderados por severidad.
Pon a un hacker antes de que lo haga alguien más
Nuestro PTaaS lleva hacking ético a tus aplicaciones de forma continua, bajo reglas que tú apruebas, y demuestra cuánto vale una vulnerabilidad antes de que te cueste algo. Prueba gratuita · Contáctanos.
Empieza ya con el PTaaS de Fluid Attacks
