El 2 de julio de 2021, mientras muchas personas en Estados Unidos se preparaban para el feriado del 4 de julio, comenzó a desarrollarse un importante ataque de ransomware.
El grupo de ransomware REvil llevó a cabo un sofisticado ataque a la cadena de suministro contra el producto VSA de Kaseya. Se cree que el ataque afectó entre 50 y 60 MSP, y entre 1.500 y 2.000 de sus clientes.
Este ataque fue un claro ejemplo de cómo las tácticas de los atacantes se vuelven cada vez más sofisticadas. Los objetivos —revendedores de TI y MSP— actúan como una puerta de entrada a decenas, cientos o incluso miles de SMB. Lamentablemente, este fue uno de los ataques de ransomware más complejos y exitosos que se recuerdan. Basta con ver los titulares de noticias que surgieron para notar lo innovador y sofisticado que fue este ataque.
Ahora que hay disponible una clave de descifrado y parece que vamos en la bajada de la montaña rusa, tenemos la oportunidad de mirar atrás y capturar algunas lecciones y aprendizajes importantes que pueden ayudar a esta industria a combatir estas amenazas con mayor eficacia.
Qué pasó
El equipo de Huntress tomó conocimiento del incidente después de que tres socios MSP distintos se contactaran con nosotros para contarnos que ellos —junto con sus clientes— habían sido afectados por ransomware. Estos reportes nos llegaron con media hora de diferencia entre sí, lo que de inmediato nos hizo pensar si esto era parte de un ataque más grande. A medida que seguía creciendo el número de víctimas comprometidas, quedó claro que lo único en común entre ellas era el uso de Kaseya VSA on-premises.
Apenas tuvimos suficiente información, comenzamos a brindar actualizaciones en tiempo real en nuestro blog de respuesta rápida, así como en nuestra publicación en Reddit. Ahora queremos profundizar un poco más en el incidente para aprender todo lo posible y estar mejor preparados para el próximo evento.
La perspectiva de los atacantes
Este ataque representó una oportunidad excepcional desde la perspectiva de los atacantes. ¿Para qué apuntar a una sola empresa cuando podían apuntar directamente a un MSP y conseguir decenas —o incluso decenas o cientos— de empresas de una sola vez?
REvil llevó a cabo un novedoso ataque a la cadena de suministro por el efecto dominó que tendría. El impacto se extendió desde el servidor VSA comprometido hacia todas las máquinas de los MSP afectados. Luego, impactó a todos los endpoints de las SMB más abajo en la cadena. De un solo golpe, los atacantes alcanzaron a la nave nodriza y afectaron a todo el sector.
Pasar inadvertidos
Hubo tres componentes principales en la cadena de ataque de los actores de amenazas:
1) Bypass de autenticación
2) Carga arbitraria de archivos
3) Ejecución de código
La interfaz para acceder al servidor Kaseya VSA está abierta públicamente en internet, por lo que los hackers pudieron encontrar y acceder a esos objetivos con facilidad. Sin embargo, cómo realizaron el bypass de autenticación inicial es algo que nuestros investigadores de seguridad todavía se preguntan.
Próximos pasos
Una vez que los atacantes tuvieron una sesión autenticada, subieron dos archivos: agent.crt y Screenshot.jpg. Hemos aprendido que `agent.crt` es el payload central que activa el ransomware, mientras que `Screenshot.jpg` prepara el terreno eliminando registros de IIS y cuentas administrativas, y configurando procedimientos en una base de datos para distribuir el ransomware a todos los endpoints con el agente en un momento coordinado.
Este ataque representó un gran problema, en gran parte porque el bypass de autenticación podía eludir por completo la autenticación multifactor y obtener acceso a la base de datos general para controlar todas las máquinas de los clientes. Esto comprometió el software de monitoreo y administración remota (RMM) que usaba una cantidad significativa de clientes de Kaseya. Hemos escuchado decir antes que un RMM comprometido es el peor escenario posible para los MSP. Esto fue otra pesadilla.
Las víctimas
Como se mencionó antes, las víctimas incluyeron entre 50 y 60 MSP y sus clientes; sin embargo, el impacto de este ataque se extiende mucho más allá de quienes fueron afectados directamente. Este incidente ha sido una experiencia reveladora para todas las empresas, incluso las que no usan el software VSA. Quedan preguntándose: “¿Podría mi propio stack de seguridad verse comprometido así? ¿Y el proveedor 'ABC'? ¿Podría ser el próximo?”
Aunque las víctimas que vivieron el cifrado de primera mano sintieron el mayor peso de este ataque, la comunidad en general ha sentido fuertes efectos dominó.
La importancia de este ataque
Lo decimos todo el tiempo: los actores de amenazas se vuelven más astutos cada día. A medida que los ataques se vuelven más sofisticados, defenderse de ellos se vuelve más difícil.
La realidad es que el ataque contra Kaseya pudo haberle pasado a cualquier proveedor. Si acaso, este ataque debería servir como una llamada de atención para las organizaciones. Sin importar cuánto o qué tan rápido crezca una empresa, es fundamental que los líderes empresariales sigan enfocados en proteger su núcleo y fortalecer su código, políticas y procedimientos. La educación y la capacitación en ciberseguridad son indispensables. Una mala brecha puede hacer que una empresa se derrumbe.
Qué funcionó bien, y qué podría haber salido mejor
Fue increíble presenciar cómo toda la comunidad de MSP se unió durante esta crisis. Lo vimos de primera mano en nuestra publicación de Reddit, cuando miembros de la comunidad MSP se contactaron para echar una mano:
Si hay un lado positivo en este incidente, es lo increíble que es la comunidad MSP y cómo nos unimos para apoyarnos y colaborar entre nosotros. 💙
Sin embargo, sin duda hubo espacio para mejorar. Si consideramos la vulnerabilidad del VSA por sí sola, la base de código del software, el proceso de notificación y el cronograma de las soluciones y la recuperación, deja algo que desear. Debemos exigirles a nuestros proveedores calidad de código y comunicación transparente.
La clave de descifrado
El 22 de julio se conoció la noticia esperada: había surgido una clave de descifrado universal.
La recepción pública de la noticia pareció ser mixta. Algunos dijeron que la llegada de la clave fue demasiado poco y demasiado tarde, ya que habían pagado el rescate por su cuenta o habían trabajado para recuperar sus datos manualmente. Otros que no habían avanzado mucho en recuperar sus datos podrían beneficiarse de la clave de descifrado para volver a estar en funcionamiento.
Eso nos lleva a la siguiente pregunta que tiene a muchos pensando: ¿cómo consiguieron la clave de descifrado?
Muchos se preguntaron si Kaseya habría pagado el rescate; otros plantearon que el gobierno intervino. Kaseya señaló que no pagaron el rescate por la herramienta de descifrado, pero no han dicho de dónde salió la clave. Dicho esto, varios detalles sobre este evento siguen sin revelarse por ahora.
La participación del equipo de Huntress
Nuestro equipo tuvo un papel activo en este incidente. Hicimos lo posible por investigar y analizar exactamente cómo se llevó a cabo este ataque, mientras intentábamos ayudar a las empresas afectadas.
Cerca de dos horas después de que comenzaran los incidentes de ransomware, nuestros equipos del SOC y de Ingeniería lograron revisar un payload que les permitió obtener algunos fragmentos, los suficientes para desarrollar una vacuna que podría ayudar en los sistemas a los que teníamos acceso (los de nuestros socios).
Sin embargo, había algunas preocupaciones sobre administrar la vacuna:
- Si REvil se enteraba, podrían haber cambiado fácilmente el nombre del archivo o directorio para que el ransomware se ejecutara como estaba previsto.
- El directorio kworking era configurable, así que si tenía otro nombre, la vacuna no funcionaría.
- El agent.exe de Huntress podría haberse confundido con el agent.exe de REvil.
En ese momento, tuvimos que hacernos una pregunta difícil: ¿los beneficios potenciales de la vacuna superaban los riesgos? Al final, para nosotros sí.
A menudo decimos que “nuestra ofensiva es tu defensa”, pero este fue un momento en que nuestras acciones hablaron más fuerte que esas palabras. Así que lanzamos la vacuna. Tomamos una página del manual de los hackers para proteger a nuestros socios, y por suerte, tenemos socios que confían en que tomaremos las decisiones correctas para mantenerlos a salvo a ellos y a sus clientes. 😁
Lecciones aprendidas
Al reflexionar sobre cómo se desarrolló este incidente, identificamos algunas lecciones que vale la pena aprender y algunos consejos para seguir adelante.
- Evalúa tu stack de seguridad con regularidad.
Lo que funciona hoy para tu organización podría no ser suficiente contra los ataques de mañana. Deberías evaluar con regularidad las herramientas de tu stack de seguridad para asegurarte de estar bien preparado frente a los atacantes del futuro.
- Trabaja con tus proveedores para configurar bien tus herramientas.
No existe una solución lista para usar que funcione para todas las empresas. Trabaja con cada proveedor con el que colabores para asegurarte de que tus herramientas estén configuradas de la manera que funcione para tu negocio. Además, asegúrate de que tus proveedores se mantengan al día con las mejores prácticas y las últimas alertas de seguridad.
- Revisa tu plan de respuesta a incidentes.
Pongámoslo así: en Florida, ocurren huracanes. A los habitantes de Florida no se los mide por si pueden evitar que ocurra un huracán; ¡eso sería absurdo!
En cambio, se los mide por qué tan rápido pueden recuperarse. Mantienen suministros de emergencia a la mano y tienen un plan para sobrevivir la temporada de huracanes.
Los ciberataques son tan inevitables como los huracanes. No existe, ni existirá, una forma infalible de prevenir un ciberataque. En cambio, los profesionales de ciberseguridad deberían enfocar sus esfuerzos en estar preparados para cuando lo peor sí ocurra. Ahí es donde entra un plan de respuesta a incidentes.
Un plan de respuesta a incidentes no solo te da tranquilidad sobre cómo actuar ante esos peores escenarios, también puede ayudarte a responder rápido y avanzar más rápido en el camino hacia la recuperación. Si quieres poner a prueba tu plan actual, consulta nuestro Incident Response Tabletop-in-a-Box.
Si necesitas ayuda, incluso si no eres socio actual de Huntress, escríbenos a [email protected].
