Introducción al Problema#
Un penetration test —o pentest— es un ataque controlado y autorizado contra los propios sistemas de una organización, con el objetivo de encontrar vulnerabilidades antes de que lo haga un atacante real. No es un escaneo automático de vulnerabilidades ni una revisión de configuración: es una simulación de ataque real, con las mismas herramientas y técnicas que usaría un adversario.
La diferencia entre un pentest y un ataque real es exactamente una cosa: autorización escrita y explícita del dueño de los sistemas. Fuera de eso, las técnicas son idénticas. Esta distinción es crítica y no negociable — el pentesting sin autorización es intrusión informática ilegal, independientemente de la intención.
Este artículo habla exclusivamente de auditar tus propios sistemas con metodología de pentesting. No es una guía para atacar sistemas ajenos, y no puede ni debe usarse con ese fin.
¿Por qué hacerlo? Porque los atacantes reales no esperan que tu equipo de IT tenga tiempo de revisar todo. Un pentest periódico — incluso uno básico interno — puede descubrir vulnerabilidades que ninguna herramienta automática identificó, porque combina herramientas con juicio humano y creatividad para encadenar problemas que por separado parecen menores.
Caso Real o Ejemplo Cotidiano#
Una empresa de distribución decidió hacer su primer pentest interno cuando contrató a un nuevo CISO. El ejercicio estaba planificado para dos días. En las primeras cuatro horas, el equipo de pentest encontró algo que nadie esperaba: el servidor JetBrains TeamCity de integración continua, usado solo internamente para deploys, tenía la interfaz de administración expuesta a internet sin autenticación, con la versión vulnerable a CVE-2024-27199.
Con esa vulnerabilidad, un atacante externo podía crear un usuario administrador sin autenticarse y tomar control completo del servidor de CI/CD. Desde ahí, el acceso a código fuente, credenciales de producción, y la capacidad de inyectar código malicioso en los builds era directo.
El servidor llevaba 8 meses en ese estado. Nadie lo había detectado porque no había escáner externo que mirara esa IP, y el equipo de IT asumía que "ese servidor es interno, no debería ser accesible desde afuera". Una configuración incorrecta del firewall lo había expuesto sin que nadie lo supiera.
El pentest encontró la vulnerabilidad el día 1. El parche tardó 4 horas en aplicarse. El costo del ejercicio fue insignificante comparado con lo que hubiera costado la brecha.
Riesgos para la Empresa#
| Sin pentesting periódico | Con pentesting interno |
|---|---|
| Vulnerabilidades críticas pueden estar expuestas durante meses sin que nadie lo sepa | Descubrimiento proactivo antes de que lo encuentre un atacante real |
| Herramientas automáticas solo detectan problemas conocidos en sus bases de datos | El pentest encadena vulnerabilidades que ningún escáner automatizado combina |
| No se puede saber qué puede hacer un atacante con acceso inicial hasta que lo hace | El pentest muestra exactamente qué impacto tendría un compromiso real |
| Sin evidencia del riesgo real, las inversiones en seguridad son difíciles de justificar | El reporte de pentest es evidencia concreta para priorizar presupuesto |
Explicación Técnica Sencilla#
La metodología básica: 5 fases#
FASE 1: RECONOCIMIENTO (Reconnaissance)
↓ Recolectar información sobre el objetivo sin interactuar con él directamente
→ ¿Qué subdominios existen? ¿Qué tecnologías usa la web? ¿Qué IPs tiene?
→ Herramientas: theHarvester, Shodan, Whois, Google Dorks
FASE 2: ESCANEO (Scanning)
↓ Descubrir qué servicios están activos y en qué puertos
→ ¿Qué puertos están abiertos? ¿Qué versiones de software corren?
→ Herramientas: Nmap, Masscan
FASE 3: IDENTIFICACIÓN DE VULNERABILIDADES (Vulnerability Assessment)
↓ Identificar debilidades explotables en los servicios descubiertos
→ ¿Hay versiones con CVEs conocidos? ¿Hay configuraciones débiles?
→ Herramientas: Nessus Essentials, OpenVAS, Nikto (web)
FASE 4: EXPLOTACIÓN CONTROLADA (Exploitation)
↓ Intentar explotar las vulnerabilidades encontradas para validar el impacto
→ ¿La vulnerabilidad es realmente explotable en este contexto?
→ Herramientas: Metasploit Framework, Burp Suite
FASE 5: REPORTE
↓ Documentar hallazgos con severidad, impacto y remediación
→ Qué se encontró, cómo explotarlo, qué impacto tendría, cómo arreglarloNmap: el escáner de red fundamental#
Nmap (Network Mapper) es la herramienta de descubrimiento de red y puertos más usada en el mundo. Con la combinación correcta de opciones, revela la superficie de ataque visible de tu red:
# Escaneo básico de hosts activos en la red interna
nmap -sn 192.168.1.0/24
# Escaneo de puertos comunes con detección de versión y OS
nmap -sV -sC -O 192.168.1.10
# Escaneo completo de todos los puertos con detección de versión
nmap -p- -sV --open 192.168.1.10
# Escaneo de vulnerabilidades con scripts NSE
nmap --script vuln 192.168.1.10Nessus Essentials: el escáner de vulnerabilidades gratuito#
Nessus Essentials (gratuito para hasta 16 IPs) escanea automáticamente los sistemas contra su base de datos de CVEs y genera un reporte priorizado por severidad. Es el punto de partida para el análisis de vulnerabilidades antes de la explotación manual.
Metasploit Framework: validación de explotabilidad#
Metasploit es el framework de pentesting más usado del mundo. Permite seleccionar un módulo de exploit, configurar el objetivo, y ejecutar el ataque de forma controlada para verificar si la vulnerabilidad es realmente explotable:
# Ejemplo: validar si SMBv1 (EternalBlue) es explotable
use exploit/windows/smb/ms17_010_eternalblue
set RHOSTS 192.168.1.20
set LHOST 192.168.1.100
check # verificar si el target es vulnerable (sin explotar)
run # explotar de forma controlada (solo en sistemas propios, con autorización)Regla fundamental: Metasploit solo se usa en sistemas propios con autorización escrita. El módulo check verifica la vulnerabilidad sin explotarla — ideal para confirmar hallazgos de Nessus sin ejecutar el exploit completo.
Cómo Prevenirlo#
-
Establecé el alcance por escrito ANTES de comenzar: Documentá qué IPs, dominios y sistemas están en scope (incluidos en el test) y cuáles están fuera. Obtené autorización escrita del responsable legal/técnico de la organización. Sin esto, no empezás. Este documento protege a todos.
-
Empezá con reconocimiento externo — qué ven los atacantes desde internet:
bash# Qué IPs/subdominios de tu organización son visibles desde internet theHarvester -d tuempresa.com.ar -b google,bing,certspotter # Qué servicios tiene expuestos tu IP pública (como lo ve un atacante) # Consultar Shodan con tu IP pública: shodan.io/host/<tu-IP> -
Hacé un inventario de servicios con Nmap antes de escanear vulnerabilidades: Sabé qué está corriendo antes de buscar problemas. El inventario de servicios activos ya puede revelar servicios que no deberían estar expuestos.
-
Usá Nessus Essentials para el escaneo de vulnerabilidades automatizado: Configurá una política de escaneo completo para la red interna. El primer escaneo suele revelar vulnerabilidades críticas de software sin parchear que son accionables de inmediato.
-
Enfocá el análisis manual en las vulnerabilidades de mayor severidad: Con el reporte de Nessus como base, priorizá las vulnerabilidades críticas (CVSS ≥ 9.0) y altas (CVSS 7.0-8.9). Para cada una, evaluá manualmente si el contexto las hace realmente explotables.
-
Documentá todo con capturas de pantalla y comandos exactos: El reporte es el producto final del pentest. Cada hallazgo debe tener: descripción de la vulnerabilidad, cómo fue encontrada, evidencia (screenshot/output de comando), impacto real si se explota, y pasos de remediación concretos.
-
Establecé un ciclo de pentesting periódico: Un pentest una vez no alcanza. La infraestructura cambia, aparecen nuevos servicios, se instalan nuevas versiones. Un ciclo trimestral o semestral de auditoría interna, complementado con escaneos de vulnerabilidades mensuales automatizados, da cobertura continua.
Herramientas Recomendadas#
Nmap (nmap.org): El escáner de red y puertos estándar de la industria. Gratuito, open source, disponible en Linux/macOS/Windows. Esencial para la fase de reconocimiento y descubrimiento de servicios. El motor de scripts NSE permite escaneos de vulnerabilidades básicos. Kali Linux lo incluye por defecto.
Nessus Essentials (tenable.com/products/nessus/nessus-essentials): La versión gratuita de Nessus, el escáner de vulnerabilidades más usado en el mundo. Gratuito para hasta 16 IPs, con acceso a la misma base de datos de plugins que la versión profesional. Genera reportes HTML/PDF detallados con remediación sugerida. El punto de partida ideal para vulnerability assessment en PyMEs.
Metasploit Framework (metasploit.com): El framework de pentesting open source más completo disponible. Incluido en Kali Linux. Permite explotar vulnerabilidades de forma controlada para validar el impacto real de los hallazgos. Fundamental para la distinción entre "vulnerabilidad teórica" y "vulnerabilidad realmente explotable en este contexto". Solo usar en sistemas propios con autorización.
Burp Suite Community Edition (portswigger.net/burp): El estándar de la industria para pentesting de aplicaciones web. La versión Community (gratuita) incluye el proxy interceptor, scanner básico, y herramientas de fuzzing. Ideal para auditar aplicaciones web propias: login forms, APIs, endpoints de upload, manejo de sesiones.
Checklist Final#
- Existe autorización escrita del responsable legal/técnico para cada sesión de pentest
- El alcance (scope) está documentado: qué sistemas incluye y cuáles excluye
- Hay un canal de comunicación activo durante el pentest para reportar hallazgos críticos inmediatos
- El equipo de IT está avisado del horario del pentest (para no confundir con un ataque real)
- Se realizó reconocimiento externo para ver qué superficie expone la organización a internet
- Se corrió Nessus Essentials (o equivalente) en todos los sistemas en scope
- Las vulnerabilidades críticas (CVSS ≥ 9.0) tienen plan de remediación con fecha asignada
- Los hallazgos están documentados con evidencia, impacto y pasos de remediación
- Los hallazgos del pentest fueron revisados con el equipo técnico responsable
- Hay un proceso de re-test para verificar que las remediaciones aplicadas son efectivas
- El ciclo de pentesting tiene una frecuencia definida (trimestral o semestral mínimo)
CVE / Vulnerabilidades Relacionadas#
CVE-2024-27199 — JetBrains TeamCity (Crítico, CVSS 7.3)#
Esta es exactamente la vulnerabilidad del caso real descrito al inicio. Afecta a JetBrains TeamCity, una plataforma de CI/CD muy usada en entornos de desarrollo. Permite a un atacante no autenticado acceder a ciertos endpoints de administración del servidor, incluyendo la posibilidad de crear usuarios con privilegios administrativos.
¿Por qué es relevante para el pentesting? Porque es el tipo exacto de vulnerabilidad que los escáners de vulnerabilidades automáticos encuentran fácilmente — pero que nadie nota hasta que alguien hace el ejercicio de buscarla explícitamente. Muchas organizaciones tienen servidores de desarrollo/CI expuestos a internet "sin querer" por configuraciones de firewall incorrectas. El pentest externo lo descubre en minutos; sin él, puede pasar meses inadvertido.
La remediación es simple: aplicar el parche oficial (TeamCity 2023.11.4+) y verificar que la interfaz de administración no sea accesible desde internet. Un control de segmentación de red correcto hubiera evitado la exposición incluso sin el parche.
Regla que este CVE refuerza: Los servidores de infraestructura de desarrollo (CI/CD, repositorios de código, gestores de artefactos, plataformas de monitoreo) nunca deben ser accesibles desde internet directamente. Solo vía VPN o acceso controlado.
Conclusión y CTA#
El pentesting no es magia — es metodología. Con Nmap, Nessus Essentials y Metasploit Framework, un equipo técnico interno puede ejecutar una auditoría básica efectiva sin contratar consultores externos para cada ciclo. Los consultores siguen siendo valiosos para auditorías exhaustivas o cuando se necesita una perspectiva verdaderamente externa — pero la auditoría interna periódica es una práctica que toda organización puede adoptar hoy.
La única condición innegociable es la autorización. Con eso documentado, la metodología es la misma que usa un atacante, pero orientada a defender.
¿Querés ayuda para estructurar tu primer programa de pentesting interno? Hablá con nuestro equipo o seguí con el siguiente artículo: Red Team vs Blue Team: ejercicios de simulación que mejoran tu seguridad real.