Los ciberdelincuentes actuales comprenden cómo funcionan los gateway de correo electrónico. Saben que los gateways analizan los encabezados de los mensajes, inspeccionan el cuerpo y examinan minuciosamente los archivos adjuntos. Y cuando algo parece sospechoso, el gateway de correo electrónico coloca los archivos adjuntos y las URL en un entorno aislado para observar su comportamiento.
Como los ciberdelincuentes son conscientes de todo esto, han modificado su metodología de ataque. Mientras que antes preferían los archivos adjuntos maliciosos, ahora recurren cada vez más a las URL maliciosas. Según nuestro informe más reciente El factor humano vol. 2: phishing y amenazas basadas en URL, las URL se utilizan ahora cuatro veces más en los correos electrónicos maliciosos que los archivos adjuntos.
Para evitar ser detectados, los ciberdelincuentes suelen ocultar los componentes maliciosos de una URL tras barreras de autenticación o lógica condicional con el fin de eludir las medidas de seguridad. Un entorno aislado (sandbox) no puede emular fácilmente el comportamiento real del usuario. Por lo tanto, sin esta interacción auténtica del usuario, es posible que el entorno aislado nunca llegue a la parte maliciosa del ataque. Y los ciberdelincuentes no se limitan a manipular las URL. También encuentran formas de eludir por completo la infraestructura de protección del correo electrónico aprovechando las relaciones de confianza en las plataformas de colaboración.
A continuación se presentan tres casos reales que hemos observado, en los que los ciberdelincuentes diseñaron intencionadamente sus ataques para eludir las protecciones existentes. Cada uno demuestra una estrategia de elusión diferente.
Caso de uso 1: el exploit de verificación de enlaces - oculta detrás de la autenticación
En este primer caso de uso, un ciberdelincuente incluye en su correo electrónico un enlace que parece legítimo. Puede tratarse, por ejemplo, de un documento compartido en OneDrive, un archivo de Dropbox o una solicitud de DocuSign.
Funcionamiento
Cuando el gateway de correo electrónico analiza la URL en su entorno aislado (sandbox), solo encuentra una página de autenticación que requiere que los usuarios verifiquen su identidad. Se solicita a los usuarios que introduzcan una dirección de correo electrónico, proporcionen una contraseña, resuelvan un CAPTCHA o realicen otra verificación que demuestre que son humanos.
Elusión crítica: esta URL inicial no contiene ningún código malicioso.
Desde el punto de vista del sistema de seguridad, esta página se asemeja a una página de verificación estándar para un servicio legítimo de intercambio de archivos. El entorno aislado (sandbox) determina que la URL es segura y el correo electrónico se entrega a la bandeja de entrada del destinatario.
Solo después de que el usuario haya hecho clic en el enlace e introducido sus datos de autenticación, autorizará el servidor web el acceso a la página maliciosa. Esta página puede ser un formulario para recopilar datos de inicio de sesión, una descarga de malware o un sitio de phishing sofisticado. El ataque se encuentra detrás del requisito de autenticación. Es invisible para el análisis automatizado, que ya ha considerado el correo electrónico como seguro.
Figura 1. Ejemplo de exploit de verificación de enlaces.
La implicación
Aunque el gateway pueda detectar la URL maliciosa conocida detrás de la página de autenticación, nunca podrá analizar la página. La URL inicial es realmente válida. Por lo tanto, el gateway no reescribirá la URL para su análisis futuro y entregará el mensaje. La amenaza solo se revela una vez finalizado el análisis de seguridad y después de que el usuario haya aceptado autenticarse. Esta técnica transforma eficazmente las funciones de seguridad legítimas (páginas de autenticación) en un mecanismo de elusión.
Caso de uso 2: el espejismo del entorno aislado (sandbox) - detectar al detector
En este ataque más sofisticado, la infraestructura web del ciberdelincuente está especialmente diseñada para detectar si un visitante es humano o si se trata de un sistema de seguridad automatizado.
Funcionamiento
Cuando un correo electrónico que contiene una URL maliciosa llega al gateway, el sistema de seguridad lo abre en un entorno aislado (sandbox) para analizar su comportamiento antes de entregarlo.
Sin embargo, el servidor web del atacante analiza las solicitudes HTTP entrantes para diferenciar entre entornos aislados (sandbox) y usuarios reales. Los servidores web pueden examinar los siguientes elementos:
- Cadenas de agente de usuario. Los entornos aislados (sandbox) a menudo usan agentes de usuario identificables que revelan que son herramientas de seguridad automatizadas.
- Direcciones IP. Esto les indica si una solicitud proviene de rangos de IP de proveedores de seguridad conocidos o de una red de centros de datos.
- Encabezados HTTP. Los patrones en los encabezados como Referer, Accept-Language y otros atributos de solicitud difieren entre las herramientas automatizadas y los navegadores auténticos.
- Ejecución de JavaScript. Esto les indica si el cliente ejecuta JavaScript por completo, ya que algunos entornos aislados pueden cargar páginas sin ejecutar el script por completo.
- Patrones de acceso. Quieren saber si se trata de un acceso directo a la URL o de un recorrido natural a partir de una búsqueda o un cliente de correo electrónico.
Figura 2. Flujo de trabajo de una solicitud de página web.
Basándose en este análisis, si la solicitud parece provenir de un entorno aislado (sandbox), el servidor del ciberdelincuente redirige a una página web totalmente inofensiva o la difunde.
Por lo tanto, cuando el sistema de seguridad analiza la URL, determina que el contenido es seguro y se entrega el correo electrónico. Sin embargo, cuando un usuario hace clic en ese mismo enlace desde su terminal profesional equipado con un navegador estándar, el servidor del ciberdelincuente redirige al contenido malicioso o lo difunde.
La implicación
Cuando los ciberdelincuentes utilizan lógica del lado del servidor para distinguir entre analizadores de seguridad y objetivos humanos, el análisis estático o de un solo paso de las URL no es suficiente. El simple hecho de realizar una inspección automatizada puede ser detectado y explotado. Esto da lugar a un juego del gato y el ratón en el que los profesionales de la seguridad están perdiendo.
Caso de uso 3: la puerta trasera de Google Calendar - explotando ecosistemas de confianza
Este vector de ataque es especialmente insidioso, ya que no implica el envío de un correo electrónico. Por lo tanto, puede eludir por completo los gateways de protección del correo electrónico.
Funcionamiento
El proceso se desarrolla de la siguiente manera:
- Reconocimiento inicial. El ciberdelincuente identifica que la empresa XYZ utiliza Google Workspace.
- Creación de cuenta. El ciberdelincuente crea una cuenta de Gmail gratuita: badguy@gmail.com.
- Identificación de objetivos. Obtiene una lista de direcciones de correo electrónico de los empleados de la empresa XYZ.
- Creación de un evento de calendario. En su cuenta @gmail.com, el ciberdelincuente crea una invitación de calendario que incluye:
- Las direcciones de correo electrónico de los empleados objetivo
- Una URL de phishing incrustada en los detalles del evento
- Un archivo adjunto malicioso en formato PDF (disfrazado como documentos de reunión)
5. El paso crítico. En lugar de hacer clic en Enviar invitación, el ciberdelincuente simplemente guarda el evento del calendario como borrador.
En cuestión de segundos, la invitación del calendario aparece en los calendarios de todos los empleados objetivo de la empresa XYZ. Contiene la URL de phishing y el archivo adjunto malicioso. Como no se ha enviado ningún correo electrónico, el gateway de protección del correo electrónico nunca detecta la amenaza. Nunca tiene la oportunidad de analizar la URL o el archivo adjunto.
Figura 3. Ejemplo de exploit de Google Calendar.
Este ataque aprovecha la relación de confianza inherente a Google Workspace. Cuando se crean invitaciones de calendario dentro del ecosistema de Google, estas se sincronizan directamente entre las cuentas sin activar los mecanismos tradicionales de envío de correos electrónicos.
Los controles de seguridad diseñados para inspeccionar el tráfico de correo electrónico se eluden por completo, ya que la amenaza opera en la capa de aplicación, y no en la capa de transporte de correos electrónicos.
Desde el punto de vista del usuario, lo único que ve es una invitación de calendario legítima, por ejemplo, para una "revisión trimestral de actividades" o una "reunión con un proveedor", con un formato profesional y documentos adjuntos. Como llegó a través de una aplicación de confianza, no hay motivos para sospechar que haya eludido ningún control de seguridad.
La implicación
Este caso de uso revela una deficiencia crítica: las empresas que dependen únicamente de la protección del gateway de correo electrónico no ven las amenazas que transmiten las herramientas de colaboración.
A medida que el trabajo se vuelve cada vez más colaborativo y basado en la nube, los ciberdelincuentes adaptan sus técnicas para explotar las relaciones de confianza entre las aplicaciones integradas.
El camino a seguir
Para defenderse de estas tácticas de elusión, debe cambiar radicalmente su enfoque en materia de seguridad. En lugar de tener un único punto de inspección, necesita una protección completa y exhaustiva. Esto es lo que hay que buscar:
1: Protección avanzada del correo electrónico con análisis continuo
Necesita un sistema de seguridad que vaya más allá de la inspección inicial de la página y que garantice una supervisión continua y un análisis posterior a la entrega. Concretamente:
- Una reevaluación continua de las URL, incluso después de la entrega de los correos electrónicos.
- Un análisis de comportamiento que detecta anomalías en los patrones de interacción de los usuarios.
- Protección en el momento del clic que analiza las URL cuando los usuarios acceden a ellas, no solo cuando llegan los correos electrónicos.
2: Protección de la colaboración integrada en el navegador
Las amenazas llegan cada vez más a través de plataformas de colaboración que por correo electrónico. Por eso necesita controles de seguridad que funcionen allí donde los usuarios interactúan con el contenido: en el navegador. La protección nativa del navegador puede:
- Analizar redirecciones y URL anidadas en tiempo real, independientemente de cómo se hayan transmitido.
- Inspeccionar las amenazas en cada página del recorrido del usuario, no solo en la página de destino inicial.
- Detectar comportamientos maliciosos en invitaciones de calendario, documentos compartidos y plataformas de mensajería.
3: Defensa centrada en las personas
Ninguna tecnología puede sustituir a la concienciación sobre la seguridad. Debe formar a sus usuarios para que comprendan:
- Por qué deben sospechar de las URL que requieren autenticación inmediata, especialmente cuando se proporcionan credenciales en el mensaje.
- Cómo reconocer y denunciar invitaciones de calendario inusuales procedentes de terceros.
- Los controles de seguridad no son infalibles, y su criterio sigue siendo una capa de defensa esencial.
Conclusión
Los casos de uso detallados anteriormente no son teóricos: se trata de modelos de ataque activos observados en entornos empresariales reales. Si parte de la base de que su gateway de correo electrónico ofrece una protección completa, está operando con un peligroso punto ciego.
Descubra cómo Proofpoint Prime Threat Protection ofrece una protección completa y multicapa contra estas tácticas de elusión intencionadas.
