Hacking ético en acción: reconocimiento de red, DNS, WHOIS y análisis OWASP paso a paso
Tema: Ciberseguridad | Tiempo de lectura estimado: 20 minutos
¿Qué es el hacking ético y por qué importa el reconocimiento de red?
El hacking ético es una disciplina que consiste en evaluar la seguridad de sistemas informáticos con autorización explícita del propietario, con el objetivo de identificar vulnerabilidades antes de que lo haga un atacante malicioso. A diferencia de lo que muchas personas creen, el hacking ético no comienza con exploits ni con herramientas complejas: comienza con información.
La fase de reconocimiento es, sin duda, el primer gran pilar de cualquier auditoría de seguridad. En esta etapa, el analista recopila datos públicamente disponibles sobre un sistema: su dirección IP, los puertos que tiene abiertos, los registros DNS, los certificados de seguridad y la información de registro del dominio. Todo esto sin lanzar un solo ataque. Como veremos en este artículo (basado en un taller práctico de hacking ético desarrollado en la Universidad Central de Bogotá), con herramientas básicas de línea de comandos es posible construir un mapa detallado de la infraestructura de un sitio web.
A lo largo de estas páginas explicaremos cómo se realizaron pruebas reales sobre el dominio honda-motorshop.free.nf, siempre bajo autorización escrita del propietario, respetando los principios del hacking ético y la legalidad. Los hallazgos se analizan también bajo el marco del OWASP Top 10 (2021), el estándar de referencia mundial para la seguridad de aplicaciones web. Para más información sobre una guía de hacking ético podemos ir al siguiente enlace: ver más aquí
La autorización previa: el principio fundamental del hacking ético
Antes de ejecutar cualquier herramienta o comando, el equipo obtuvo una carta de autorización escrita del propietario del sitio web. Este paso, muchas veces pasado por alto en tutoriales informales, es absolutamente indispensable. Sin autorización, cualquier prueba de reconocimiento (incluso las más inofensivas) puede constituir un delito informático según la legislación vigente en Colombia y en la mayoría de países del mundo.
Esta práctica refleja uno de los valores más importantes del hacking ético: la transparencia y el respeto por los límites legales. Un analista de seguridad responsable siempre documenta el alcance de sus pruebas, obtiene autorización formal y delimita claramente qué sistemas puede evaluar y cuáles no.
Pruebas de conectividad con PING: cuando el silencio también habla
La primera herramienta utilizada fue el comando ping, uno de los más conocidos en el mundo de las redes. Su función es simple: envía paquetes ICMP a un servidor y espera respuesta, midiendo tiempos de latencia y detectando pérdida de paquetes.
Al ejecutar ping honda-motorshop.free.nf, el resultado fue inesperado para quien no conoce los entornos de hosting moderno: 100% de pérdida de paquetes. Los cuatro paquetes enviados no obtuvieron respuesta. Sin embargo, esto no significa que el servidor esté caído.
El dominio resolvió correctamente a la dirección IP 185.27.134.138, lo que confirma que el servidor existe y está activo. La pérdida de paquetes se debe a que el proveedor de hosting bloquea las solicitudes ICMP por razones de seguridad, una práctica completamente habitual en servicios de alojamiento compartido. De hecho, al acceder al sitio desde un navegador web, la página cargó sin problemas, confirmando que los servicios HTTP y HTTPS estaban operativos.
Esta es una lección valiosa: en hacking ético, la ausencia de respuesta no equivale a ausencia de objetivo. Saber interpretar correctamente los resultados (incluidos los negativos), es parte esencial del análisis.
Traceroute: trazando el camino de los paquetes hasta el servidor
El siguiente paso fue ejecutar el comando tracert honda-motorshop.free.nf (en Windows) o su equivalente traceroute en sistemas Linux y macOS. Esta herramienta traza la ruta que siguen los paquetes de datos desde el equipo local hasta el servidor de destino, mostrando cada salto intermedio.
Los resultados fueron reveladores. Los primeros saltos correspondían a la red local y al proveedor de internet del equipo desde donde se realizaron las pruebas. A partir del cuarto salto, el tráfico se enrutó hacia infraestructura internacional. Los tiempos de respuesta (cercanos a los 160 milisegundos) junto con los nombres de los nodos identificados (como WILDCARD-UK.edge3.Manchesteruk2.Level3.net) apuntan claramente a que el servidor físico se encuentra en el Reino Unido.
A partir de cierto punto, varios nodos dejaron de responder, mostrando asteriscos en lugar de tiempos. Esto es completamente normal: muchos routers y dispositivos intermedios están configurados para no responder a solicitudes ICMP por políticas de seguridad. Sin embargo, el hecho de que la traza llegue hasta los nodos finales demuestra que existe conectividad válida hacia el servidor.
Escaneo de puertos con Nmap: descubriendo los servicios activos
Una de las herramientas más potentes utilizadas en el taller fue Nmap (Network Mapper), un escáner de puertos de código abierto ampliamente usado en auditorías de seguridad. Se ejecutó un escaneo básico con el comando nmap -F honda-motorshop.free.nf, que analiza los 100 puertos más comunes.
El escaneo identificó tres puertos abiertos:
- Puerto 80 (HTTP): Utilizado para comunicación web estándar, sin cifrado.
- Puerto 443 (HTTPS): El protocolo seguro para comunicación cifrada mediante SSL/TLS.
- Puerto 2049 (NFS): Un servicio de archivos en red, comúnmente activo en servidores de hosting compartido.
La presencia de los puertos 80 y 443 confirma que el sitio está disponible tanto con HTTP como con HTTPS, cumpliendo con los estándares básicos de seguridad web. El puerto 2049, por otro lado, llama la atención: aunque su presencia puede ser legítima en entornos de hosting, también representa un servicio adicional expuesto que, si no está correctamente asegurado, podría convertirse en un vector de ataque.
nslookup y resolución DNS: confirmando la identidad del servidor
Para obtener la dirección IP asociada al dominio de forma precisa, se utilizó el comando nslookup honda-motorshop.free.nf. Esta herramienta consulta el sistema de nombres de dominio (DNS) y devuelve la IP correspondiente al nombre solicitado.
El dominio resolvió correctamente a 185.27.134.138, lo que indica que el sistema DNS está bien configurado y que el sitio web está correctamente apuntado a su servidor. Este resultado es consistente con los obtenidos en las pruebas de ping y traceroute.
Análisis DNS profundo: registros A, MX, NS y TXT
Más allá de la consulta básica, el análisis DNS incluyó la inspección de distintos tipos de registros para obtener una visión más completa de la infraestructura del dominio.
Registro tipo A
Registro tipo MX
Registro tipo NS
Registro tipo TXT
Los resultados mostraron un patrón coherente con la arquitectura del sitio:
El registro tipo A confirmó nuevamente la IP del servidor. Los registros MX, NS y TXT no mostraron configuraciones personalizadas, ya que el sitio está alojado bajo un subdominio de un servicio de hosting gratuito. La ausencia de registros MX es especialmente significativa: el dominio no está configurado para recibir correos electrónicos directamente. El sitio utiliza WordPress para sus notificaciones, enviando mensajes a través de servicios externos como Gmail mediante el protocolo SMTP, lo que hace innecesaria la configuración de registros MX propios.
Este tipo de análisis demuestra que la ausencia de ciertos registros no siempre es una señal de alarma: hay que entender el contexto del servicio para interpretar correctamente los resultados.
Consulta WHOIS: quién está detrás del dominio
La consulta WHOIS permite obtener información pública sobre el registrante de un dominio. Para este caso, se utilizó la herramienta en línea who.is, ya que el sistema operativo Windows no incluye el comando whois de forma nativa: ver más aquí
La consulta arrojó información correspondiente al dominio principal free.nf, dado que el sitio analizado es un subdominio y no un dominio propio. Los datos relevantes obtenidos fueron:
- Registrador: Key-Systems GmbH
- Fecha de creación: 14 de junio de 2023
- Fecha de expiración: 14 de junio de 2026
- Última actualización: 25 de noviembre de 2025
No se encontró información directa sobre el propietario del subdominio, lo cual es habitual en servicios de hosting gratuito, donde los datos del registrante suelen estar protegidos o no disponibles públicamente. Esta es también una consideración de privacidad relevante: el uso de subdominios gratuitos dificulta la atribución directa a un propietario específico.
Certificados SSL/TLS: garantizando la seguridad de las comunicaciones
El análisis de certificados SSL/TLS es fundamental para verificar que las comunicaciones entre el usuario y el servidor están cifradas y protegidas. Se utilizaron dos métodos complementarios: la inspección directa desde el navegador y la herramienta en línea SSL Checker.
Certificado en navegador (ZeroSSL)
SSL Checker: ver más aquí
Los hallazgos fueron positivos. El sitio cuenta con un certificado SSL válido emitido por ZeroSSL, lo que garantiza que las comunicaciones están cifradas mediante HTTPS (puerto 443). La cadena de certificación está correctamente configurada e incluye las autoridades intermedias necesarias para ser reconocida como confiable por todos los navegadores principales.
Un detalle técnico interesante: el certificado no está emitido exclusivamente para el subdominio honda-motorshop.free.nf, sino para el dominio principal free.nf incluyendo todos sus subdominios mediante la extensión SANs (Subject Alternative Names). Esto es una práctica común en servicios de hosting gratuito, donde un único certificado wildcard cubre múltiples sitios alojados bajo el mismo dominio. La fecha de expiración identificada fue el 25 de junio de 2026, lo que indica que el certificado tiene vigencia activa al momento del análisis.
OWASP Top 10: evaluando las vulnerabilidades más críticas de la aplicación web
Con la información recopilada durante la fase de reconocimiento, el equipo procedió a analizar el sitio bajo el marco del OWASP Top 10 (2021), el estándar de referencia mundial publicado por la Open Web Application Security Project que clasifica las diez categorías de vulnerabilidades más críticas en aplicaciones web. A continuación se presenta el análisis aplicado al sitio honda-motorshop.free.nf.
A01 — Control de Acceso Roto (Broken Access Control)
Esta vulnerabilidad ocurre cuando los usuarios pueden acceder a recursos o funciones sin la debida autorización. Para evaluarla, se utilizó la herramienta de línea de comandos (CMD) para ejecutar pruebas sobre rutas administrativas como /admin y /wp-admin.
El riesgo principal identificado en esta categoría es el posible acceso a información sensible o funciones restringidas. El análisis de resultados confirmó que la ruta administrativa sí existe en el servidor, pero está protegida mediante autenticación. No hay acceso directo sin credenciales. Se observaron además los siguientes encabezados en la respuesta del servidor: WWW-Authenticate, Cache-Control y Content-Length, lo que confirma que el servidor solicita credenciales activamente antes de permitir cualquier tipo de acceso.
Mitigación recomendada: implementar control de roles granular, validación estricta en el lado del servidor y mecanismos de autenticación segura.
A02 — Fallas Criptográficas (Cryptographic Failures)
Las fallas criptográficas ocurren cuando la información sensible no está correctamente protegida mediante cifrado, lo que permite su exposición o interceptación por parte de atacantes. Para evaluar esta categoría, se verificó el uso del protocolo HTTPS desde el navegador, se inspeccionó el certificado SSL/TLS y se confirmó el estado del puerto 443 previamente identificado con la herramienta Nmap.
Para verificar el uso de cifrado en el sitio web, se realizó el acceso desde el navegador comprobando el protocolo HTTPS, la inspección del certificado SSL/TLS desde el candado del navegador y la validación del puerto seguro 443 previamente identificado con Nmap.
El análisis confirmó que el sitio utiliza HTTPS (puerto 443) y que el certificado SSL es válido, emitido por ZeroSSL, con comunicación cifrada entre el usuario y el servidor. Sin embargo, se identificó que al acceder directamente por HTTP, el sitio carga sin redirigir automáticamente a HTTPS, lo que podría permitir comunicaciones no cifradas si el usuario no escribe el protocolo seguro explícitamente.
Mitigación recomendada: configurar una redirección forzosa de HTTP a HTTPS mediante el archivo .htaccess o la configuración del servidor.
A03 — Inyección (Injection)
Las vulnerabilidades de inyección ocurren cuando datos no confiables son enviados a un intérprete como parte de comandos o consultas, lo que puede permitir la ejecución de instrucciones no autorizadas. Para evaluar este riesgo, se identificó un formulario de contacto en el sitio web y se realizaron pruebas de entrada utilizando caracteres especiales, como ' OR 1=1 --, en los campos disponibles.
El análisis evidenció que el campo acepta la entrada sin aplicar validaciones visibles en el lado del cliente, lo que indica la ausencia de controles de sanitización en el frontend. Aunque no es posible confirmar el comportamiento del backend sin acceso directo al servidor, esta situación representa un riesgo potencial de vulnerabilidades de inyección, dependiendo de cómo el servidor procese los datos recibidos.
Mitigación recomendada: implementar validación y sanitización de entradas tanto en el cliente como en el servidor, utilizar consultas parametrizadas para evitar inyecciones SQL y aplicar mecanismos de escape de caracteres en caso de renderización en interfaces web.
A04 — Diseño Inseguro (Insecure Design)
Esta categoría abarca los problemas de seguridad que tienen su origen en la propia arquitectura del sistema, antes incluso de que se escriba código.
El análisis de la arquitectura del sitio reveló que está alojado en un hosting gratuito compartido bajo el subdominio free.nf, lo que indica una arquitectura básica con limitaciones de seguridad estructurales. Esta configuración implica que muchas decisiones clave de seguridad dependen enteramente del proveedor de hosting y no están bajo el control directo del administrador del sitio. Además, tal como evidenció la consulta WHOIS, la información del registrante no es pública, lo que dificulta la trazabilidad y la gestión de incidentes.
El diagrama de arquitectura del sitio reveló un conjunto de características preocupantes desde el punto de vista de la seguridad: el sitio está alojado en un hosting gratuito compartido (free.nf), sin WAF (Web Application Firewall) visible, sin protección DDoS activa, sin CDN y sin políticas de seguridad avanzadas. Los recursos asignados son limitados en CPU, RAM y almacenamiento. Esta arquitectura implica que muchas decisiones de seguridad están fuera del control directo del administrador del sitio y dependen enteramente del proveedor de hosting.
Mitigación recomendada: aplicar principios de diseño seguro desde las etapas tempranas, realizar análisis de amenazas periódicos y considerar migrar a una infraestructura con mayor control sobre los parámetros de seguridad.
A05 — Mala Configuración de Seguridad (Security Misconfiguration)
Las configuraciones incorrectas en servidores o aplicaciones son una de las causas más comunes de brechas de seguridad. El escaneo con Nmap detectó tres puertos abiertos y el análisis de encabezados HTTP reveló ausencias críticas.
Además de los puertos 80, 443 y 2049 ya identificados, el escaneo ampliado detectó también el puerto 21 (FTP) filtrado y el puerto 22 (SSH) filtrado, lo que indica que estos servicios están presentes aunque no totalmente accesibles. El puerto 2049 (NFS) continúa siendo el más preocupante por su potencial para exponer el sistema de archivos a la red. Adicionalmente, se detectó la ausencia de encabezados de seguridad HTTP esenciales: X-Frame-Options, X-Content-Type-Options y Strict-Transport-Security, lo que incrementa la exposición ante ataques de clickjacking e inyección de contenido.
Mitigación recomendada: cerrar o restringir los puertos no indispensables, implementar los encabezados de seguridad HTTP faltantes y configurar un firewall de aplicaciones web.
A06 — Componentes Vulnerables y Desactualizados (Vulnerable and Outdated Components)
El uso de componentes desactualizados o con vulnerabilidades conocidas representa una de las principales vías de ataque en aplicaciones web, especialmente en sistemas basados en WordPress. Durante el análisis del código fuente del sitio, se identificaron rutas visibles hacia archivos internos de plugins, como se observa en la carga de recursos desde:
En particular, se evidenció la referencia a archivos ubicados en el directorio /wp-content/plugins/woocommerce/, lo cual confirma el uso de este plugin dentro de la aplicación. La exposición de estas rutas permite a un atacante identificar tecnologías específicas utilizadas en el sistema, facilitando la búsqueda de vulnerabilidades conocidas asociadas a dichos componentes.
Aunque en esta fase no se confirmó la versión exacta de los plugins instalados, la visibilidad de estos recursos indica una posible superficie de ataque si alguno de ellos se encuentra desactualizado o presenta fallas de seguridad documentadas.
Mitigación recomendada: mantener actualizados todos los componentes del sistema, incluyendo WordPress, plugins y temas; eliminar aquellos que no se encuentren en uso; y minimizar la exposición de información sensible en el código fuente mediante técnicas de hardening.
A07 — Fallos de Identificación y Autenticación (Identification and Authentication Failures)
Esta categoría evalúa las fallas en los mecanismos de identificación y autenticación de usuarios. En el sitio analizado se identificó que el sistema permite intentos ilimitados de inicio de sesión sin CAPTCHA ni ningún tipo de verificación adicional, lo que incrementa significativamente el riesgo de ataques de fuerza bruta.
El análisis del panel de administración reveló las siguientes condiciones de riesgo concretas:
El login no implementa ningún mecanismo de protección ante intentos repetidos de acceso. Adicionalmente, se identificaron cuatro cuentas con rol de administrador registradas en el sistema, cuyos nombres de usuario son predecibles y genéricos: ana_admin, gina_admin, nelson_admin y cpinzon19. Si bien WordPress obliga al uso de contraseñas fuertes al momento de crear usuarios (lo que mitiga parcialmente el riesgo), no existe autenticación multifactor ni plugins de seguridad activos que refuercen el proceso de acceso.
Riesgos identificados: acceso no autorizado mediante ataques de fuerza bruta, escalamiento de privilegios derivado de la existencia de múltiples cuentas con rol de administrador y compromiso de cuentas críticas ante la ausencia de mecanismos de protección adicionales.
Mitigación recomendada: mantener la obligatoriedad de contraseñas fuertes (ya implementada), implementar autenticación multifactor (MFA), configurar el bloqueo automático de cuentas tras varios intentos fallidos, reducir el número de cuentas con rol de administrador y asignar nombres de usuario menos predecibles. Cuando el contexto académico o de producción lo permita, instalar plugins de seguridad que refuercen el proceso de login.
A08 — Fallos en la Integridad de Software y Datos (Software and Data Integrity Failures)
Esta vulnerabilidad se presenta cuando el sistema depende de componentes externos (plugins, temas o servicios del hosting) cuya integridad no está verificada mediante firmas digitales ni controles de actualización seguros. En entornos gratuitos como free.nf, las actualizaciones y archivos pueden ser modificados sin mecanismos de validación que lo detecten.
El análisis del panel de administración evidenció que el sitio depende enteramente del proveedor de hosting gratuito para la gestión de actualizaciones y seguridad. Se observaron múltiples plugins activos con versiones desactualizadas, lo que representa un riesgo directo de pérdida de integridad del software. El informe de “Salud del sitio” mostró además un evento programado fallido y un resultado inesperado en la API REST, condiciones que pueden afectar la estabilidad del sistema y abrir vectores de ataque no previstos.
Riesgos identificados: manipulación de software o datos por vulnerabilidades en plugins desactualizados, posible inserción de código malicioso o corrupción de archivos del sistema ante la ausencia de mecanismos de firma digital y validación de origen.
Mitigación recomendada: validar la integridad de los archivos críticos del sitio, usar únicamente plugins y temas del repositorio oficial de WordPress, activar las actualizaciones automáticas para todos los componentes, implementar copias de seguridad periódicas con verificación de hashes, migrar a un hosting con soporte de WAF (Web Application Firewall) y validación de integridad, y revisar periódicamente el panel de “Salud del sitio” para detectar anomalías de forma proactiva.
A09 — Fallos en el Registro y Monitoreo de Seguridad (Security Logging and Monitoring Failures)
Las fallas en el registro y monitoreo de eventos críticos impiden detectar ataques a tiempo y eliminan la trazabilidad necesaria para responder adecuadamente a incidentes. En el sitio analizado, el sistema no mantiene trazabilidad completa de las acciones programadas ni cuenta con alertas robustas configuradas.
Riesgos identificados: incapacidad de detectar ataques o fallos en tiempo real, pérdida de trazabilidad de eventos críticos del sistema y mayor exposición a incidentes que pasan completamente desapercibidos.
Mitigación recomendada: configurar cron jobs diarios para todas las tareas críticas del sistema, ampliar la capacidad y el período de retención del sistema de logging, revisar periódicamente los registros de WooCommerce y WordPress, y migrar a un hosting con capacidades de monitoreo en tiempo real y alertas automáticas ante actividades sospechosas.
A10 — Falsificación de Solicitudes del Lado del Servidor (Server-Side Request Forgery – SSRF)
El SSRF permite que un atacante manipule al servidor para que realice solicitudes HTTP hacia recursos internos o externos en su nombre, evadiendo los controles de acceso establecidos.
Para evaluar esta vulnerabilidad se realizó una inspección manual del sitio web utilizando el navegador, con el objetivo de identificar posibles puntos de entrada como formularios, campos de texto o funcionalidades que permitieran el envío de URLs desde el lado del usuario hacia el servidor.
Durante el análisis, no se evidenció la presencia de formularios o campos que permitan ingresar direcciones URL, ni funcionalidades que generen solicitudes externas desde el servidor de forma explícita. El formulario de contacto disponible en el sitio únicamente solicita datos básicos como nombre, correo electrónico, asunto y mensaje, sin ningún campo que acepte URLs ni redirecciones externas.
Nivel de riesgo: bajo en el contexto del análisis realizado, dado que no se identificaron vectores directos de SSRF en la interfaz pública del sitio.
Mitigación recomendada: aunque el riesgo actual es bajo, se recomienda como medida preventiva validar y sanitizar todas las entradas del usuario, restringir las solicitudes del servidor hacia direcciones internas como localhost y 127.0.0.1, implementar listas blancas de URLs permitidas y configurar reglas de firewall que limiten las solicitudes salientes del servidor.
Conclusiones: lo que el hacking ético revela sobre la seguridad real
El taller demostró con claridad que la fase de reconocimiento es enormemente informativa (y potencialmente peligrosa en manos equivocadas) sin necesidad de explotar ninguna vulnerabilidad de forma activa. Con herramientas básicas como ping, tracert, nslookup, Nmap y consultas DNS/WHOIS, fue posible construir un mapa detallado de la infraestructura del sitio: su ubicación geográfica en el Reino Unido, los servicios activos, el estado del certificado SSL y las posibles superficies de ataque.
El análisis OWASP complementó esta visión con hallazgos concretos. El sitio muestra una configuración básica pero con varias áreas de mejora prioritaria: la ausencia de limitación de intentos de login lo expone a ataques de fuerza bruta, los encabezados de seguridad HTTP faltantes incrementan la superficie de ataque, los plugins desactualizados representan vectores de explotación conocidos y la falta de monitoreo activo impediría detectar una intrusión a tiempo. Por otro lado, aspectos como el certificado SSL válido y la autenticación requerida en el panel administrativo demuestran que existen controles básicos implementados.
La conclusión más importante es la que trasciende este caso específico: ningún sistema es completamente seguro, pero la diferencia entre un sistema vulnerable y uno resistente está en la capacidad de identificar sus debilidades antes de que lo haga un atacante malintencionado. El hacking ético, realizado siempre con autorización y dentro del marco legal, es la herramienta más poderosa disponible para lograrlo.
Créditos:
Autores: Ana Catalina Parra Arias – Gina Marcela Acosta Ruiz – Nelson Stiven Otavo Paredes
Editor: Magister Ingeniero Carlos Iván Pinzón Romero
Código: UCHEG1-9
Universidad: Universidad Central
Fuentes:
Chirou, A. (2023, 29 de diciembre). Guía de hacking y pentesting - Capítulo 2: Herramientas para pentesters. https://achirou.com/guia-de-hacking-y-pentesting-capitulo-2-herramientas-para-pentesters/
Chirou, A. (2024, 1 de enero). Guía de hacking y pentesting - Capítulo 3: Nmap reconocimiento y enumeración. https://achirou.com/guia-de-hacking-y-pentesting-capitulo-3-nmap-reconocimiento-y-enumeracion/
Chirou, A. (2024, 22 de noviembre). Linux para hackers #18: Comandos de red. https://achirou.com/linux-para-hackers-18-comandos-de-red/
DC Seguridad. (s.f.). Pentesting paso a paso: máquinas TryHackMe. DCSeguridad. https://dcseguridad.es/tag/pentesting/
Instituto Nacional de Ciberseguridad (INCIBE-CERT). (2023). Estudio de herramientas para la actividad de reconocimiento. https://www.incibe.es/sites/default/files/2023-08/INCIBE-CERT_ESTUDIO_DE_HERRAMIENTAS_DE_RECONOCIMIENTO_2023_v1.0.pdf
Paramissuperiores. (2025, 26 de noviembre). Nmap: Guía completa 2025 – Tutorial de comandos, escaneo de puertos y hacking ético. https://paramissuperiores.es/2025/11/26/nmap-tutorial-comandos-escaneo-puertos/
Revista de Seguridad UNAM. (s.f.). Pruebas de penetración para principiantes: 5 herramientas para empezar. Universidad Nacional Autónoma de México. https://revista.seguridad.unam.mx/print/2233
Viafirma. (2025, 10 de noviembre). Hacking ético: identificación de servicios con nmap. https://www.viafirma.com/es/identificacion-de-servicios-con-nmap/
WeLiveSecurity. (s.f.). Herramientas de pentesting para principiantes. ESET. https://www.welivesecurity.com/es/recursos-herramientas/herramientas-pentesting-para-principiantes/
free.nf WHOIS Domain Name Lookup - Who.is. (2023). Who.Is. https://who.is/whois/free.nf
SSL Checker. (2026). Sslshopper.Com. https://www.sslshopper.com/ssl-checker.html#hostname=https://honda-motorshop.free.nf/
