Subscribe to receive notifications of new posts:

Dinámicas de una estafa sofisticada de phishing y cómo la detuvimos

08/09/2022

10 min read
The mechanics of a sophisticated phishing scam and how we stopped it

Ayer, 8 de agosto de 2022, Twilio anunció que había sido víctima de un ataque de phishing selectivo. Más o menos al mismo tiempo, observamos otra ofensiva con características muy similares dirigida a los empleados de Cloudflare. Si bien algunos empleados cayeron en la trampa de los mensajes de phishing, pudimos frenar el ataque con nuestro paquete de productos Cloudflare One, y las claves de seguridad físicas que facilitamos a todos los empleados para que puedan acceder a nuestras aplicaciones.

Hemos confirmado que ningún sistema de Cloudflare se vio expuesto. Cloudforce One, nuestro equipo de información sobre amenazas, pudo realizar un análisis adicional para examinar el mecanismo del ataque y recabar pruebas críticas para ayudar a localizar al ciberdelincuente.

La sofisticación del ataque contra empleados y sistemas nos lleva a pensar que la mayoría de las organizaciones se podrían ver afectadas. Puesto que el ciberdelincuente se dirige a varias organizaciones, queríamos compartir en esta publicación un resumen de lo que vimos exactamente para ayudar a otras empresas a reconocer y mitigar este ataque.

Smishing

El 20 de julio de 2022, empleados de Cloudflare notificaron al equipo de seguridad de Cloudflare que estaban recibiendo mensajes aparentemente legítimos que apuntaban a lo que parecía ser una página de inicio de sesión de Cloudflare Okta. Los mensajes comenzaron el 20 de julio de 2022 a las 22:50 UTC. En el transcurso de menos de 1 minuto, al menos 76 empleados recibieron mensajes de texto en sus teléfonos móviles personales y corporativos, así como algunos de sus familiares. Todavía no hemos podido determinar cómo el atacante consiguió la lista de números de teléfono de los empleados, pero hemos revisado los registros de acceso a nuestros servicios de directorio de empleados y no hemos encontrado ningún indicio de riesgo.

Cloudflare cuenta con un equipo de Respuesta a Incidentes de Seguridad (SIRT) 24 horas al día. Todos los empleados de Cloudflare están formados para informar de cualquier evento sospechoso al SIRT. Más del 90 % de los informes al SIRT resultan no ser amenazas, pero se insta a los empleados a que informen de cualquier anomalía y nunca se les disuade de enviar demasiadas denuncias. Si embargo, en este caso, se trataba de una amenaza real.

Los mensajes de texto que recibieron los empleados tenían este aspecto:

Procedían de tres números de teléfono asociados a tarjetas SIM de T-Mobile: (754) 268-9387, (205) 946-7573, (754) 364-6683 y (561) 524-5989, y apuntaban a un dominio aparentemente oficial: cloudflare-okta.com. Ese dominio se registró a través de Porkbun, un registrador de dominios, el 20 de julio de 2022 a las 22:13:04 (hora UTC), menos de 40 minutos antes del inicio de la campaña de phishing.

Cloudflare creó nuestro registrador seguro en parte para poder controlar cuándo se registraban dominios que utilizaban la marca Cloudflare y cerrarlos. Sin embargo, debido a que este dominio se había registrado recientemente, aún no se había publicado como un nuevo registro ".com", por lo que nuestros sistemas no lo detectaron y nuestro equipo no lo había cerrado aún.

Si hiciste clic en el enlace, te llevó a una página de phishing, que estaba alojada en DigitalOcean y tenía el siguiente aspecto:

Cloudflare utiliza Okta como nuestro proveedor de identidad. La página de phishing estaba diseñada para parecer idéntica a una página legítima de inicio de sesión de Okta y solicitaba a cualquier visitante su nombre de usuario y contraseña.

Phishing en tiempo real

Pudimos analizar la carga útil del ataque de phishing basándonos en lo que recibieron nuestros usuarios, así como en el contenido que otras empresas víctimas habían publicado en servicios como VirusTotal. Cuando la víctima completaba la página de phishing, las credenciales se transmitían inmediatamente al atacante a través del servicio de mensajería Telegram. Esta transmisión en tiempo real era importante porque la página de phishing también solicitaba una contraseña de un solo uso de duración definida (TOTP).

Supuestamente, el ciberdelincuente recibía las credenciales en tiempo real, las escribía en la página de inicio de sesión auténtica de la empresa afectada y, en el caso de muchas organizaciones, eso generaba un código que se enviaba al empleado por SMS o se mostraba en un generador de contraseñas. A continuación, el empleado escribía el código TOTP en el sitio de phishing, y también se transmitía al atacante. Este podía entonces, antes de la expiración del código TOTP, utilizarlo para acceder a la página de inicio de sesión real de la empresa, anulando así la mayoría de las implementaciones de autenticación en dos fases.

Protección, aunque no sea perfecta

Confirmamos que tres empleados de Cloudflare cayeron en la trampa del mensaje de phishing y escribieron sus credenciales. Sin embargo, Cloudflare no utiliza códigos TOTP. En su lugar, cada usuario recibe una clave de seguridad compatible con FIDO2 de un proveedor como YubiKey. Dado que las claves de seguridad están vinculadas a los usuarios e implementan el enlace al origen, incluso una actividad de phishing sofisticada en tiempo real como esta no puede recopilar la información necesaria para iniciar sesión en cualquiera de nuestros sistemas. Aunque el ciberdelincuente intentó iniciar sesión en nuestros sistemas con las credenciales de nombre de usuario y contraseña en riesgo, no pudo superar el requisito de la clave de seguridad.

Sin embargo, esta página de phishing no buscaba simplemente credenciales y códigos TOTP. Si alguien lograba superar esas medidas, la página de phishing iniciaba la descarga de una carga útil de phishing que incluía el software de acceso remoto de AnyDesk. Ese software, si se instalaba, permitía al atacante controlar el equipo de la víctima de forma remota. Confirmamos que ninguno de los miembros de nuestro equipo llegó hasta ahí. Sin embargo, si lo hubieran hecho, nuestra seguridad de puntos finales habría detenido la instalación del software de acceso remoto.

¿Cómo respondimos?

Las principales acciones de respuesta que tomamos para este incidente fueron:

1. Bloquear el dominio de phishing mediante Cloudflare Gateway

Cloudflare Gateway es una solución de puerta de enlace web segura que proporciona protección para datos y contra amenazas con filtrado DNS/HTTP y Zero Trust integrado de forma nativa. Utilizamos esta solución internamente para identificar de manera proactiva los dominios maliciosos y bloquearlos. Nuestro equipo añadió el dominio malicioso a Cloudflare Gateway para bloquear el acceso de todos los usuarios.

La detección automática de dominios maliciosos de Gateway también identificó el dominio y lo bloqueó, pero el hecho de que se registrara y se enviaran mensajes en un intervalo de tiempo tan corto significaba que el sistema no había actuado automáticamente antes de que algunos usuarios hicieran clic en los enlaces. A raíz de este incidente, estamos trabajando para acelerar la rapidez con la que se identifican y bloquean los dominios maliciosos. También estamos implementando controles sobre el acceso a los dominios recién registrados que ofrecemos a los clientes, pero que no implementamos nosotros.

2. Identificar a todos los usuarios de Cloudflare afectados y restablecer las credenciales en riesgo

Pudimos comparar los destinatarios de los mensajes de phishing con la actividad de inicio de sesión e identificar los intentos de autenticación del ciberdelincuente en las cuentas de nuestros usuarios. Identificamos que tras varios intentos de inicio de sesión fallidos se había bloqueado el acceso debido a los requisitos de la clave de seguridad (U2F) que indicaban que se había utilizado la contraseña correcta, pero no se había podido verificar el segundo factor. En el caso de los tres empleados cuyas credenciales se filtraron, restablecimos sus credenciales y cualquier sesión activa, y analizamos sus dispositivos.

3. Identificar y eliminar la infraestructura del ciberdelincuente

El dominio de phishing del ciberdelincuente se había registrado hace poco a través de Porkbun y se alojaba en DigitalOcean. El dominio de phishing utilizado para atacar a Cloudflare se creó menos de una hora antes de la primera oleada de phishing. El sitio tenía un frontend Nuxt.js y un backend Django. Trabajamos con DigitalOcean para cerrar el servidor del atacante, y con Porkbun para tomar el control del dominio malicioso.

A partir de los intentos fallidos de inicio de sesión, pudimos comprobar que el ciberdelincuente estaba aprovechando el software de VPN Mullvad y utilizando específicamente el navegador Google Chrome en un equipo Windows 10. Las direcciones IP de la VPN utilizadas por el atacante eran 198.54.132.88 y 198.54.135.222. Esas direcciones IP están asignadas a Tzulo, un proveedor de servidores dedicados con sede en Estados Unidos cuyo sitio web afirma tener servidores en Los Ángeles y Chicago. En realidad, parece que el primero estaba funcionando en un servidor de la zona de Toronto y el segundo en un servidor de la zona de Washington, D.C. Bloqueamos estas direcciones IP para que no pudieran acceder a ninguno de nuestros servicios.

4. Actualizar las detecciones para identificar cualquier intento de ataque posterior

Con lo que pudimos descubrir sobre este ataque, incorporamos señales adicionales a nuestras detecciones existentes para identificar específicamente a este ciberdelincuente. En el momento de escribir esta publicación, no hemos observado ninguna otra oleada de ataques dirigida a nuestros usuarios. Sin embargo, la información del servidor indicaba que el ciberdelincuente se dirigía a otras organizaciones, incluida Twilio. Nos pusimos en contacto con ellas y compartimos la información sobre el ataque.

5. Verificar los registros de acceso al servicio para      detectar cualquier otro indicio de ataque

Tras el ataque, revisamos todos los registros de nuestro sistema en busca de cualquier otra huella digital de este ciberdelincuente en particular. Cloudflare Access sirve como punto de control central para todas las aplicaciones de Cloudflare, de ahí que podamos buscar en los registros cualquier indicio de que el atacante haya vulnerado algún sistema. Dado que los teléfonos de los empleados fueron el objetivo, también revisamos minuciosamente los registros de nuestros proveedores de directorios de empleados. No encontramos ninguna prueba que apuntara a un riesgo.

Lecciones aprendidas y medidas adicionales que estamos adoptando

Aprendemos de cada ataque. Si bien el ciberdelincuente no logró su objetivo, estamos haciendo algunos reajustes con lo que hemos aprendido. Estamos ajustando la configuración de Cloudflare Gateway para restringir o aislar el acceso a los sitios que se ejecutan en los dominios que se registraron en las últimas 24 horas. También ejecutaremos cualquier sitio no incluido en la lista de permitidos que contenga términos como "cloudflare" "okta" "sso" y "2fa" a través de nuestra tecnología de aislamiento del navegador. Además, estamos utilizando cada vez más la tecnología de identificación de phishing de Area 1 para analizar la web y buscar cualquier página que esté diseñada para atacar a Cloudflare. Por último, estamos introduciendo algunos ajustes a nuestra implementación de Access para evitar cualquier inicio de sesión desde VPN, proxies domésticos y proveedores de infraestructura desconocidos. Todas estas son funciones estándar de los mismos productos que ofrecemos a los clientes.

El ataque también reafirmó la importancia de tres cosas que estamos haciendo bien. En primer lugar, solicitar claves de seguridad para el acceso a todas las aplicaciones. Al igual que Google, no hemos visto ningún ataque de phishing que se haya materializado con éxito desde la implementación de las claves de seguridad. Herramientas como Cloudflare Access han facilitado la compatibilidad con las claves de seguridad incluso en las aplicaciones heredadas. Si te interesa saber cómo hemos implementado las claves de seguridad, ponte en contacto con [email protected]y nuestro equipo de seguridad estará encantado de compartir las prácticas recomendadas que hemos aprendido durante el proceso.

En segundo lugar, utilizamos nuestra propia tecnología para proteger a nuestros usuarios y sistemas. Las soluciones de Cloudflare One, como Access y Gateway, fueron fundamentales para anticiparnos al ataque. Configuramos nuestra implementación de Access para que solicite claves de seguridad en cada aplicación. Además, crea una ubicación de registro central para todas las autenticaciones de aplicaciones, y, en caso de ser necesario, un lugar desde el que podemos eliminar las sesiones de un usuario potencialmente en riesgo. Gateway nos permite cerrar rápidamente los sitios maliciosos como este y entender qué usuarios han podido ser víctimas del ataque. Todas estas son funciones que ponemos a disposición de los clientes de Cloudflare como parte de nuestro conjunto de productos Cloudflare One, y este ataque demuestra lo eficaces que pueden ser.

En tercer lugar, la seguridad exige pecar de prudencia, pero no se trata de buscar culpables. No se amonestó a los tres empleados que cayeron en la estafa del phishing. Todos somos humanos y cometemos errores. Es muy importante que, cuando los cometamos, los mencionemos y no los encubramos. Este incidente es otro ejemplo de por qué la seguridad es un trabajo conjunto de todos los miembros del equipo de Cloudflare.

Cronología detallada de los acontecimientos

2022-07-20 22:49 UTC El ciberdelincuente envía más de 100 SMS a los empleados de Cloudflare y sus familias.
2022-07-20 22:50 UTC Los empleados empiezan a informar de los mensajes SMS al equipo de seguridad de Cloudflare.
2022-07-20 22:52 UTC Se comprueba que el dominio del ciberdelincuente está bloqueado en Cloudflare Gateway para los dispositivos corporativos.
2022-07-20 22:58 UTC Comunicación de advertencia enviada a todos los empleados a través del chat y el correo electrónico.
2022-07-20 22:50 UTC ~
2022-07-20 23:26 UTC
Supervisión de la telemetría en el registro del sistema de Okta y los registros HTTP de Cloudflare Gateway para localizar las credenciales en riesgo. Eliminación de las sesiones de inicio de sesión y suspensión de las cuentas en riesgo.
2022-07-20 23:26 UTC El proveedor de alojamiento suspende el sitio de phishing.
2022-07-20 23:37 UTC Se restablecen las credenciales filtradas de los empleados.
2022-07-21 00:15 UTC Análisis exhaustivo de la infraestructura y capacidades del atacante.

Indicadores del riesgo

Valor Tipo Contexto y evaluación MITRE
cloudflare-okta[.]com alojado en 147[.]182[.]132[.]52 URL de Phishing T1566.002: Phishing: Enlace de phishing de objetivo definido enviado a los usuarios.
64547b7a4a9de8af79ff0eefadde2aed10c17f9d8f9a2465c0110c848d85317a SHA-256 T1219: Software de acceso remoto distribuido por el ciberdelincuente

¿Qué medidas puedes implementar?

Si estás siendo testigo de ataques similares en tu entorno, no dudes en ponerte en contacto con [email protected]. Estaremos encantados de compartir las prácticas recomendadas sobre cómo garantizar la seguridad de tu empresa. Si, por el contrario, te interesa saber más sobre cómo implementamos las claves de seguridad, consulta nuestra publicación en el blog o ponte en contacto con [email protected].

Por último, ¿quieres trabajar en la detección y mitigación de los próximos ataques con nosotros? Estamos buscando profesionales que quieran incorporarse a nuestro equipo de Detección y Respuesta, ¡únete a nosotros!

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Security (ES)Post Mortem (ES)Cloudflare Gateway (ES)Cloudflare Access (ES)Español

Follow on X

Matthew Prince|@eastdakota
Daniel Stinson-Diess|@shellcromancer
Cloudflare|@cloudflare

Related posts

April 12, 2024 1:00 PM

Cómo Cloudflare evitará que los clientes se vean afectados por el próximo cambio en la cadena de certificados de Let's Encrypt con su sólida canalización de certificados

La cadena de certificados con firma cruzada de Let's Encrypt expirará en septiembre. Esta novedad afectará a los dispositivos heredados con almacenes de confianza obsoletos...

March 08, 2024 2:22 AM

Log Explorer supervisa los eventos de seguridad sin almacenamiento de terceros

La eficacia conjunta de nuestros análisis de seguridad y Log Explorer permite a los equipos de seguridad analizar, investigar y supervisar los ataques a la seguridad de forma nativa en Cloudflare. De esta forma, conseguimos reducir el tiempo de resolución y el coste total de propiedad para nuestros...

March 05, 2024 2:02 PM

Protege tus activos expuestos con nuestro Centro de seguridad: resumen para los CISO

Hoy nos complace anunciar un nuevo conjunto de capacidades en nuestro Centro de seguridad para abordar directamente un desafío común: garantizar una implementación completa en toda tu infraestructura. Consigue información precisa sobre dónde y cómo optimizar tu postura de seguridad ...