CASO DE ESTUDIO · TECHCORP LATAM · INGENIERÍA SOCIAL
Esta semana estuve analizando el factor humano en la seguridad: por qué llamar al usuario "el eslabón más débil" es la narrativa incorrecta, cómo se mide un programa de concientización que realmente cambia comportamiento, y los vectores de ingeniería social que el entrenamiento de phishing por correo no cubre. Hoy quiero bajar todo eso al caso concreto: lo que ocurrió en TechCorp Latam con el correo que fue el punto de entrada del ransomware.
EL CORREO QUE NADIE MARCÓ COMO SOSPECHOSO
El correo llegó a la bandeja de entrada del área administrativa de TechCorp Latam un martes a las 10:47 de la mañana. No llegó en horario inusual. No tenía errores ortográficos llamativos. No pedía información urgente ni amenazaba con consecuencias. Era un correo que parecía exactamente lo que decía ser: una factura de un proveedor con el que la empresa tenía relación comercial.
El dominio del remitente era proveedor-techcorp.com, no el dominio real del proveedor que era proveedortechcorp.com. La diferencia, un guión en un dominio que de otra forma era idéntico, no era visible de forma inmediata en el cliente de correo que mostraba solo el nombre del remitente en la bandeja de entrada. El asunto era "Factura #2847 — Pago pendiente." El cuerpo era profesional, breve y en el tono exacto de una comunicación de cobranza normal. El adjunto se llamaba Factura_2847.pdf.
El correo pasó los filtros de spam porque el dominio era nuevo, sin historial negativo previo, y el contenido no coincidía con firmas de correo malicioso conocidas. Llegó a la bandeja de entrada como cualquier otro correo comercial.
¿POR QUÉ EL USUARIO ABRIÓ EL ADJUNTO?
La persona que abrió el adjunto trabajaba en el área de administración y finanzas. Recibir facturas de proveedores era parte de su trabajo. Revisar y confirmar recepción también lo era. El correo era coherente con su rol diario, llegó en horario laboral normal, y no tenía ninguna señal obvia de alarma.
El adjunto era un PDF. Los PDFs de facturas son exactamente el tipo de documento que esa persona abría varias veces al día. La diferencia que no podía ver desde la bandeja de entrada es que ese PDF específico contenía una macro que se ejecutó al abrir el archivo, aprovechando una configuración de Adobe Acrobat Reader que permitía la ejecución de scripts en ese equipo.
Culpar a la persona que abrió el adjunto es tan útil como culpar al navegador de un barco que chocó porque no vio el iceberg. La pregunta relevante no es por qué abrió el PDF. Es por qué la organización no tenía procesos ni herramientas que hubieran interrumpido esa cadena antes de que el adjunto se ejecutara.
LO QUE HABRÍA NECESITADO EXISTIR
El ataque fue exitoso porque varias capas de defensa estaban ausentes simultáneamente. Eso no es mala suerte: es el resultado predecible de una postura de seguridad que había crecido en complejidad operacional sin que la cultura de seguridad creciera al mismo ritmo.
La verificación de dominios en el cliente de correo podría haber resaltado la diferencia entre proveedor-techcorp.com y proveedortechcorp.com. Una configuración de seguridad de Adobe Reader que deshabilite la ejecución de scripts habría neutralizado la macro. Un proceso de verificación para facturas que superen un umbral de monto, llamar al proveedor para confirmar antes de procesar, habría detectado que esa factura no existía. Una política de restricción de ejecución de macros en documentos recibidos por correo habría hecho irrelevante el PDF malicioso.
Ninguna de esas capas estaba activa. No porque alguien las hubiera desactivado deliberadamente, sino porque nunca habían sido parte formal de la postura de seguridad de TechCorp Latam. Eran brechas de proceso y configuración que existían en silencio, invisibles hasta que un atacante las usó.
ERROR COMÚN
Diseñar el programa de concientización alrededor del correo de phishing obvio: el que tiene errores ortográficos, el que pide credenciales directamente, el que amenaza con consecuencias inmediatas. Los ataques reales que tienen impacto significativo no son los obvios. Son los coherentes con el rol del destinatario, con dominio similar al real, con adjunto de tipo habitual, sin señales de alarma visibles. Si los simulacros son fácilmente identificables, el programa mide qué tan bien los usuarios reconocen los correos que diseñó TI, no los que diseñan los atacantes.
LO QUE CAMBIÓ DESPUÉS
Post-incidente, TechCorp Latam implementó los controles que faltaban. La nueva infraestructura Fortinet incluyó filtrado de correo con verificación de dominios similares y análisis de adjuntos en sandbox. Se estableció una política de restricción de macros en documentos recibidos por correo externo. Se definió un proceso de verificación para facturas que superan un umbral de monto.
Pero el cambio más importante no fue técnico. Fue la conversación que el incidente forzó sobre qué significa concretamente que cada área tiene responsabilidades específicas en la cadena de seguridad, con pasos definidos para cuando algo no cuadra y un canal claro para reportar.