El hacking ético consiste en evaluar la seguridad de sistemas con autorización explícita y por escrito, dentro de un alcance acordado y con el objetivo de reducir riesgos. Lo que separa esta práctica de un delito no es la herramienta ni la técnica: es el permiso, el alcance, la intención y la trazabilidad. Las mismas acciones que dentro de un contrato son un servicio profesional, fuera de él pueden constituir un acceso ilegítimo penado por ley.
Ver índice de contenidos
- 01Qué convierte una práctica en hacking ético
- 02El marco legal, en concreto
- 03El documento de alcance
- 04Metodología por fases
- 05Cómo montar un laboratorio seguro
- 06Dónde practicar legalmente
- 07Cómo se prioriza un hallazgo
- 08Qué debe contener un informe
- 09Ética, privacidad y datos
- 10Errores frecuentes al empezar
- 11Preguntas frecuentes
- 12Fuentes
Qué convierte una práctica en hacking ético
La pregunta que más se repite entre quienes empiezan es dónde está el límite. La respuesta es menos difusa de lo que parece, porque se apoya en cuatro condiciones que se verifican de forma objetiva.
Alguien con facultad para otorgarla dio permiso por escrito. No basta con que te lo pida un compañero de trabajo.
Está definido qué activos, en qué ventana horaria y con qué técnicas. Todo lo que no esté incluido, está excluido.
El objetivo es reducir el riesgo de la organización, no obtener ventaja, notoriedad ni información para otro uso.
Queda registro de qué se hizo y cuándo. Sin eso no se puede demostrar que se respetó el alcance.
Que un sistema sea accesible no significa que esté disponible para probarlo. La puerta abierta de una casa ajena sigue siendo una casa ajena.
Conviene además distinguir modalidades que suelen confundirse. Un análisis de vulnerabilidades identifica debilidades conocidas, normalmente con herramientas automatizadas y sin explotarlas. Un test de intrusión valida de forma controlada si esas debilidades son realmente aprovechables. Un ejercicio de equipo rojo simula un adversario concreto para medir la capacidad de detección y respuesta, y suele tener un alcance mucho más amplio y menos anunciado. Confundirlos en una propuesta comercial genera expectativas que después no se cumplen.
El marco legal, en concreto
En Argentina, la Ley 26.388, sancionada en 2008, incorporó los delitos informáticos al Código Penal. Entre otras figuras, tipificó el acceso ilegítimo a un sistema o dato informático de acceso restringido, además de conductas relacionadas con la interceptación de comunicaciones y el daño a datos y sistemas. No hace falta causar un perjuicio económico ni extraer información: el acceso sin autorización ya está contemplado en sí mismo.
Esto tiene tres consecuencias prácticas para quien está aprendiendo:
- Escanear no es inocuo. Aunque un escaneo de puertos sea técnicamente pasivo, se realiza contra un sistema ajeno y puede interpretarse como acto preparatorio.
- La buena intención no es una defensa automática. Avisar después de haber accedido no borra el acceso previo.
- El alcance protege a las dos partes. Al profesional lo ampara frente a una acusación; a la organización le da control sobre lo que ocurre en sus sistemas.
Esta sección es informativa y no constituye asesoramiento legal. La legislación varía según el país y cambia con el tiempo. Ante una situación concreta, consultá con un profesional del derecho de tu jurisdicción.
El documento de alcance
Es el documento que convierte una intención en un trabajo legítimo. Se firma antes de tocar nada y debería responder, como mínimo, a lo siguiente:
- Quién autoriza y con qué facultad. Si el sistema está alojado por un tercero, puede hacer falta también su permiso.
- Qué activos entran: dominios, rangos de IP, aplicaciones, cuentas de prueba. Enumerados, no descritos en general.
- Qué queda expresamente fuera: sistemas de terceros, entornos de producción críticos, datos de personas reales.
- Ventana horaria y si hay períodos prohibidos, como cierres contables o fechas de alta demanda.
- Técnicas excluidas: típicamente denegación de servicio, ingeniería social sobre personas concretas o acciones destructivas.
- Manejo de datos: qué se puede ver, qué no se debe copiar, cómo se guarda la evidencia y cuándo se destruye.
- Contactos de emergencia y procedimiento si algo se cae o si se encuentra evidencia de un compromiso previo.
- Entregables y plazos: qué informe se entrega, en qué formato y a quién.
El punto sobre evidencia de un compromiso previo se olvida seguido y es el más delicado: si durante la evaluación aparecen indicios de que alguien más ya está dentro, el procedimiento cambia por completo y hay que escalarlo de inmediato en lugar de seguir probando.
Metodología por fases
Las metodologías reconocidas —PTES, la OWASP Web Security Testing Guide y la guía NIST SP 800-115— difieren en el detalle pero coinciden en la estructura general.
- Alcance y autorizaciónSe define y se firma qué se va a evaluar, cuándo y con qué límites. Sin este paso, no hay nada más.
- ReconocimientoEntender la superficie expuesta: tecnologías, servicios, puntos de entrada. Siempre dentro de lo autorizado.
- Análisis de riesgosOrdenar las debilidades detectadas por impacto y probabilidad, en lugar de perseguir la más llamativa.
- Validación controladaConfirmar que un problema es real, con el mínimo cambio posible y sin exponer datos innecesarios.
- DocumentaciónEvidencia, impacto, pasos de reproducción y recomendaciones concretas de corrección.
- ReverificaciónComprobar que la mitigación aplicada funciona. Sin este paso, el trabajo queda a medias.
La fase de validación es donde se define el profesionalismo. La diferencia entre confirmar que una falla existe y aprovecharla a fondo es enorme: lo primero es lo que se contrató, lo segundo suele exceder el alcance y multiplica el riesgo para todos.
Cómo montar un laboratorio seguro
La forma correcta de aprender es en un entorno propio donde no puedas afectar a nadie. Con virtualización alcanza y sobra para empezar.
Reglas mínimas
- Red aislada. Configurá las máquinas virtuales en modo host-only o en una red interna sin salida. El error más común es dejarlas en modo puente y exponerlas a la red doméstica.
- Snapshots antes de cada prueba. Te permiten volver a un estado conocido en segundos y repetir un escenario tantas veces como haga falta.
- Nada de datos reales. Ni credenciales que uses en otros servicios, ni copias de bases de datos de trabajo, ni información personal de nadie.
- Documentá como si fuera un cliente. Acostumbrarte a registrar en el laboratorio es lo que hace que después te salga natural.
- Separá las cuentas. El laboratorio no debería compartir sesiones ni gestores de contraseñas con tu vida cotidiana.
Para el objetivo vulnerable no hace falta inventar nada: existen aplicaciones diseñadas expresamente para practicar, mantenidas por proyectos abiertos, que traen fallas documentadas y guías de solución.
Dónde practicar legalmente
Fuera de tu laboratorio, la única práctica legítima es en plataformas que lo autorizan de forma expresa en sus reglas.
| Opción | Qué ofrece | Para quién |
|---|---|---|
| Aplicaciones vulnerables locales | Software que instalás en tu propia máquina virtual, con fallas conocidas y documentadas | Primeros pasos, sin depender de conexión ni de terceros |
| Laboratorios web guiados | Ejercicios progresivos por tipo de vulnerabilidad, con teoría y verificación automática | Aprender un tema concreto en profundidad |
| Plataformas de desafíos y CTF | Máquinas y retos con dificultad creciente y comunidad activa | Practicar metodología completa y sostener la constancia |
| Programas de divulgación de vulnerabilidades | Sistemas reales cuyas organizaciones publican reglas de participación | Cuando ya tenés método y sabés leer un alcance |
En el último caso, la regla es leer las condiciones antes que la aplicación. Cada programa define qué dominios entran, qué técnicas están prohibidas y cómo reportar. Salirse de ahí deja de estar cubierto por la autorización.
Cómo se prioriza un hallazgo
Encontrar problemas es la parte fácil. Lo que aporta valor es explicar cuáles importan primero, y para eso conviene apoyarse en criterios reconocidos en lugar de una opinión.
- CVSS (Common Vulnerability Scoring System), mantenido por FIRST, produce una puntuación a partir de características como el vector de ataque, la complejidad, los privilegios necesarios y el impacto sobre confidencialidad, integridad y disponibilidad.
- CVE es el identificador público de una vulnerabilidad conocida; la NVD del NIST agrega el análisis y las puntuaciones asociadas.
- OWASP Top 10 agrupa las categorías de riesgo más habituales en aplicaciones web y sirve para comunicar hallazgos en un lenguaje que muchos equipos ya conocen.
- MITRE ATT&CK cataloga tácticas y técnicas de adversarios reales, y es especialmente útil para conectar un hallazgo con lo que un atacante podría hacer a continuación.
Una puntuación alta no siempre significa prioridad alta. Una falla crítica en un sistema aislado sin datos sensibles puede importar menos que una media en el que procesa los pagos. La puntuación es un insumo, no la decisión.
Qué debe contener un informe
El informe es el producto real del trabajo. Un hallazgo que no se entiende no se corrige, y entonces la evaluación no sirvió para nada.
Qué se evaluó, qué riesgo hay hoy y qué conviene hacer primero. En lenguaje comprensible para quien decide el presupuesto.
Qué se probó y, sobre todo, qué no. Sin esto, el informe se lee como si cubriera todo.
Descripción, impacto concreto, pasos de reproducción, evidencia suficiente y referencia a un criterio reconocido.
Acciones concretas, responsable sugerido y cómo verificar que quedó resuelto.
Dos cuidados que distinguen un informe profesional: la evidencia debe ser suficiente pero no excesiva —una captura que demuestre el acceso, no un volcado de la base de datos— y las recomendaciones deben ser accionables. «Mejorar la seguridad del servidor» no es una recomendación; «restringir el acceso al panel administrativo a la red interna y forzar segundo factor» sí lo es.
Ética, privacidad y datos
Durante una evaluación es habitual encontrarse con información que no se estaba buscando: credenciales, datos personales, comunicaciones internas. El criterio profesional es el de mínima recolección.
- Accedé a lo mínimo necesario para demostrar el problema y detenete ahí.
- No copies información personal a tu equipo si podés demostrarlo con una captura parcial y ofuscada.
- Protegé la evidencia mientras exista: cifrada, con acceso limitado y con fecha de destrucción acordada.
- Respetá los plazos de divulgación. Publicar un hallazgo antes de que exista corrección expone a personas que no eligieron ese riesgo.
- Si encontrás material que sugiere un delito en curso, no sigas: escalá según el procedimiento definido en el alcance.
Errores frecuentes al empezar
- Empezar por las herramientas. Sin entender redes, sistemas y web, una herramienta produce resultados que no vas a poder interpretar ni defender.
- Practicar contra sistemas ajenos «para probar». Es el error que arruina carreras antes de empezarlas.
- Dejar el laboratorio en modo puente. Convierte una práctica controlada en tráfico real hacia tu red.
- Confundir cantidad de hallazgos con calidad. Veinte avisos automáticos sin verificar valen menos que tres problemas confirmados y bien explicados.
- Copiar comandos sin entenderlos. En seguridad, un comando mal comprendido puede destruir datos o dejar rastros que después no sabés explicar.
- No documentar durante el trabajo. Reconstruir de memoria al final produce informes imprecisos y pierde evidencia.
Preguntas frecuentes
¿Puedo practicar contra cualquier sitio público?
No. Que un sistema sea accesible desde Internet no implica autorización para probarlo. Practicá únicamente en tu propio laboratorio, en plataformas creadas para eso o en programas de divulgación de vulnerabilidades cuyas reglas indiquen expresamente qué está permitido. Sin permiso, escanear o intentar acceder puede constituir un delito.
¿Necesito autorización por escrito o alcanza con un permiso verbal?
Siempre por escrito. La autorización tiene que identificar quién la otorga y con qué facultad, qué activos abarca, en qué ventana horaria, qué técnicas quedan excluidas y a quién avisar ante un incidente. Un permiso verbal no te protege si algo sale mal ni sirve como prueba después.
¿Qué debería aprender primero?
Redes y TCP/IP, administración de Linux, funcionamiento de la web y HTTP, programación básica y nociones de gestión de riesgos. Las herramientas se aprenden rápido cuando entendés qué está pasando por debajo; al revés, se convierten en botones que producen resultados que no sabés interpretar.
¿Hacking ético y pentesting son lo mismo?
No exactamente. El hacking ético es el marco general de evaluar seguridad con autorización y fines de mejora. Un test de intrusión es un servicio concreto, acotado en tiempo y alcance, con objetivos y entregables definidos. También existen otras modalidades como el análisis de vulnerabilidades, la revisión de configuración o los ejercicios de equipo rojo.
¿Qué hago si encuentro una vulnerabilidad grave por casualidad?
Detené la exploración, no accedas a más datos de los estrictamente necesarios para confirmar el problema, documentá lo mínimo indispensable y buscá el canal de contacto de seguridad de la organización, por ejemplo un archivo security.txt o una política de divulgación publicada. No difundas el hallazgo antes de que exista una corrección o un plazo acordado.
¿Sirve de algo un informe si no encontré nada?
Sí, y es una situación habitual. El informe documenta qué se probó, con qué alcance, con qué técnicas y qué limitaciones tuvo la evaluación. Eso permite saber qué quedó sin cubrir y da una línea de base para la próxima revisión. Un informe sin hallazgos no equivale a un sistema seguro: equivale a que en ese alcance y en ese momento no se encontró nada.
Fuentes
Documentación oficial, estándares y normativa consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
- NIST. SP 800-115: Technical Guide to Information Security Testing and Assessment. Estructura de una evaluación técnica de seguridad.
- OWASP. Web Security Testing Guide. Metodología de prueba para aplicaciones web.
- OWASP. OWASP Top 10. Categorías de riesgo más habituales en aplicaciones web.
- OWASP. Juice Shop. Aplicación deliberadamente vulnerable para practicar en local.
- PTES. Penetration Testing Execution Standard. Fases de un test de intrusión y contenido del alcance.
- FIRST. Common Vulnerability Scoring System (CVSS). Criterios de puntuación de vulnerabilidades.
- NIST. National Vulnerability Database. Base de datos pública de vulnerabilidades con identificadores CVE.
- MITRE. ATT&CK. Catálogo de tácticas y técnicas de adversarios observados.
- PortSwigger. Web Security Academy. Laboratorios guiados y gratuitos de seguridad web.
- Gobierno de Argentina. Ley 26.388 de delitos informáticos. Texto de la norma que incorporó estos delitos al Código Penal.