Unidad 1

1

A01 - Análisis de un ciberataque

Febrero 2026, Equipo 4

Integrantes:

MatriculaNombre
177685Martinez Lara Santiago de la cruz
179033Alonso Castillo Omar Karim
177622Cruz Juárez Francisco Javier
175031Espinoza Aguilar Brian Salvador
173030Sánchez Ramirez Mayeli
177263Sánchez Zavala Alan Gilberto

Introducción

El 10 de noviembre de 2019, Petróleos Mexicanos (Pemex) fue víctima de un ataque de ransomware de escala nacional. El incidente, protagonizado por el grupo criminal Indrik Spider mediante la variante DoppelPaymer, paralizó sistemas administrativos, financieros y de logística. Este informe analiza de manera técnica, económica y estratégica el evento, subrayando que la falta de gestión de vulnerabilidades y el uso de sistemas legados fueron los catalizadores de una crisis que afectó la distribución de combustibles y la integridad de datos estratégicos de la nación.

Este informe analiza de manera técnica, económica y estratégica el evento, subrayando que la falta de gestión de vulnerabilidades y el uso de sistemas legados fueron los catalizadores de una crisis que afectó la distribución de combustibles y la integridad de datos estratégicos de la nación.

Desarrollo

Fase 1: Investigación y Documentación del Análisis de Actores y Herramientas

El ataque no fue una infección aleatoria, sino una operación de "Big Game Hunting" ejecutada por el grupo criminal Indrik Spider.

  • El Malvare: Se utilizó DoppelPaymer, una evolución del ransomware BitPaymer. Ejecución de hilos en paralelo para cifrado de alta velocidad.
  • Técnicas MITRE ATT&CK:
    • (T1566) Phishing: Vector inicial Dridex.
    • (T1021) Servicios Remotos: RDP y SMB para movimiento lateral.
    • (T1490) Inhibición de Recuperación: Eliminación automática de Shadow Copies.

Vulnerabilidades Iniciales

La superficie de ataque crítica se debió a tres factores:

  1. CVE-2017-0144 (EternalBlue): Protocolo SMBv1 activo en la red interna.
  2. CVE-2019-19781 (Citrix): Gateways desactualizados permitiendo RCE.
  3. Obsolescencia: Servidores Windows Server 2003/2008 en operación (End-of-Life).

Línea del Tiempo del Ataque

FECHA / FASEHITO CLAVEDESCRIPCIÓN TÉCNICA
Sept - Oct 2019Infiltración SilenciosaLos atacantes logran acceso inicial. Reconocimiento pasivo para identificar servidores de facturación y SAP críticos.
01 - 08 Nov 2019Movimiento LateralIndrik Spider utiliza herramientas como Mimikatz para extraer credenciales. Compromiso de cuentas de Administrador de Dominio.
09 Nov 2019Exfiltración de DatosRobo de 6.4 GB de información (contratos, correos) antes del cifrado. Fase de "Doble Extorsión".
10 Nov 2019 (08 AM)Detonación del CifradoEjecución masiva del ransomware. Bloqueo en centros de cómputo en CDMX, Tabasco y Edomex. Demanda de 565 BTC.
11 - 12 Nov 2019Respuesta de EmergenciaPemex apaga su red nacional. Instrucción de no encender equipos. Gobierno declara que no pagará rescate.
13 - 15 Nov 2019Impacto OperativoParálisis en Terminales de Almacenamiento (TAD). Facturación manual de pipas (papel y pluma), retrasando suministros.
30 Nov 2019Filtración Dark WebAl vencer el plazo, los atacantes publican los datos robados en el portal "Dopple Leaks".

Fase 2: Análisis de Impacto

Factores que facilitaron el ataque

FACTORDESCRIPCIÓN DE LA FALLAEVIDENCIA
Falla TécnicaGestión de Vulnerabilidades nula. EternalBlue sin parchear.Propagación lateral vía SMBv1.
Falla HumanaIngeniería Social (Phishing).Acceso inicial por ejecución de troyano.
Falla PolíticaRecortes presupuestales en TI y falta de mantenimiento.ASF confirmó falta de inversión preventiva.

Tabla Técnica del Ataque (Resumen Forense)

ELEMENTODESCRIPCIÓN
Tipo de ataqueRansomware (variante DoppelPaymer).
ActorIndrik Spider.
VectoresPhishing, RDP, SMB (EternalBlue).
Impacto MITRET1486 (Data Encrypted for Impact).

Impacto CIA

  • Confidencialidad (CRÍTICA): Filtración de secretos comerciales en Dark Web.
  • Integridad (ALTA): Cifrado irreversible de archivos y bases de datos.
  • Disponibilidad (MUY ALTA): Parálisis operativa por >10 días.

Análisis Económico

Costo del Rescate Solicitado: 565 BTC (~$94,374,000 MXN).

Estimación del Costo Total del Incidente

TIPO DE COSTODESCRIPCIÓNESTIMACIÓN (MXN)
Pérdidas operativasInactividad y procesos manuales.$500,000,000
Costos técnicosRespuesta, limpieza y nuevos licenciamientos.$150,000,000
Daños legalesAuditorías y multas.$25,000,000
TOTAL ESTIMADOSuma de impactos.$675,000,000

Reflexión Grupal

Analizando este caso, consideramos que el incidente de PEMEX no fue un error aislado, sino una consecuencia sistémica de la deuda técnica. Es sorprendente que una organización de tal magnitud dependiera de sistemas operativos obsoletos (Windows 2008) en 2019.

Desde nuestra perspectiva como futuros ingenieros en seguridad, este caso nos enseña que la tecnología más costosa (Firewalls, IDS) es inútil si no se tiene una cultura básica de higiene digital (parches) y concientización humana contra el phishing.

Conclusión y Lecciones

El ciberataque a PEMEX demostró que la ciberseguridad es un asunto de Seguridad Nacional. El costo de recuperación ($675M) superó por mucho el costo que hubiera tenido mantener la infraestructura actualizada.

Lección Clave: La prevención no es un gasto, es una inversión estratégica. Se requiere implementar arquitecturas Zero Trust y políticas de respaldo inmutables.

Referencias


A02 - ANÁLISIS DE SERVICIOS DE SEGURIDAD

ANÁLISIS DE SERVICIOS DE SEGURIDAD (X.800 Y RFC 4949)

AGREGAR PDF ORIGINAL!

Introducción

El presente informe tiene como propósito analizar diversos escenarios de incidentes de seguridad informática mediante la aplicación de los seis servicios de seguridad definidos en el estándar ITU-T X.800. Este marco conceptual es fundamental para identificar qué capacidad de seguridad ha sido vulnerada en una red de comunicaciones.

Para asegurar una comunicación técnica estandarizada y profesional, se integra la terminología establecida en el RFC 4949. La relevancia de este análisis radica en fortalecer la capacidad de documentar vulneraciones en contextos reales, permitiendo a los especialistas proponer medidas de control coherentes y viables.

Ficha Técnica de Análisis de Escenarios

EscenariosElementoAnálisis de Caso: Respuesta Técnica
Escenario 01Servicios X.800 comprometidos:Confidencialidad, Integridad y Disponibilidad.
Definición(es) RFC 4949:Multi-stage attack: Ataque ejecutado en fases secuenciales. Data breach: Divulgación no autorizada de información sensible. Availability attack: Objetivo de impedir el acceso legítimo a recursos.
Tipo de amenaza:Externa (Cibercrimen organizado).
Impacto técnico/operativo:Cifrado masivo de servidores, pérdida de acceso a sistemas críticos y alto riesgo reputacional.
Medida de control:Implementación de respaldos inmutables y sistemas de cifrado de datos en reposo.
Escenario 02Servicios X.800 comprometidos:Confidencialidad y Control de acceso.
Definición(es) RFC 4949:Misconfiguration: Configuración incorrecta que introduce vulnerabilidades. Exposure: Condición donde la información queda accesible sin protección.
Tipo de amenaza:Externa por error interno (falla pasiva).
Impacto técnico/operativo:Exposición pública de datos sensibles y posibles sanciones legales.
Medida de control:Monitoreo continuo de accesos y auditorías de configuraciones de nube.
Escenario 03Servicios X.800 comprometidos:Integridad y Confidencialidad.
Definición(es) RFC 4949:Supply chain attack: Ataque vía proveedor confiable. Trust exploitation: Abuso de una relación de confianza para acciones no autorizadas.
Tipo de amenaza:Externa (vía terceros).
Impacto técnico/operativo:Instalación de código malicioso en múltiples organizaciones y ruptura de confianza en el proveedor.
Medida de control:Verificación de integridad de actualizaciones y uso de firmas digitales obligatorias.
Escenario 04Servicios X.800 comprometidos:Autenticación y Control de acceso.
Definición(es) RFC 4949:Phishing: Ingeniería social para obtener información. Credential compromise: Robo de credenciales válidas por un atacante.
Tipo de amenaza:Externa.
Impacto técnico/operativo:Acceso persistente no detectado y robo masivo de información personal.
Medida de control:Implementación de doble factor de autenticación (MFA) y detección de patrones inusuales.
Escenario 05Servicios X.800 comprometidos:Disponibilidad e Integridad.
Definición(es) RFC 4949:Data destruction: Eliminación intencional de información. Availability attack: Servicios en peligro por falta de accesibilidad.
Tipo de amenaza:Externa.
Impacto técnico/operativo:Pérdidas económicas críticas por manipulación y borrado de respaldos.
Medida de control:Diversificación de medios de respaldo y pruebas periódicas de restauración.
Escenario 06Servicios X.800 comprometidos:Confidencialidad y Control de acceso.
Definición(es) RFC 4949:Insider threat: Amenaza originada por un individuo con acceso legítimo a la red.
Tipo de amenaza:Interna.
Impacto técnico/operativo:Fuga masiva de bases de datos críticas para venta a terceros; falla de confianza institucional.
Medida de control:Aplicación del principio de mínimo privilegio y auditoría estricta de privilegios de usuario.
Escenario 07Servicios X.800 comprometidos:Integridad y No repudio.
Definición(es) RFC 4949:Evidentiary integrity: Violación de la integridad de las pruebas. Audit trail: Compromiso del rastro de auditoría.
Tipo de amenaza:Externa (Anti-forense).
Impacto técnico/operativo:Incapacidad legal para demostrar responsabilidades; impacto probatorio y legal severo.
Medida de control:Centralización de logs en servidores de solo lectura y protección criptográfica de registros.
Escenario 08Servicios X.800 comprometidos:Disponibilidad.
Definición(es) RFC 4949:Operational failure: Caída de servicios por errores en procesos operativos internos.
Tipo de amenaza:Interna accidental.
Impacto técnico/operativo:Caída simultánea de servicios globales; parálisis operativa masiva.
Medida de control:Protocolos estrictos de pruebas de pre-producción y planes de reversión (rollback).
Escenario 09Servicios X.800 comprometidos:Autenticación y Confidencialidad.
Definición(es) RFC 4949:Masquerade: Suplantación de identidad. Phishing: Engaño para recolectar datos sensibles.
Tipo de amenaza:Externa (Ingeniería social).
Impacto técnico/operativo:Recolección ilícita de datos de ciudadanos; pérdida de credibilidad institucional.
Medida de control:Autenticación de dominio (DMARC) y campañas de concienciación ciudadana.
Escenario 10Servicios X.800 comprometidos:Confidencialidad, Integridad y Disponibilidad.
Definición(es) RFC 4949:Destructive attack: Acción orientada a la destrucción total de sistemas y rastros.
Tipo de amenaza:Externa (Ataque total).
Impacto técnico/operativo:Daño irreversible a la infraestructura y eliminación total de evidencia forense.
Medida de control:Implementación de segmentación de red y sistemas de respuesta rápida ante incidentes.

Reflexión

El análisis detallado revela que la mayoría de los incidentes en el entorno latinoamericano derivan de una gestión insuficiente de los servicios de autenticación y control de acceso. La sofisticación de ataques como el supply chain attack o las amenazas internas (insider threats) demuestra que las organizaciones deben transitar hacia modelos de "Confianza Cero" (Zero Trust), donde la integridad de los datos y la disponibilidad se protejan no solo con barreras perimetrales, sino con monitoreo continuo y robustecimiento de procesos operativos.

Referencias


A03 - Políticas de IPTables

En breve se mostrará la interpretación y traducción de las políticas de IPTables

AGREGAR PDF!

Introducción

El filtrado de paquetes es una de las técnicas fundamentales para la defensa de redes. En esta actividad, se explora el uso de iptables, una herramienta estándar en sistemas Linux para definir reglas de firewall.

El objetivo es comprender cómo fluyen los datos a través de las distintas tablas y cadenas del kernel, así como traducir políticas de seguridad teóricas en comandos técnicos ejecutables.

Flujo de Paquetes

Pregunta 1: Completa los espacios conforme se explica el flujo del paquete.

"Cuando un paquete llega al sistema, primero pasa por una <u>Tabla</u>, después por una <u>Cadena</u> y finalmente se ejecuta una <u>Acción/Regla</u>."

Tablas de IPTables

TablaPropósito PrincipalEjemplo de Uso
FILTERFiltrado de paquetes (Aceptar/Rechazar).Proteger Servidor Web.
NATTraducción de Direcciones de Red.Compartir Internet (Masquerade).
MANGLEAlteración de cabeceras de paquetes.Calidad de Servicio (QoS/TOS).
RAWConfiguración antes del seguimiento de conexiones.Exención (NOTRACK).
SECURITYControl de acceso obligatorio (MAC).Soporte SELinux.

Anatomía de un comando

El siguiente comando permite aceptar tráfico TCP entrante destinado específicamente a los puertos 80 (HTTP) y 443 (HTTPS), utilizado típicamente para servidores web.

iptables -A [INPUT] -p tcp -m [multiport] --dports 80,443 -j [ACCEPT]

Variables y opciones comunes

  • Limitar intentos por minuto: -m limit --limit X/min
  • Filtrar por IP de origne: --SOURCE / -s 192.168.0.1/24
  • Ver solo números (sin DNS): -L -n
  • Ver reglas con contadores: -L -v

Análisis de regla

¿Que hace la siguiente regla?

iptables -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 \ -m state --state NEW,ESTABLISHED -j ACCEPT

Permite el tráfico entrante a través de la interfaz eth0, usando el protocolo TCP hacia los puertos 22 (SSH), 80 (HTTP) y 443 (HTTPS). Adicionalmente, restringe la aceptación solo a conexiones que sean NUEVAS o que ya estén ESTABLECIDAS.

Traducción de Políticas

  • Permitir tráfico HTTP entrante iptables -A INPUT -p tcp --dport 80 -j ACCEPT
  • Permitir todo el tráfico saliente iptables -A OUTPUT -j ACCEPT
  • Permitir SSH solo desde la IP 192.168.1.50 iptables -A INPUT -p tcp -s 192.168.1.50 --dport 22 -j ACCEPT
  • Permitir tráfico TCP entrante a puertos 80 y 443 solo si es conexión establecida o relacionada iptables -A INPUT -p tcp -m multiport --dports 80,443 -m state --state ESTABLISHED,RELATED -j ACCEPT
  • Permitir tráfico entrante por eth0 a 22, 80, 443 + registrar intentos + solo NEW/ESTABLISHED iptables -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j LOG --log-prefix "ACCESO_PERMITIDO: " y iptables -A INPUT -i eth0 -p tcp -m multiport --dports 22,80,443 -m state --state NEW,ESTABLISHED -j ACCEPT

La implementación de políticas en iptables requiere un entendimiento profundo no solo de la sintaxis del comando, sino del modelo TCP/IP. Un error común es olvidar permitir el tráfico de respuesta (ESTABLISHED), lo que puede cortar la conexión del propio administrador.Esta actividad refuerza la importancia del principio de "Denegar por defecto" (DROP policy), abriendo únicamente los puertos estrictamente necesarios para reducir la superficie de ataque.

Referencias


A04 - Defensa a Profundidad

AGREGAR PDF

Introducción

La defensa en red se basa en la implementación de controles estrictos sobre el flujo de información entre zonas de diferente nivel de confianza (Internet, DMZ, LAN). En esta actividad, se configuran reglas específicas de iptables para filtrar tráfico en un firewall perimetral, protegiendo servicios críticos como correo (SMTP), web (HTTP) y resolución de nombres (DNS).

Se aplica el principio de Mínimo Privilegio, donde todo lo que no está explícitamente permitido, está prohibido.

Reglas de FIltrado

A continuación se detallan las reglas aplicadas según la topología de red analizada.

#Acción SolicitadaRegla de iptables
1Política Restrictivaiptables -P INPUT DROPiptables -P FORWARD DROPiptables -P OUTPUT DROP
2Tráfico Establecidoiptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
3DNS (TCP) saliente de LANiptables -A FORWARD -p tcp -s 192.1.2.0/24 -d 0.0.0.0/0 --dport 53 -m state --state NEW -j ACCEPT
4Correo entrante (SMTP)iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 192.1.2.10 --dport 25 -m state --state NEW -j ACCEPT
5Correo saliente (SMTP)iptables -A FORWARD -p tcp -s 192.1.2.10 -d 0.0.0.0/0 --dport 25 -m state --state NEW -j ACCEPT
6HTTP entrante a Webiptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 192.1.2.11 --dport 80 -m state --state NEW -j ACCEPT
7HTTP saliente de LANiptables -A FORWARD -p tcp -s 192.1.2.0/24 -d 0.0.0.0/0 --dport 80 -m state --state NEW -j ACCEPT

Reflexión

La configuración realizada demuestra una postura de seguridad robusta. Al establecer políticas DROP por defecto en todas las cadenas, garantizamos que solo los flujos de tráfico legítimos (DNS, SMTP, HTTP) definidos en la planeación puedan atravesar el firewall.Es crucial notar el uso del módulo state. Permitir el tráfico ESTABLISHED,RELATED en la regla 2 es vital; sin ella, los paquetes de retorno de las conexiones legítimas serían bloqueados, rompiendo la comunicación. Esta es la base de un firewall Stateful (con estado).

Referencias


A05 - Cartografiafía durante el Pentesting

AGREGAR PDF

Introducción

El presente documento realiza un análisis comparativo de las principales metodologías y marcos de referencia utilizados en la industria de la ciberseguridad. El objetivo es identificar las características, fases y objetivos de cada estándar para determinar su aplicabilidad según distintos escenarios de evaluación técnica y cumplimiento normativo.

Comparación de Metodologías

A continuación se presenta el análisis detallado de los frameworks seleccionados.

MetodologíaA. DescripciónB. Fases de ImplementaciónC. Objetivo PrincipalD. Escenarios de UsoH. CertificacionesI. Versión
MITRE ATT&CKBase de conocimientos de Tácticas y Técnicas basadas en ataques reales.Tácticas, Técnicas y Procedimientos (TTPs).Clasificar comportamientos de adversarios.SOC, Threat Hunting y emulación de ataques.CDEv14
OWASP WSTGMarco integral para pruebas de seguridad en aplicaciones web.1. Recolección de información, 2. Configuración, 3. Identidad, 4. Autenticación, 5. Autorización, etc.Evaluación técnica de controles en software web.Auditorías web, móviles y de APIs.GWAPT, OSWEv4.2
NIST SP 800-115Guía técnica federal para realizar pruebas y exámenes de seguridad.1. Planificación, 2. Descubrimiento, 3. Ejecución, 4. Post-ejecución.Estandarizar pruebas técnicas y reportes.Entornos gubernamentales y regulados.Security+, CISSPFinal
OSSTMMEstándar científico para la verificación de seguridad operacional.1. Inducción, 2. Interacción, 3. Interrogación, 4. Evaluación.Medición métrica de la seguridad (RAVs).Redes, Wireless, Física e Ingeniería Social.OPST, OPSA3.0
PTESEstándar que define las etapas mínimas de un pentest de calidad.1. Pre-engagement, 2. Intel, 3. Modelado, 4. Análisis, 5. Explotación, 6. Post-Exp, 7. Reporte.Estandarizar el proceso comercial y técnico del pentest.Auditorías profundas de infraestructura.OSCP, CPTS1.1
ISSAFMarco detallado que vincula la técnica con la gestión y auditoría.1. Planificación, 2. Evaluación, 3. Informes, 4. Limpieza, 5. Destrucción.Guía técnica paso a paso para auditorías completas.Auditorías integrales de sistemas complejos.CISA (Base)v0.2.1

Reflexión

Tras analizar los distintos marcos, concluyo que no existe una "bala de plata". La elección depende enteramente del alcance. Para una aplicación web crítica, OWASP WSTG es insustituible. Sin embargo, para un ejercicio de Red Team completo, MITRE ATT&CK es el estándar para modelar amenazas.En un entorno profesional, la combinación de PTES para la gestión del proyecto y OSSTMM para la métrica operativa ofrece un equilibrio sólido entre calidad técnica y valor de negocio.

Referencias


A06 - IPSEC VPN

A continuación se muestra la implementación de IPSEC y VPN en routers CISCO