Este es una de las newsletters antiguas que se enviaron de forma exclusiva a los miembros del Club Negocios Seguros, y que se liberan públicamente un mes más tarde.
Si quieres recibir las actuales cada martes y jueves en tu bandeja de correo, hazte miembro ahora.
*******
Negocios Seguros
De vez en cuando me gusta traer por aquí casos de éxito en políticas de seguridad.
Este es el caso de CloudFlare, una empresa que ya sabéis que me encanta, por eso de ofrecer una serie de servicios que son a día de hoy críticos para suministrar acceso a Internet a lo largo y ancho del mundo.
El ser tan buenos en lo suyo supone, por tanto, que también sean objetivos principales, y de ahí que cada cierto tiempo tenemos que hablar de algún DDoS masivo con el que les toca lidiar.
Sin embargo, esta vez estamos ante un ataque dirigido a sus trabajadores.
Como contaban recientemente en su blog (EN):
El 20 de julio más de 70 empleados recibieron un SMS en sus teléfonos (tanto personales como de trabajo) que apuntaba a una supuesta página de inicio de sesión de Okta de Cloudflare. Los empleados sospecharon, pero no tenían ni idea cómo los criminales obtuvieron sus números de teléfono. La mayoría ignoró el mensaje, que afirmaba que «su programación de Cloudflare se había actualizado» y pedía hacer clic en un enlace. El objetivo era robar el login y la contraseña de Cloudflare, y tres de los más de 70 cayeron en la trampa.
Sin embargo, gracias a la seguridad de acceso con clave de hardware, los criminales no consiguieron hacer nada con esa contraseña.
Pero el tema no acababa ahí.
Tuvieron un segundo ataque diseñado para que los empleados descarguen software de acceso remoto en sus ordenadores, lo que permitiría al atacante controlar la computadora de forma remota. En este caso ninguno cayó en la trampa, de forma que nadie instaló el software no autorizado.
Una vez identificado el ataque, Cloudflare bloqueó el dominio de origen del phishing, se restablecieron las contraseñas de los empleados y se cerraron las sesiones activas, por si acaso.
El dominio usado en el ataque se configuró menos de una hora antes de que comenzara la campaña, de forma que no estaba en ninguna lista negra, por lo que es importante estar atentos a enlaces de cualquier dominio desconocido, y usar herramientas que informan sobre la autoridad de un dominio en caso de alguna duda.
De todo el ataque me parece interesante señalar varios puntos:
- El 2FA fue crítico: En la primera campaña hubo tres trabajadores que cayeron. Pero como había un 2FA activo mediante hardware, no sirvió para nada.
- Una buena concienciación en materia de seguridad de la información para el equipo: El segundo ataque fracasó porque ninguno de los trabajadores cayó en la trampa, lo que deja claro que como mínimo una formación básica en riesgos digitales tienen.
- Las listas negras y blancas no sirven: Como explican al final, el dominio usado para la campaña se creó apenas una hora antes de comenzar el ataque. Esto hace que sea virtualmente imposible que esté fichado, y por tanto, que haga saltar las alarmas de cualquier IDS y antivirus que haya en la organización. La única defensa contra este tipo de ataques es el sentido común de los trabajadores, y si me apuras, sistemas heurísticos super avanzados, que lo van a tener cada vez más jodido para defenderse de algo así.
En fin, que un ejemplo de guion de cómo una buena política de acceso a los recursos informacionales y una buena formación del equipo evitan incluso ataques dirigidos. Que son, en esencia, los más complicados de gestionar.
________
Si quieres recibir contenido exclusivo como éste el día uno y directamente en tu bandeja de correo cada martes y jueves, hazte miembro del Club «NEGOCIOS SEGUROS».
