1. Introducción
El hacking ético es una actividad profesional de ciberseguridad mediante la cual una persona especializada —habitualmente denominada ethical hacker, auditor de seguridad o penetration tester— analiza sistemas informáticos, redes, aplicaciones y dispositivos para identificar vulnerabilidades antes de que sean explotadas por atacantes.
Desde el punto de vista técnico, el hacker ético puede emplear conocimientos, herramientas y técnicas similares a las utilizadas por un ciberdelincuente. La diferencia esencial no está en el programa utilizado, sino en la autorización previa, la finalidad defensiva, el alcance convenido, la proporcionalidad de las pruebas y el tratamiento responsable de la información obtenida.
Por tanto, el hacking ético no puede definirse simplemente como «hackear con buenas intenciones». Para que la actividad sea jurídicamente legítima debe desarrollarse dentro de un marco previamente autorizado, documentado, limitado y controlado.
2. ¿Qué es una vulnerabilidad informática?
Una vulnerabilidad es una debilidad técnica, lógica, organizativa o humana que puede ser aprovechada para comprometer la seguridad de un sistema.
Los tres atributos tradicionales de seguridad son:
- Confidencialidad: la información solo puede ser conocida por personas o sistemas autorizados.
- Integridad: los datos y programas no son modificados de manera indebida.
- Disponibilidad: los servicios, sistemas e información permanecen accesibles cuando son necesarios.
También pueden afectarse la autenticidad, la trazabilidad, la privacidad, la no repudiación y el control de acceso.
Las vulnerabilidades pueden originarse en errores de programación, configuraciones inseguras, credenciales débiles, software desactualizado, falta de cifrado, permisos excesivos, dependencias vulnerables, mala segmentación de redes, errores de lógica de negocio o procedimientos internos deficientes.
3. Auditoría, análisis de vulnerabilidades y prueba de penetración
3.1. Auditoría de seguridad
Examina políticas, procedimientos, configuraciones, controles y evidencias para determinar el nivel de cumplimiento de requisitos jurídicos, técnicos o normativos.
3.2. Análisis de vulnerabilidades
Identifica debilidades conocidas mediante herramientas automáticas y comprobaciones manuales. Su resultado suele ser una lista priorizada de posibles vulnerabilidades, pero no siempre demuestra que puedan explotarse en el entorno concreto.
3.3. Prueba de penetración
Procura comprobar de forma controlada si una vulnerabilidad puede explotarse y cuál sería su impacto real. Puede analizar acceso indebido, elevación de privilegios, exposición de información, desplazamiento entre sistemas y eficacia de los mecanismos de detección.
3.4. Red Team
Una operación de Red Team simula un adversario real y puede combinar pruebas de red, aplicaciones, ingeniería social, seguridad física, comunicaciones inalámbricas y evasión de controles. Por su mayor riesgo, exige reglas de actuación especialmente detalladas.
4. Modalidades de evaluación
| Modalidad | Información previa | Utilidad principal |
|---|---|---|
| Caja negra | Muy limitada. | Simular a un atacante externo sin conocimiento interno. |
| Caja blanca | Código, documentación, credenciales y arquitectura. | Lograr una evaluación profunda y eficiente. |
| Caja gris | Información y permisos parciales. | Simular a un usuario, trabajador o proveedor con acceso limitado. |
5. Metodología técnica del hacking ético
Una prueba profesional no consiste en ejecutar indiscriminadamente herramientas automáticas. Debe seguir una metodología planificada, reproducible y compatible con el riesgo del sistema evaluado.
5.1. Planificación y alcance
La primera etapa define dominios, subdominios, direcciones IP, aplicaciones, APIs, redes, servidores, dispositivos, entornos de nube y demás activos incluidos. También determina expresamente qué elementos quedan excluidos.
5.2. Reconocimiento
El reconocimiento pasivo obtiene información públicamente disponible: DNS, certificados, motores de búsqueda, repositorios, metadatos y tecnologías visibles. El reconocimiento activo interactúa con el sistema para identificar puertos, servicios, versiones y respuestas.
5.3. Enumeración de la superficie de ataque
Se identifican servicios, aplicaciones, puntos de autenticación, formularios, APIs, paneles administrativos, cargas de archivos, sistemas heredados, recursos en la nube e integraciones con terceros.
5.4. Identificación de vulnerabilidades
Se combinan herramientas automáticas con revisión manual. Los resultados deben validarse porque pueden existir falsos positivos, falsos negativos o conclusiones descontextualizadas.
5.5. Explotación controlada
Cuando el contrato lo permite, se demuestra prudentemente la explotabilidad del hallazgo. Debe aplicarse el principio de mínima intervención: obtener solamente la evidencia necesaria, sin descargar bases completas ni causar daños.
5.6. Escalamiento de privilegios y movimiento lateral
Puede verificarse si una cuenta de bajo nivel permite obtener permisos superiores o alcanzar otros sistemas. Ambas actividades deben estar expresamente comprendidas en el alcance.
5.7. Persistencia
La instalación de mecanismos de persistencia debe evitarse salvo autorización expresa y necesidad técnica. Nunca deben quedar puertas traseras permanentes.
5.8. Limpieza y restauración
Al finalizar deben eliminarse cuentas, archivos, herramientas, tokens, reglas temporales y datos extraídos, dejando constancia de la restauración del entorno.
5.9. Informe y nueva comprobación
El informe ejecutivo traduce el riesgo al lenguaje de la organización. El informe técnico documenta el activo afectado, evidencia, impacto, criticidad, condiciones de explotación y medidas correctivas. Una nueva prueba o retest verifica la remediación.
6. Herramientas y lenguajes
6.1. Herramientas habituales
- Nmap: descubrimiento de equipos, puertos y servicios.
- Wireshark: análisis de tráfico de red.
- Burp Suite y OWASP ZAP: pruebas sobre aplicaciones web y APIs.
- Greenbone/OpenVAS y Nessus: análisis y gestión de vulnerabilidades.
- Metasploit Framework: validación controlada de vulnerabilidades.
- MobSF: análisis de aplicaciones móviles.
- Ghidra: ingeniería inversa y análisis de programas.
- Docker y máquinas virtuales: construcción de laboratorios aislados.
Las herramientas son de uso dual: su valoración jurídica depende de la autorización, finalidad, contexto, alcance y forma concreta de utilización.
6.2. Lenguajes utilizados
- Python: automatización, APIs, procesamiento de resultados y pruebas de concepto.
- Bash: automatización y administración en GNU/Linux.
- PowerShell: entornos Windows, Active Directory, Microsoft 365 y Azure.
- JavaScript y TypeScript: aplicaciones web, navegadores, Node.js y APIs.
- Go: herramientas concurrentes, rápidas y portables.
- C y C++: análisis de memoria, sistemas, controladores y dispositivos embebidos.
- Java, C# y PHP: revisión de aplicaciones empresariales desarrolladas en esos ecosistemas.
7. La autorización como presupuesto jurídico
La autorización constituye el principal límite entre una evaluación legítima y una posible conducta ilícita. Debe provenir de una persona con facultades suficientes sobre el sistema y abarcar los activos, técnicas, horarios y finalidades de la intervención.
La organización contratante puede carecer de competencia para autorizar pruebas sobre componentes pertenecientes a proveedores de nube, procesadores de pago, casas matrices, servicios compartidos o APIs de terceros.
8. Ley N.º 20.327 y delitos informáticos
La Ley N.º 20.327, promulgada en 2024, incorporó y modificó figuras vinculadas con la ciberdelincuencia, entre ellas el acceso ilícito a datos, la interceptación ilícita, la vulneración de datos, el fraude informático, el daño informático, la suplantación de identidad y el abuso de dispositivos.
8.1. Acceso ilícito a datos informáticos
El artículo 297 BIS del Código Penal sanciona determinadas conductas realizadas sin autorización y sin justa causa respecto de información ajena contenida en soporte digital. Una contratación legítima no habilita a acceder a sistemas o datos excluidos del alcance.
8.2. Interceptación ilícita
El artículo 297 TER resulta especialmente relevante para la captura de tráfico, análisis de redes inalámbricas, interceptación de sesiones o comunicaciones no públicas. Estas técnicas deben limitarse a redes, equipos y comunicaciones expresamente autorizados.
8.3. Vulneración de datos
El acceso, utilización, modificación, revelación o cesión no autorizada de información confidencial puede generar consecuencias penales. La evidencia debe reducirse a la mínima cantidad necesaria para acreditar el hallazgo.
8.4. Daño informático
Las pruebas deben excluir o controlar rigurosamente técnicas capaces de interrumpir servicios, corromper bases de datos, eliminar información, bloquear cuentas o saturar recursos.
8.5. Abuso de dispositivos
La posesión o utilización de una herramienta de seguridad no es automáticamente ilícita. No obstante, el profesional debería documentar su origen legítimo, la finalidad defensiva, el contrato, los activos evaluados y la custodia de credenciales o evidencias.
9. Contrato y reglas de actuación
La autorización debería formalizarse mediante un contrato y un documento técnico de Rules of Engagement o reglas de actuación.
- Identidad y facultades de las partes.
- Objetivo de la evaluación.
- Activos incluidos y excluidos.
- Fechas, horarios y direcciones de origen.
- Técnicas autorizadas y prohibidas.
- Uso o exclusión de ingeniería social y denegación de servicio.
- Tratamiento de credenciales y datos personales.
- Condiciones de detención inmediata.
- Contactos técnicos, jurídicos y de emergencia.
- Comunicación de hallazgos críticos.
- Conservación y destrucción de evidencias.
- Confidencialidad, responsabilidad y subcontratación.
- Remediación, nueva prueba y utilización del informe.
- Legislación y jurisdicción aplicables.
10. Protección de datos personales
La Ley N.º 18.331 establece el régimen uruguayo de protección de datos personales. El principio de seguridad exige condiciones técnicas y organizativas adecuadas, mientras que el principio de reserva obliga a quienes obtienen legítimamente información proveniente de bases de datos.
Cuando el auditor accede a datos personales puede quedar sujeto a obligaciones de confidencialidad, seguridad, minimización, limitación de finalidad, conservación limitada, eliminación segura y prohibición de reutilización.
Los datos obtenidos durante una prueba no deberían reutilizarse en publicaciones, clases, demostraciones o portafolios sin base jurídica suficiente y medidas de anonimización adecuadas.
11. Vulneraciones de seguridad y comunicación de incidentes
La Ley N.º 19.670 y el Decreto N.º 64/020 regulan la comunicación de vulneraciones de seguridad que afecten datos personales. La reglamentación establece procedimientos de mitigación, documentación y comunicación a la Unidad Reguladora y de Control de Datos Personales, incluyendo el plazo máximo de 72 horas en los supuestos aplicables.
El contrato de hacking ético debe prever quién recibe el hallazgo, quién activa el protocolo de incidentes, cómo se preserva la evidencia, quién realiza las comunicaciones regulatorias y cómo se notifica a los titulares afectados.
Para entidades comprendidas en el marco nacional de ciberseguridad, el Decreto N.º 66/025 y las directrices de Agesic también deben ser considerados, especialmente respecto de la comunicación de incidentes al CERTuy.
12. Responsabilidad civil, confidencialidad y propiedad intelectual
12.1. Responsabilidad civil
El artículo 1319 del Código Civil recoge el principio general de responsabilidad por hechos ilícitos dañosos. El auditor puede responder contractual o extracontractualmente si interrumpe servicios, elimina información, expone datos, actúa fuera del alcance o incumple su deber profesional de diligencia.
12.2. Confidencialidad y secreto empresarial
Durante la prueba pueden conocerse arquitecturas, código fuente, contraseñas, claves, información comercial, documentos, datos de clientes y vulnerabilidades todavía no corregidas. La obligación de confidencialidad debe continuar después de finalizado el contrato.
12.3. Propiedad intelectual e ingeniería inversa
El cliente no siempre es titular del código ni posee facultades para autorizar su descompilación o análisis. Deben revisarse la Ley N.º 9.739, los contratos y las licencias aplicables al software.
13. Nube, terceros y servicios críticos
En entornos de nube deben examinarse las políticas del proveedor. El contrato con el cliente no autoriza necesariamente a atacar infraestructura compartida, escanear rangos ajenos, saturar servicios o acceder a datos de otros clientes.
Las pruebas sobre organismos públicos, salud, energía, telecomunicaciones, finanzas u otras infraestructuras críticas requieren especial coordinación con responsables técnicos, jurídicos, de protección de datos y de respuesta a incidentes.
14. Divulgación responsable de vulnerabilidades
La divulgación coordinada consiste en comunicar privadamente una vulnerabilidad al responsable del sistema y conceder un plazo razonable para corregirla antes de publicar información.
Quien encuentre accidentalmente una falla debería detener la exploración, no elevar privilegios, no descargar bases de datos, no modificar información, conservar solamente evidencia mínima y utilizar un canal oficial de comunicación.
Una política de divulgación o un programa de recompensas debería definir sistemas incluidos, técnicas autorizadas, conductas prohibidas, tratamiento de datos, forma de informar, plazos y condiciones de publicación.
15. Principios éticos fundamentales
- Autorización: no realizar pruebas activas sin permiso suficiente.
- Necesidad: ejecutar solamente las acciones requeridas.
- Proporcionalidad: preferir la técnica menos invasiva.
- Minimización: acceder a la menor cantidad posible de datos.
- Confidencialidad: proteger vulnerabilidades, credenciales y evidencias.
- Trazabilidad: registrar acciones, horarios, activos y resultados.
- Integridad y disponibilidad: evitar alteraciones e interrupciones.
- Competencia profesional: no ejecutar técnicas que no puedan controlarse.
- Limpieza: retirar accesos, herramientas y datos temporales.
16. Aprendizaje seguro y seguridad en el desarrollo
La formación debe realizarse en máquinas virtuales, redes aisladas, contenedores, aplicaciones deliberadamente vulnerables, plataformas educativas, ejercicios Capture The Flag y programas de recompensas con reglas claras.
La seguridad también debe integrarse al ciclo de desarrollo mediante modelado de amenazas, revisión de arquitectura, análisis estático y dinámico, control de dependencias, detección de secretos, pruebas de APIs, seguridad de contenedores y evaluaciones periódicas.
17. Limitaciones de una prueba de penetración
Una evaluación no garantiza seguridad absoluta. Sus resultados dependen del alcance, tiempo, información suministrada, técnicas autorizadas, experiencia del equipo, restricciones operativas y estado del sistema durante la prueba.
El informe representa una fotografía temporal. Una actualización, nueva funcionalidad, dependencia vulnerable o cambio de configuración puede modificar rápidamente el riesgo.
18. Conclusiones
El hacking ético es una herramienta indispensable para gestionar riesgos tecnológicos, pero su legitimidad no depende únicamente de la buena intención del profesional.
Requiere autorización previa y documentada, alcance preciso, reglas de actuación, proporcionalidad, minimización de datos, confidencialidad, coordinación institucional, procedimientos ante incidentes, informe profesional, remediación y nueva evaluación.
La capacidad técnica permite descubrir vulnerabilidades. La metodología, la prudencia y el Derecho determinan si esa capacidad se utiliza de manera profesional, segura y legítima.
Fuentes normativas y técnicas
- Ley N.º 20.327 — Ciberdelincuencia (IMPO).
- Ley N.º 18.331 — Protección de datos personales (IMPO).
- Ley N.º 19.670, artículo 38 — Vulneraciones de seguridad (IMPO).
- Decreto N.º 64/020 — Reglamentación en materia de protección de datos (IMPO).
- Decreto N.º 66/025 — Marco de ciberseguridad (IMPO).
- Código Civil, artículo 1319 — Responsabilidad civil (IMPO).
- Ley N.º 9.739 — Propiedad intelectual (IMPO).
- CERTuy — Agesic.
- OWASP Web Security Testing Guide.
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment.
- ISO/IEC 27001 — Sistemas de gestión de seguridad de la información.
Advertencia
Este artículo tiene finalidad informativa, académica y general. No constituye autorización para realizar pruebas sobre sistemas ajenos ni sustituye el análisis técnico y jurídico de un caso concreto.