Introducing browser isolation for email links to stop modern phishing threats

Existe una confianza implícita e inmerecida que depositamos en nuestras comunicaciones por correo electrónico. La premisa de que una organización no puede tener realmente una postura de seguridad Zero Trust sin incluir el correo electrónico, fue el detonante que nos impulsó a adquirir Area 1 Security a principios de este año. Hoy, hemos dado el primer paso en este emocionante viaje para integrar Area 1 de Cloudflare en nuestra plataforma general de Zero Trust. Los clientes de Cloudflare Gateway pronto podrán activar el aislamiento remoto del navegador (Remote Browser Isolation, RBI) para los enlaces de correo electrónico, lo que les proporcionará un nivel de protección inigualable frente a los modernos ataques multicanal contra el correo electrónico.

Un estudio de Area 1 de Cloudflare reveló que casi el 10 % de todos los ataques maliciosos observados recolectaban información de credenciales, lo que pone de manifiesto que la identidad de las víctimas es lo que los ciberdelincuentes suelen buscar. Si bien los ataques de phishing básicos se bloquean con controles de seguridad existentes, los ataques avanzados y las cargas útiles no tienen un patrón establecido que pueda coincidir de forma fiable con una regla de bloqueo o cuarentena. Además, con el aumento de los ataques de phishing multicanal, una solución eficaz de seguridad para el correo electrónico necesita poder detectar campañas combinadas que abarquen la entrega por correo electrónico y la web, así como campañas diferidas que sean benignas en el momento de la entrega, pero que se conviertan en un arma en un clic.

Cuando existen suficientes señales "difusas", la solución más eficaz es aislar el destino para garantizar la seguridad de los usuarios finales. Ahora, con la integración del Aislamiento de navegador de Cloudflare en la seguridad del correo electrónico del Área 1 de Cloudflare, estos ataques pueden detectarse y neutralizarse de forma sencilla.

Errar es humano

¿Por qué los usuarios hacen clic aún así en enlaces maliciosos? No es porque no hayan asistido a suficientes sesiones de formación o no sean conscientes de la seguridad. Es porque tienen 50 correos electrónicos sin leer en su bandeja de entrada, tienen reuniones de Zoom a las que asistir, y todo con un niño de cuatro años cargado en los hombros. Se esfuerzan al máximo. Cualquiera, incluidos los investigadores de seguridad, puede ser víctimas de ataques de ingeniería social si el adversario está bien preparado.

Si aceptamos que el error humano no es algo aislado, el desarrollo de flujos de trabajo de seguridad plantea nuevas preguntas y objetivos:

  • ¿Cómo podemos reducir, en lugar de eliminar, la probabilidad de un error humano?
  • ¿Cómo podemos reducir el impacto de un error humano cuando, y no si, ocurre?
  • ¿Cómo se puede integrar la seguridad en los flujos de trabajo diarios de los usuarios?  

Estas son las preguntas que teníamos en mente cuando llegamos a la conclusión de que el correo electrónico debe ser una parte fundamental de cualquier plataforma Zero Trust. Los usuarios cometen errores en el correo electrónico con la misma regularidad, de hecho, a veces más, que en la web.

¿Bloquear o no bloquear?

Para los equipos de TI, ésta es la cuestión con la que luchan a diario para equilibrar la mitigación de riesgos con la productividad de los usuarios. El equipo del COS quiere que el departamento de TI bloquee todo lo arriesgado o desconocido, mientras que la unidad de negocio quiere que el departamento de TI permita todo lo que no sea explícitamente malo. Si el departamento de TI decide bloquear los enlaces arriesgados o desconocidos, y eso da lugar a un falso positivo, pierden tiempo añadiendo manualmente las URL a las listas de permitidas, y quizá el atacante cambie después esas URL por contenido malicioso de todas formas. Si el departamento de TI decide permitir sitios peligrosos o desconocidos, en el mejor de los casos pierden tiempo recuperando los dispositivos infectados y restableciendo las credenciales de inicio de sesión, pero lo más habitual es que se ocupen de los daños causados por una violación de datos o un bloqueo por ransomware. La simplicidad operativa de habilitar el RBI con el correo electrónico (también conocido como aislamiento de enlaces de correo electrónico) ahorra un tiempo considerable a los departamentos de TI, COS y unidades de negocio.

Cómo funciona

Para un cliente del Aea 1 de Cloudflare, los pasos iniciales consisten en habilitar el RBI en su portal:

Con la activación del aislamiento del enlace de correo electrónico, el ciclo efímero de un correo electrónico con enlaces sospechosos es el siguiente:

Paso 1: El Area 1 de Cloudflare inspecciona el correo electrónico y determina que ciertos enlaces de los mensajes son sospechosos o están en el límite

Paso 2: las URL e hipervínculos del correo electrónico sospechosos se reescriben con una URL personalizada con prefijo de Area 1 de Cloudflare.

Paso 3: el correo electrónico se envía a las bandejas de entrada previstas.

Paso 4: si un usuario hace clic en el enlace del correo electrónico, Cloudflare redirige a un navegador remoto a través de <authdomain>.cloudflareaccess.com/browser/{{url}}.

Paso 5: El navegador remoto carga un sitio web en un servidor de la Red Global de Cloudflare y proporciona comandos de dibujo Zero Trust al punto final del navegador sin cliente del usuario.

Al ejecutar el código del navegador y controlar las interacciones del usuario en un servidor remoto y no en un dispositivo del usuario, se aíslan todos y cada uno de los intentos de malware y phishing, y no se infectarán los dispositivos ni se comprometerán las identidades de los usuarios. Esto mejora la seguridad tanto del usuario como del punto final cuando hay riesgos desconocidos y dispositivos no administrados, y permite a los usuarios acceder a sitios web sin tener que conectarse a una VPN o tener políticas de firewall estrictas.

La tecnología RBI de Cloudflare utiliza una tecnología patentada única llamada Network Vector Rendering (NVR) que utiliza navegadores sin encabezados basados en Chromium en la nube, intercepta de forma transparente la salida de la capa de dibujo, transmite los comandos de dibujo de forma eficiente y segura a través de la web, y los redibuja en las ventanas de los navegadores HTML5 locales. A diferencia de las tecnologías de aislamiento de navegadores heredadas, que se basaban en el empuje de píxeles o la reconstrucción del DOM, NVR está optimizado para ser escalable, segura y para la transparencia del usuario final, al tiempo que garantiza la compatibilidad general con los sitios web.

Ataque de phishing antes del aislamiento del enlace del correo electrónico

Veamos un ejemplo específico de un ataque de phishing diferido, cómo elude los sistemas de protección tradicionales y cómo el aislamiento del enlace del correo electrónico aborda la amenaza.

Conforme las organizaciones tratan de adoptar nuevos principios de seguridad y arquitecturas de red como Zero Trust, los adversarios no dejan de idear técnicas para eludir estos controles explotando la aplicación más utilizada y más vulnerable: el correo electrónico. El correo electrónico es un buen candidato para el riesgo debido a su ubicuidad y a la capacidad de ser evitado con bastante facilidad por un atacante motivado.

Tomemos un ejemplo de "ataque de phishing diferido" sin el aislamiento del enlace del correo electrónico.

Preparación del atacante: semanas antes del inicio del ataque
El atacante prepara la infraestructura para el intento de phishing que se avecina. Esto puede incluir:

  • Registrar un dominio
  • Cifrarlo con SSL
  • Configurar una autenticación de correo electrónico adecuada (SPF, DKIM, DMARC)
  • Crear una página web inofensiva

En este punto, no hay evidencia de un ataque que pueda captar pasarelas de correo electrónico seguras, soluciones basadas en la autenticación o la información sobre amenazas, ya que esta se basa únicamente en señales basadas en la reputación y otras técnicas de detección deterministas.

"Inicio" del ataque: domingo por la tarde
El atacante envía un correo electrónico que parece auténtico desde el dominio recién creado. Este correo incluye un enlace a la página web (todavía inofensiva). No hay nada en el correo electrónico para bloquearlo o señalizarlo como peligroso. El correo electrónico llega a las bandejas de entrada previstas.

Inicio del ataque: domingo por la noche
Una vez que el atacante está seguro de que todos los mensajes de correo electrónico han llegado a su destino, dirige el enlace a un destino malicioso cambiando la página web controlada por el atacante, quizás creando una página de inicio de sesión falsa para recabar credenciales.

Entrada del ataque: lunes por la mañana
Cuando los usuarios comprueban sus bandejas de entrada para empezar la semana, ven el correo electrónico. Quizá no todos hagan clic en el enlace, pero algunos sí. Tal vez todos los que han hecho clic no escriban sus credenciales, pero otros sí. Sin el aislamiento del enlace del correo electrónico, el ataque tiene éxito.

Las consecuencias del atacante solo acaban de empezar, una vez que se obtienen las credenciales de inicio de sesión, los atacantes pueden poner en peligro cuentas legítimas, distribuir malware a la red de la organización, robar información confidencial y causar muchos más daños posteriores.

Ataque de phishing tras el aislamiento del enlace del correo electrónico

La integración entre el Area 1 de Cloudflare y el Aislamiento de navegador de Cloudflare proporciona una capa crítica de protección posterior a la entrega que puede frustrar ataques como el ejemplo de phishing diferido descrito anteriormente.

Si el atacante se prepara y ejecuta el ataque como se indica en la sección anterior, nuestro aislamiento de enlaces de correo electrónico analizaría el enlace de correo electrónico en el momento de hacer clic y realizaría una evaluación de alto nivel sobre si el usuario debería poder navegar hasta él.

Enlace seguro: se redirigirá a los usuarios a este sitio de forma transparente

Enlace malicioso: se bloquea la navegación de los usuarios

Enlace sospechoso: se disuade a los usuarios de navegar y se les presenta una página de advertencia que les sugiere ver el enlace en un navegador aislado


Si bien la página de advertencia fue la táctica de mitigación empleada en el ejemplo anterior, el aislamiento de enlaces de correo electrónico también ofrece a los administradores de seguridad otras opciones de mitigación personalizables, como poner la página en modo de solo lectura, restringir la descarga y carga de archivos y deshabilitar la entrada del teclado por completo en sus consolas de Cloudflare Gateway.

El aislamiento del enlace del correo electrónico también se adapta a los flujos de trabajo existentes de los usuarios sin afectar a la productividad ni restarles tiempo con las incidencias informáticas. Dado que Cloudflare Browser Isolation opera en la red de Cloudflare, con ubicaciones globales en 270 ciudades, las sesiones de navegación web se sirven lo más cerca posible de los usuarios, minimizando la latencia. Además, Cloudflare Browser Isolation envía el resultado final de cada página web al usuario en lugar de limpiar la página o enviar un flujo de píxeles, que reduce aún más la latencia y no rompe las aplicaciones basadas en el navegador, como el SaaS.

Cómo empezar

Los clientes actuales del Area 1 de Cloudflare y Cloudflare Gateway pueden optar a la versión beta del aislamiento de enlaces de correo electrónico. Para obtener más información e indicar tu interés, inscríbase para participar en nuestra próxima beta.

Si desea ver qué amenazas detecta Area 1 de Cloudflare en su tráfico de correo electrónico en directo, solicite una evaluación gratuita del riesgo de phishing aquí. Para empezar, solo necesita cinco minutos y no afecta al flujo de correo.