Nuevo cóctel de extorsiones: impresoras de oficina, rescates pequeños y BitLocker

Hace poco, nuestros equipos en América Latina investigaron una serie de incidentes relacionados con configuraciones incorrectas, la implementación de BitLocker y el empleo de impresoras corporativas. Los atacantes utilizaron estos dispositivos para notificar a las organizaciones que su infraestructura había sido comprometida y que debían pagar un rescate para recuperar sus datos.

Este artículo analiza dos incidentes: uno ocurrido en junio en Colombia y otro en mayo en México. En él se destacan las similitudes entre las comunicaciones de los atacantes en ambos casos, y se describen las tendencias emergentes en los montos de los rescates.

Primer indicio de un ataque

En ambos incidentes, lo primero que notaron los usuarios afectados fue un ícono de candado junto a sus unidades en el Explorador de Windows. Esto indicaba que la unidad estaba cifrada con BitLocker, bloqueando el acceso a su contenido.

Confirmación de que el disco está bloqueado

Se requería una clave de recuperación para desbloquear la unidad.

Intento de acceso al contenido del disco y solicitud de las claves de BitLocker

No es la primera vez que vemos este tipo de amenazas; hace algunos años, nuestro equipo descubrió una amenaza conocida como ShrinkLocker que utilizaba BitLocker para lograr sus objetivos.

Primer caso: abuso de RDP para cifrar datos

Uno de los incidentes ocurrió en Colombia durante junio. Los atacantes explotaron un servicio RDP expuesto a internet que se encontraba en un servidor conectado a un dispositivo de almacenamiento de 8 TB con datos críticos para las operaciones de la organización. Después de tomar control del sistema y manipular las credenciales de usuario, habilitaron BitLocker de forma exclusiva en la unidad donde se almacenaban los datos financieros. Una vez completado el cifrado, bloquearon la unidad y utilizaron las impresoras de la empresa para imprimir notas de rescate.

Nota de rescate del ransomware

Lamentablemente, no se pudo obtener evidencia del caso porque la empresa priorizó la restauración del sistema para tratar de recuperar el disco cifrado. Los atacantes exigían menos de USD 3000 y la empresa contempló la posibilidad de pagar el rescate. Después, el sistema fue restaurado antes de que se pudiera tomar ninguna medida, lo que eliminó la evidencia necesaria para evaluar el incidente.

Respuesta del atacante al correo que envió la víctima a la dirección incluida en la nota de rescate impresa

Este ataque fue posible debido a un servicio de escritorio remoto (RDP) expuesto a internet y a la presencia de puertos adicionales abiertos que los empleados utilizaban para acceder a la información corporativa. Aprovechando esta exposición de red y la configuración errónea, los atacantes comprometieron el sistema, identificaron una unidad adicional y utilizaron BitLocker para cifrar los datos y exigir el pago de un rescate. Dejar los puertos RDP abiertos sin los controles de seguridad adecuados pone en riesgo la seguridad de los sistemas y la información, tal como se destaca en el “Informe global: Anatomía de un mundo cibernético“.

Puertos expuestos identificados en el sistema durante los últimos meses

La empresa confirmó que, debido a problemas de compatibilidad con las aplicaciones necesarias para las operaciones, la protección EPP (Endpoint Protection Platform) estaba deshabilitada en el sistema, lo que facilitó que los atacantes validaran, enumeraran y ejecutaran aplicaciones sin que la actividad maliciosa fuera detectada por los sistemas de monitoreo central.

Segundo caso: presentamos al XEntry Team

En otro incidente ocurrido en México en mayo, nuestro equipo logró identificar cómo los actores de amenazas obtuvieron el acceso inicial a la infraestructura. Los atacantes explotaron un servicio MSSQL mal configurado, lo que les permitió ejecutar comandos en el sistema tras obtener las credenciales de acceso a la base de datos gracias a que el código publicado en GitHub no tenía las medidas de seguridad adecuadas.

Ataque del XEntry Team

En este incidente, el ataque comenzó tres meses antes de su detección, cuando el intruso descubrió y verificó su acceso al entorno. Una vez que confirmaron su acceso y nivel de privilegios dentro de la configuración del servidor MSSQL, el cual se extendía más allá del DBMS hasta el sistema operativo subyacente, los atacantes se enfocaron inicialmente en manipular la configuración del servidor web del mismo sistema. Así redujeron el nivel de seguridad y crearon archivos de web shell en carpetas públicas. Muchos de estos intentos de manipular el servicio o crear archivos maliciosos fueron contenidos por los controles de seguridad EPP existentes, pero, a pesar de las alertas generadas, no se realizaron las investigaciones necesarias para atender la actividad reportada.

Comandos ejecutados en el intento de manipular el servidor web

Luego, los atacantes verificaron que podían ejecutar comandos en el sistema local y montaron su infraestructura para filtrar datos mediante un puente de comunicaciones. Al explotar el servicio MSSQL, obtuvieron acceso a cada uno de los sistemas internos de la organización.

El motor de base de datos utilizado por la empresa era Microsoft SQL Server 2019.0150.2160.04, el cual estaba mal configurado, lo que permitía la ejecución de comandos del sistema operativo mediante el procedimiento almacenado extendido xp_cmdshell.

Debido a la configuración errónea de un servicio expuesto a internet, los atacantes establecieron un canal capaz de ejecutar cualquier tipo de comando dirigido al servidor y a la infraestructura local dentro de su alcance.

Ruta del ataque

Uno de los principales objetivos era identificar sistemas y recursos compartidos con acceso a información crítica. Nuestro análisis confirmó el acceso de los atacantes a sistemas que almacenaban parámetros de configuración de servicios de red, servicios de gestión empresarial y servicios en la nube, entre otros.

Un subconjunto de la información crítica identificada y recopilada por los actores de amenazas

A principios de mayo, los atacantes se enfocaron en realizar escaneos adicionales e implementar la solución ManageEngine’s Endpoint Central RMM (Monitoreo y gestión remota), con el fin de establecer persistencia y comenzar las etapas finales de su intrusión:

Escaneo e implementación de RMM

En los días siguientes, se instalaron aplicaciones adicionales de tipo RMM, como Mesh Agent y Tactical RMM. Estas aplicaciones se usaron para crear tareas programadas que habilitaban el servicio BitLocker y cifrar de forma individual los discos de la infraestructura, generando una clave para cada sistema cifrado:

Comandos para recopilar claves de BitLocker ejecutados desde herramientas RMM

Por último, a mediados de mayo, los atacantes lograron ejecutar un objeto de directiva de grupo (GPO) utilizado para implementar tareas de activación y cifrado, así como otras encargadas de continuar implementando aplicaciones RMM mediante tareas programadas. Al principio, la actividad se dirigió a sistemas críticos, pero después se extendió a todos los sistemas sincronizados con el controlador de dominio. El ataque se hizo evidente para los usuarios cuando sus equipos mostraron una pantalla azul con el mensaje “Hacked by XEntry Team” y sus credenciales dejaron de funcionar.

Unas horas después, comenzaron a imprimirse notas de rescate en las impresoras de la oficina:

Nota de rescate impresa por el XEntry Team

Estos casos confirman que los adversarios buscan obtener acceso a la infraestructura sin invertir en grupos de ransomware o asociarse con ellos. En cambio, aprovechan herramientas nativas de Microsoft para facilitar el cifrado de datos y el pago de los rescates. Para contrarrestar este tipo de intrusiones, resulta fundamental monitorear y centralizar los registros de los recursos protegidos, así como gestionar oportunamente las alertas.

Conclusiones

• Aunque los sistemas analizados tenían implementadas medidas de seguridad, se detectó una gestión inadecuada de las alertas, así como decisiones erróneas motivadas por incompatibilidades de aplicaciones.
• Es fundamental configurar el Protocolo de Escritorio Remoto (RDP) siguiendo las mejores prácticas de ciberseguridad para prevenir accesos no autorizados. Esto es crítico dado que, de acuerdo con nuestro Informe global: Anatomía de un mundo cibernético, más del 13 % de los incidentes está relacionado con violaciones de políticas y errores de configuración, lo que confirma que este tipo de configuraciones incorrectas sigue siendo un riesgo significativo.
• Las organizaciones deben priorizar la implementación de políticas estrictas de control de aplicaciones, así como el monitoreo activo del tráfico de red en busca de comunicaciones de comando y control (C2). Esto es de importancia crítica dado que, según el mismo informe, más del 20 % de los incidentes involucró el abuso de herramientas RMM (Remote Monitoring and Management) para la ejecución y estrategias de C2. El hecho de que los atacantes utilicen más de tres herramientas distintas para obtener el control en un solo incidente, refuerza la urgencia de implementar estas medidas.
• Algunas preguntas permanecen sin respuesta debido a la falta de evidencia y a la restauración precipitada de los sistemas, que omitió etapas críticas del proceso de respuesta a incidentes. Es importante garantizar un procedimiento adecuado de respuesta a incidentes, preservando la evidencia necesaria para confirmar todas las actividades relacionadas y ajustando o proponiendo controles que permitan prevenir futuros incidentes con TTP similares.
• Aunque las notas de rescate no revelan una conexión clara entre los actores, ciertas palabras utilizadas en las comunicaciones, así como el método de entrega y comunicación, podrían confirmar un vínculo entre ellos:

“Nuestra garantía: no hay reseñas negativas en línea sobre incumplimiento de nuestras obligaciones…” (Nota de rescate del primer caso)

“Nuestra reputación es la garantía de que todo lo acordado será cumplido…” (Nota de rescate del segundo caso)

Nuestros equipos continuarán monitoreando estas amenazas.

Firmas de detección

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a