ssh-enum

Estudio de Validación Estadística de CVE-2016-6210

Una reinvestigación reproducible de la enumeración de nombres de usuario de OpenSSH mediante análisis estadístico.

Este proyecto reinvestiga CVE-2016-6210, un canal lateral de temporización documentado de OpenSSH, para determinar si sigue siendo observable en un servidor Ubuntu moderno usando la configuración PAM predeterminada.

En lugar de asumir que el comportamiento publicado aún aplica, el proyecto evalúa las mediciones de temporización de autenticación recolectadas mediante sondas manuales, Hydra y Metasploit usando la prueba t de Welch y la d de Cohen para distinguir señales de temporización genuinas del ruido de medición.

El estudio no encontró diferencias de temporización estadísticamente significativas en la configuración predeterminada probada, demostrando el valor de la experimentación reproducible y la validación basada en evidencia de las afirmaciones de seguridad publicadas.

⚠️ Aviso Legal

Este proyecto se realizó completamente dentro de un entorno de laboratorio aislado y de propiedad propia. Todos los hallazgos se aplican solo a la configuración probada. Nunca pruebe sistemas que no posea o para los que no tenga autorización explícita por escrito.

🎯 Planteamiento del Problema

Enumeración de usuarios - la capacidad de determinar si un nombre de usuario específico existe en un sistema remoto sin credenciales válidas. Es un primer paso crítico en la cadena de ataque que lleva al compromiso de la cuenta:``` Reconnaissance → [User Enumeration] → Password Attack → Access ↑ This project investigates here

Si un atacante puede distinguir "este usuario existe" de "este usuario no existe" analizando las respuestas del servidor, puede reducir drásticamente el espacio de claves para posteriores ataques de fuerza bruta o de relleno de credenciales.

SSH es un objetivo frecuente porque está expuesto casi universalmente, maneja la autenticación por contraseña y las implementaciones antiguas tenían diferencias de tiempo medibles entre nombres de usuario válidos e inválidos (CVE-2016-6210).

**Esta investigación plantea dos preguntas:**

1. ¿El OpenSSH moderno en Ubuntu 22.04.5 LTS con configuración predeterminada filtra la existencia de usuarios
   a través de mensajes de respuesta, tiempos o señales reportadas por herramientas?
2. Si un atacante lo intenta de todos modos, ¿qué artefactos deja? y ¿con qué
   fiabilidad pueden ser detectados?

---

## 🖥️ Configuración del Laboratorio

Todas las pruebas se realizaron en una red virtual totalmente aislada de solo anfitrión, sin exposición a internet.

| Máquina  | SO                        | Rol                                    | IP               | Versión SSH      |
|----------|---------------------------|-----------------------------------------|------------------|------------------|
| Atacante | Kali Linux 2024.1         | Herramientas ofensivas, scripts de análisis | 192.168.56.5     | —                |
| Objetivo   | Ubuntu Server 22.04.5 LTS | Ejecutando OpenSSH con configuración **predeterminada** | 192.168.56.10    | OpenSSH 8.9p1    |

**Configuración SSH objetivo (valores predeterminados de `/etc/ssh/sshd_config`):**```
PasswordAuthentication yes
UsePAM yes                  # Key setting — normalises timing via dummy hash
PermitRootLogin prohibit-password
MaxAuthTries 6
LogLevel INFO

UsePAM yes es la configuración crítica de endurecimiento. Fuerza a OpenSSH a ejecutar un cálculo bcrypt ficticio para usuarios inexistentes, igualando el tiempo de una verificación de contraseña real. Esto se introdujo específicamente como una contramedida para CVE-2016-6210.

🔬 Metodología

Cada método de ataque se ejecutó como un ensayo independiente con un estado de registro limpio:```bash

Reset log state on target before each trial

sudo truncate -s 0 /var/log/auth.log

After attack: collect evidence

sudo cp /var/log/auth.log ~/evidence/trial-N-auth.log

Evidencia recopilada por intento:
- Salida estándar/error de la herramienta (guardado textualmente)
- `/var/log/auth.log` del objetivo
- Muestras de temporización de respuesta mediante `time.perf_counter()` en `manual_ssh.py`
- Banner SSH obtenido antes de cualquier intento de autenticación

### Métodos de ataque

| Método                | Herramienta                          | Lista de palabras        | Propósito                                        |
|-----------------------|--------------------------------------|--------------------------|--------------------------------------------------|
| SSH Manual            | `ssh` CLI + Paramiko                 | 50 nombres de usuario comunes | Línea base; inspeccionar respuestas brutas       |
| Hydra fuerza bruta    | `hydra`                              | mismos 50                | Automatizado; aprovecha el modo de enumeración integrado de Hydra |
| Módulo de Metasploit  | `auxiliary/scanner/ssh/ssh_enumuser` | mismos 50                | Módulo de enumeración dedicado del framework      |
| Huella digital del banner | personalizado `BannerFingerprinter` | N/A                      | Filtración de versión sin autenticación, verificación de CVE |
| Análisis de temporización | personalizado `ResponseAnalyzer`    | subconjunto válido vs inválido | Verificación estadística de canal lateral         |

---

## Lo que se Construyó

Este proyecto va más allá de ejecutar herramientas — envuelve cada ataque y toda la lógica de detección en una base de código Python estructurada y proporciona un orquestador que ejecuta todo el pipeline de principio a fin.

### Herramientas de ataque (`src/attack_tools/`)

**`ManualSSHEnumerator`** — Prueba cada nombre de usuario N veces con `paramiko`, registrando la temporización precisa, el tipo de resultado y el banner SSH. Calcula la media/desviación estándar por usuario. Críticamente, **no** reutiliza conexiones entre intentos, asegurando que cada muestra capture el tiempo completo de procesamiento del servidor.

**`BannerFingerprinter`** — Obtiene el banner SSH a través de un socket TCP bruto (sin necesidad de credenciales). Analiza el nombre de implementación, la cadena de versión y la pista del SO. Contrasta con un registro local de CVE. Una versión como `OpenSSH_8.9p1 Ubuntu-3ubuntu0.6` revela el software exacto del servidor — potencialmente suficiente para identificar vulnerabilidades conocidas antes de intentar cualquier autenticación.

**`HydraAutomation`** — Envoltorio de subproceso alrededor de Hydra. Analiza la salida estándar para extraer inicios de sesión exitosos, mensajes de error y el veredicto de enumeración propio de Hydra (`does not support user enumeration`).

**`MetasploitScanner`** — Escribe un script de recurso temporal y maneja `msfconsole` mediante subproceso. Analiza la salida para detección de endurecimiento y cualquier nombre de usuario encontrado.

### Herramientas de detección (`src/detection_tools/`)

**`LogParser`** — Analizador de auth.log basado en expresiones regulares que soporta cinco tipos de eventos SSH: `failed_invalid_user`, `failed_valid_user`, `pre_auth_reject`, `accepted`, `disconnected`. Devuelve diccionarios estructurados de eventos con marca de tiempo, tipo de evento, nombre de usuario, IP de origen y puerto.

**`ResponseAnalyzer`** — Realiza la prueba t de Welch sobre las distribuciones de temporización de nombres de usuario válidos vs inválidos. Calcula delta de temporización (ms), valor p, tamaño del efecto d de Cohen y una conclusión en lenguaje sencillo. Umbral: delta ≥ 5ms Y p < 0.05 activa una advertencia de canal lateral.

**`EnumerationDetector`** — Cuatro patrones de detección:
- **Sondeos rápidos de usuarios**: ventana deslizante - misma IP, ≥10 nombres de usuario distintos en 60s
- **Correlación de listas de palabras**: tasa de coincidencia entre nombres de usuario intentados y listas de ataque conocidas
- **Temporización secuencial**: coeficiente de variación en los intervalos entre intentos (CoV bajo → herramienta)
- **Sondeo distribuido**: mismo nombre de usuario desde múltiples IPs (reconocimiento de relleno de credenciales)

**`AlertingSystem`** — Emisor de alertas ligero. Genera alertas JSON con marca de tiempo a la salida estándar. Extensible con integraciones de correo electrónico/SIEM/webhook según sea necesario.

### Orquestador

**`run_investigation.py`** — Controlador CLI que ejecuta las cuatro etapas en secuencia y escribe los resultados en `data/results/`. Ejecute con `--help` para ver el uso completo.```bash
python run_investigation.py \
    -target 192.168.xx.xxxx \
    -usernames data/wordlists/common-usernames-50.txt \
    -log data/sample-logs/auth.log \
    -known-valid root ubuntu \
    -samples 10

Observaciones y Hallazgos

Hallazgo 1: Coherencia en las Respuestas — La Defensa Principal

Hipótesis probada: ¿OpenSSH devuelve un mensaje de error diferente para un usuario inexistente que para un usuario existente con una contraseña incorrecta?```bash

Non-existent user

$ ssh [email protected] Permission denied (publickey,password).

Existing user, wrong password

$ ssh [email protected] Permission denied (publickey,password).

**Resultado:** Las respuestas son idénticas byte por byte. El protocolo no filtra nada.

**Por qué:** Desde OpenSSH 7.3, `UsePAM yes` obliga al servidor a ejecutar una operación `crypt()` ficticia para usuarios inexistentes, igualando tanto el tiempo como la ruta de error de una autenticación fallida real. La corrección fue una respuesta directa a CVE-2016-6210.

---

### Hallazgo 2: No se detectó canal lateral temporal

**Hipótesis probada:** Incluso si los mensajes de error coinciden, ¿existe una diferencia temporal medible entre nombres de usuario válidos e inválidos que pueda explotarse estadísticamente?

Se recopilaron diez muestras de tiempo para cada uno de los 50 nombres de usuario. Se compararon usuarios conocidos como válidos (confirmados del sistema) con el grupo de usuarios inválidos.

| Métrica                        | Valor                                |
|--------------------------------|--------------------------------------|
| Tiempo medio — usuarios inválidos | ~312 ms                              |
| Tiempo medio — usuarios válidos   | ~311 ms                              |
| Diferencia                     | **~1 ms**                            |
| Valor p de la prueba t de Welch | > 0.40                               |
| Conclusión                     | **No se distingue canal lateral**   |

La diferencia de ~1 ms está muy por debajo del umbral de ruido de 5 ms y no es estadísticamente significativa (p >> 0.05). El cálculo hash ficticio de OpenSSH es efectivo.

---

### Hallazgo 3: Hydra informa que no hay soporte para enumeración

El modo de enumeración SSH de Hydra se basa en una de tres señales: mensajes de error diferentes, tiempos diferentes o comportamiento de conexión diferente. Con los tres normalizados, Hydra informa explícitamente:```
[ERROR] target ssh://192.168.56.10:22/ does not support user enumeration
[STATUS] 50/50 tries completed, 0 valid logins found

Efecto secundario observado: A pesar de fallar en la enumeración, los 50 intentos se registran en /var/log/auth.log con la IP de origen, la marca de tiempo y el nombre de usuario intentado. La presencia del atacante es completamente visible.

Hallazgo 4: Metasploit detecta endurecimiento antes de completar el escaneo

El módulo auxiliary/scanner/ssh/ssh_enumuser verifica la versión de OpenSSH desde el banner antes de intentar la enumeración. Las versiones ≥ 7.3 con UsePAM yes se marcan como endurecidas y el módulo sale temprano:``` [] 192.168.xx.xxxx:22 - SSH - Checking for vulnerability [] 192.168.xx.xxxx:22 - SSH - Target is not vulnerable: OpenSSH 8.9p1 (hardened)

Este es un hallazgo útil: el banner por sí solo comunica la postura defensiva del servidor a un atacante antes de que se realice cualquier intento de enumeración.

---

### Hallazgo 5: La detección es fiable incluso cuando la enumeración falla

La percepción clave desde la perspectiva del defensor: **el ataque genera ruido incluso cuando no tiene éxito**. Los cuatro patrones de detección se activaron correctamente contra el auth.log recopilado:

| Detección                  | Disparador                                                | Gravedad |
|----------------------------|-----------------------------------------------------------|----------|
| Sondeo rápido de usuario   | IP Kali probó 50 nombres de usuario en <60s               | ALTA     |
| Correlación de wordlist    | 48/50 nombres intentados coincidieron con wordlist        | ALTA     |
| Temporización secuencial   | CoV entre intentos = 0.04 (firma de herramienta)          | MEDIA    |
| Sondeo solo de banner      | Desconexiones previas a la autenticación antes de enviar cualquier nombre de usuario | BAJA     |

---

## Proceso de pensamiento

### ¿Por qué la enumeración manual de SSH primero?

El instinto de comenzar con pruebas manuales fue metodológicamente sólido: antes de confiar en la salida de una herramienta, es necesario entender lo que realmente dice el protocolo sin procesar. Ejecutar `ssh ghost@target` y observar el mensaje de error exacto te dice si hay *algo* que enumerar antes de invertir tiempo en automatización.

La primera observación, de que `Permission denied (publickey,password)` se ve idéntico independientemente de si el usuario existe, fue el hallazgo central. Todo lo que siguió fue validación de ese resultado.

### Suposiciones que se hicieron (y se reexaminaron)

La suposición inicial fue que Hydra y Metasploit serían *más* capaces que las pruebas manuales, por lo que si lo manual fallaba, las herramientas aún podrían tener éxito. Esto resultó ser incorrecto en la dirección esperada, pero correcto en el *por qué*: las herramientas no agregan capacidad aquí porque el protocolo en sí mismo no filtra la señal. Las herramientas son solo automatización sobre el mismo protocolo.

Una segunda suposición que vale la pena examinar: el primer intento manual fue notablemente más lento que los siguientes, y el intento con contraseña correcta fue rápido. Esto se interpretó inicialmente como una posible señal de temporización. En reflexión, la lentitud se debió a la sobrecarga de establecimiento de conexión TCP en un estado de red nuevo (resolución ARP, configuración de conexión), no al tiempo de procesamiento del lado del servidor. Controlar esto—midiendo desde `time.perf_counter()` *después* del handshake TCP, o descartando la primera muestra—habría sido más riguroso. La implementación de `ManualSSHEnumerator` aborda esto recolectando 10 muestras por nombre de usuario e informando media/desviación estándar, lo que diluye el ruido de la primera muestra.

### Qué cambió durante el proyecto

El alcance original era limitado: ejecutar tres herramientas, documentar si funcionan. El proyecto evolucionó en dos direcciones:

**Hacia adentro (análisis más profundo):** Cuando los resultados iniciales fueron negativos, la pregunta natural se convirtió en *por qué*—lo que llevó a leer los registros de cambios de OpenSSH, CVE-2016-6210, y la implementación de `UsePAM`. Comprender el mecanismo es más valioso que solo registrar el resultado.

**Hacia afuera (giro hacia la detección):** Un resultado de ataque negativo sigue siendo un punto de dato defensivo útil. El giro hacia "aunque la enumeración falló, ¿qué vio el servidor?" llevó a los componentes de análisis de registros e ingeniería de detección, que convirtieron un ejercicio unidimensional de ejecución de herramientas en una investigación de dos caras.

### Qué se haría de manera diferente

Las mediciones de temporización se tomaron a través de una red virtual solo de host, que introduce menos fluctuación que una red real pero también significa que los resultados son optimistas. En un entorno real con latencia TCP, fluctuación y retransmisiones, el piso de ruido sería más alto y el análisis de temporización necesitaría más muestras por nombre de usuario. Una metodología más robusta probaría a través de un enlace WAN simulado (usando `tc netem` para introducir latencia y fluctuación controladas) para ver cómo se mantienen las conclusiones en condiciones realistas.

---

## Riesgos de seguridad

Aunque la enumeración no tuvo éxito en este laboratorio, la superficie de ataque y los riesgos asociados son:

**Si la enumeración *fuera* posible (p. ej., OpenSSH antiguo, `UsePAM no`, pila PAM personalizada):**
- Los atacantes podrían reducir una campaña de fuerza bruta solo a nombres de usuario confirmados como válidos, reduciendo el riesgo de detección y aumentando la eficiencia drásticamente.
- Combinado con rociado de contraseñas (una contraseña común para todos los nombres de usuario válidos), esto evita los bloqueos por usuario de `MaxAuthTries`.

**Riesgos que aplican incluso con resistencia a la enumeración:**
- El banner SSH filtra la versión exacta de OpenSSH y el SO. Un atacante que vea `OpenSSH_8.9p1` puede verificar inmediatamente si CVE-2024-6387 (regreSSHion) aplica, antes de enviar un solo paquete de autenticación.
- Todos los intentos de enumeración se registran con la IP de origen. Si la monitorización de registros está ausente, un ataque de combustión lenta (un intento por hora) podría sondear miles de nombres de usuario sin activar alertas basadas en tasa.
- `PasswordAuthentication yes` mantiene abierta la superficie de ataque basada en contraseñas incluso si la enumeración no es viable. Los ataques de credenciales posteriores a OSINT (usando listas de contraseñas filtradas contra nombres de usuario derivados de OSINT) no requieren enumeración del lado del servidor en absoluto.

---

## Estrategias de mitigación

| Amenaza                     | Mitigación                                                       | Cambio de configuración requerido         |
|-----------------------------|------------------------------------------------------------------|-------------------------------------------|
| Canal lateral de temporización | Asegurar `UsePAM yes` (predeterminado en Ubuntu)                 | Ninguno — ya es predeterminado            |
| Divulgación de versión en banner | `VersionAddendum none` y `DebianBanner no` en `sshd_config`      | Sí                                        |
| Ataques basados en contraseñas | `PasswordAuthentication no` — autenticación solo con clave       | Sí                                        |
| Fuerza bruta posterior a OSINT | `fail2ban` con jaula `sshd`                                      | Instalar + configurar                     |
| Enumeración lenta            | Envío de registros a SIEM; alertar sobre >N nombres de usuario distintos/IP/hora | SIEM requerido                |
| Inicio de sesión como root  | `PermitRootLogin no`                                             | Sí (el valor predeterminado es `prohibit-password`) |
| Desconexiones previas a la autenticación | `MaxStartups 10:30:60` para limitar la tasa de conexiones no autenticadas | Sí                                        |

**Adiciones mínimas recomendadas de `sshd_config` para una implementación reforzada:**```
PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
MaxStartups 10:30:60
VersionAddendum none
LogLevel VERBOSE

Mejoras Futuras

El proyecto actual prueba un protocolo en una configuración. Extensiones naturales:

Enumerar otros servicios en el mismo host. SMTP (VRFY/EXPN), LDAP (consultas de atributos), formularios de inicio de sesión HTTP y SNMP son vectores comunes de fuga de nombres de usuario en la misma máquina que está endurecida en SSH. Un estudio comparativo entre servicios produciría una imagen de riesgo más completa.

Probar configuraciones SSH no predeterminadas. UsePAM no, módulos PAM personalizados, backends de autenticación Kerberos y versiones antiguas de OpenSSH (implementadas en sistemas embebidos, dispositivos de red) aún pueden mostrar fugas de temporización. Probar el mismo pipeline contra una configuración deliberadamente vulnerable demostraría el contraste.

Detección en vivo con inotify. La detección actual se ejecuta a posteriori sobre un archivo de registro copiado. Una versión de nivel de producción usaría inotify (o tail -f + un hilo analizador) para detectar y alertar en tiempo casi real, en cuestión de segundos desde que comienza un intento de enumeración.

Detección a nivel de red. Auth.log es un artefacto basado en el host. Compleméntelo con detección a nivel de paquetes: las conexiones TCP de corta duración al puerto 22 que se cierran antes de completar el handshake de autenticación son una señal de fingerprinting solo de banner. Esto podría implementarse como una regla de Zeek o Suricata.

Cuadernos Jupyter para informes estadísticos. Los datos de temporización recopilados son susceptibles de visualización: diagramas de caja de las distribuciones de temporización por usuario, diagramas de dispersión de la frecuencia de intentos a lo largo del tiempo, mapas de calor de IPs de origen. Los cuadernos harían que el análisis fuera reproducible y compartible.

Estructura del Proyecto```

ssh-enumeration-analysis/ │ ├── README.md ├── run_investigation.py ← Full pipeline orchestrator (start here) ├── requirements.txt │ ├── src/ │ ├── attack_tools/ │ │ ├── init.py │ │ ├── manual_ssh.py ← Paramiko-based timing probe │ │ ├── banner_fingerprinter.py ← No-auth banner grab + CVE lookup │ │ ├── hydra_automation.py ← Hydra subprocess wrapper │ │ └── metasploit_scanner.py ← MSF console automation │ │ │ └── detection_tools/ │ ├── init.py │ ├── log_parser.py ← auth.log regex parser │ ├── response_analyzer.py ← Welch t-test + Cohen's d │ ├── pattern_detector.py ← 4 detection patterns │ └── alerting_system.py ← JSON alert emitter │ ├── data/ │ ├── sample-logs/ │ │ ├── auth-baseline.log ← Normal SSH activity (no attacks) │ │ ├── auth-hydra-run.log ← Captured during Hydra trial │ │ └── auth-msf-run.log ← Captured during Metasploit trial │ │ │ ├── wordlists/ │ │ ├── common-usernames-50.txt │ │ └── common-usernames-100.txt │ │ │ └── results/ ← Auto-generated (gitignored) │ ├── investigation-summary.json │ ├── manual-enumeration-results.json │ ├── timing-analysis.json │ └── detection-report.json │ ├── tests/ │ ├── test_enumeration.py │ ├── test_detection.py │ └── test_log_parser.py │ ├── case-study/ │ └── User_Enumeration_attempt_using_manual_SSH.docx │ └── screenshots/ ├── manual-ssh-same-response.png ├── hydra-no-enumeration-support.png ├── metasploit-hardened-detected.png ├── auth-log-hydra-evidence.png └── detection-alerts-output.png

## ⚡ Inicio Rápido```bash
# 1. Clone and install dependencies
git clone https://github.com/Alisha-chaudhary/ssh-enum
cd ssh-enum
pip install -r requirements.txt

# 2. Run just the banner fingerprint (no credentials needed)
python -c "
from src.attack_tools.banner_fingerprinter import BannerFingerprinter
r = BannerFingerprinter().grab('192.168.xx.xxxx')
print(r.raw_banner, r.cves)
"

# 3. Run the full investigation pipeline
python run_investigation.py \
    -target 192.168.xx.xxxx \
    -usernames data/wordlists/common-usernames-50.txt \
    -log data/sample-logs/auth-hydra-run.log \
    -known-valid root ubuntu \
    -samples 10

# 4. Analyse a log file only (no live target needed)
python -c "
from src.detection_tools.pattern_detector import EnumerationDetector
d = EnumerationDetector('data/sample-logs/auth-hydra-run.log')
import json; print(json.dumps(d.run_all(), indent=2))
"

Requisitos:``` paramiko>=3.3.1 scipy>=1.11.0 Hydra and Metasploit must be installed separately (pre-installed on Kali Linux).

---

## 📚 Referencias

| Recurso                                                                              | Relevancia                                       |
|---------------------------------------------------------------------------------------|-------------------------------------------------|
| [CVE-2016-6210](https://nvd.nist.gov/vuln/detail/CVE-2016-6210)                       | El canal lateral de temporización para el que este proyecto hizo pruebas |
| [CVE-2024-6387 (regreSSHion)](https://nvd.nist.gov/vuln/detail/CVE-2024-6387)         | RCE sin autenticación en OpenSSH ≤ 9.7            |
| [Manual de sshd_config de OpenSSH](https://man.openbsd.org/sshd_config)                     | `UsePAM`, `MaxAuthTries`, `VersionAddendum`     |
| [OWASP — Enumeración de Usuarios](https://owasp.org/www-community/attacks/User_Enumeration)  | Patrones generales de ataque de enumeración             |
| [RFC 4252 — Protocolo de Autenticación SSH](https://tools.ietf.org/html/rfc4252)         | Especificación del protocolo; define el comportamiento de los mensajes de error  |
| [Documentación de fail2ban](https://www.fail2ban.org/wiki/index.php/Main_Page)           | Limitación de velocidad y bloqueo de IP                    |

---

## 🎓 Habilidades Demostradas

| Dominio                 | Evidencia                                                                                                |
|-------------------------|----------------------------------------------------------------------------------------------------------|
| Internos del Protocolo SSH | Comprensión de la normalización de temporización de `UsePAM`, corrección de CVE-2016-6210, exposición de información del banner          |
| Seguridad Ofensiva      | Uso práctico de Hydra, Metasploit y sondeo personalizado con Paramiko en una metodología estructurada              |
| Análisis Estadístico    | Prueba t de Welch, d de Cohen, coeficiente de variación aplicados a datos de temporización                              |
| Ingeniería de Detección | Detección de IOC basada en registros en cuatro tipos de patrones; salida estructurada de alertas                              |
| Ingeniería Python       | Dataclasses, sugerencias de tipo, automatización de subprocesos, análisis de expresiones regulares, librerías estadísticas                    |
| Investigación en Seguridad | Hipótesis → experimento controlado → recolección de evidencia → hallazgos documentados → conclusiones accionables |

---

**Estado:** Completado | **Probado en:** Ubuntu Server 22.04 LTS + OpenSSH 8.9p1 | Kali Linux 2024.1

ssh-enum

Más Populares

Acerca de