En los últimos meses, equipos de seguridad en Latinoamérica investigaron incidentes que comparten un patrón preocupante: extorsión con BitLocker, cifrado de discos y presión al negocio mediante notas de rescate impresas. En lugar de depender de un “grupo de ransomware” tradicional, los atacantes parecen construir el ataque usando herramientas disponibles dentro del ecosistema corporativo y combinándolas con accesos que obtienen por fallos de configuración.
Este artículo resume dos casos (uno en Colombia y otro en México) y extrae tendencias que deberían importar a cualquier organización: desde señales iniciales en Windows hasta el abuso de servicios expuestos y la falta de una respuesta a alertas que permita contener a tiempo la intrusión.
La señal inicial: el candado y la necesidad de una clave
En ambos incidentes, las víctimas notaron primero un cambio visible en su entorno Windows. En el Explorador de archivos, aparecía un ícono de candado junto a las unidades afectadas, un indicio de que el disco estaba cifrado con BitLocker.
Ese cifrado bloqueaba el acceso a la información hasta contar con una clave de recuperación. Para el usuario final, la situación se percibe como un incidente repentino; para el atacante, es el objetivo final tras asegurar el control del sistema y escalar hacia más equipos y discos.
Primer caso (Colombia): RDP expuesto y cifrado de un almacenamiento clave
El incidente de Colombia ocurrió en junio e ilustra una ruta de ataque clásica: aprovechar un servicio de RDP accesible desde Internet. El actor comprometió una máquina conectada a un dispositivo de almacenamiento de alrededor de 8 TB con datos críticos para la operación.
Tras tomar control del sistema y manipular credenciales de usuarios, el atacante habilitó BitLocker de forma dirigida. En lugar de cifrar todo de inmediato, seleccionó principalmente el volumen donde residía información financiera relevante.
Una vez completado el cifrado, el disco quedó bloqueado y se utilizó la infraestructura de la empresa para emitir el mensaje de rescate. Según el análisis, el atacante imprimió notas a través de las impresoras corporativas.
En cuanto al monto solicitado, la demanda fue de 3.000 dólares. Sin embargo, la respuesta de la organización se vio acelerada por la urgencia de recuperar la unidad. Eso impidió reunir evidencia para un análisis forense profundo, dejando la investigación en un punto donde no fue posible confirmar con total precisión etapas previas o detalles del alcance.
Por qué RDP mal configurado agrava el riesgo
El caso no solo se explica por “acceso externo”. El problema central es que el servicio de RDP estaba expuesto y además existían puertos adicionales abiertos utilizados por empleados para acceder a información corporativa. Ese escenario, sumado a configuraciones débiles, habilita que un atacante entre, identifique recursos adicionales y luego ejecute el flujo de cifrado con BitLocker.
Además, se reportó que, debido a compatibilidades con aplicaciones necesarias para operar, la protección de EPP (plataforma de protección de endpoints) estaba deshabilitada en el sistema afectado. Al reducir controles, el atacante puede verificar, enumerar y ejecutar componentes sin que la actividad maliciosa se refleje de manera adecuada en sistemas de monitoreo centralizados.
Segundo caso (México): MSSQL mal configurado y despliegue de persistencia
El incidente de México ocurrió en mayo y es especialmente instructivo porque muestra una cadena de acceso inicial apoyada en MSSQL mal configurado. El atacante explotó un servicio MSSQL con configuración deficiente, lo que permitió ejecutar comandos en el sistema luego de obtener credenciales desde código publicado de forma insegura en GitHub.
Lo relevante es el tiempo: el acceso inicial ocurrió tres meses antes de que la actividad fuese detectada. Tras verificar su acceso y el nivel de privilegios dentro del entorno MSSQL, el atacante extendió el impacto más allá del motor de base de datos y llegó al sistema operativo.
De la configuración web a shells: bajar defensas y crear puertas traseras
En una primera fase, el actor intentó modificar aspectos de la configuración del servidor web en el mismo sistema. Además, redujo configuraciones de seguridad y creó archivos tipo web shell en carpetas accesibles públicamente.
Algunas acciones fueron frenadas por controles EPP existentes y se generaron alertas. No obstante, pese a las señales, no se realizó la investigación necesaria para atender la actividad. En retrospectiva, ese punto resulta crucial: una alerta sin seguimiento suele convertirse en “permiso” para que el atacante continúe.
El canal de ejecución: xp_cmdshell y un servicio expuesto
Después, el atacante confirmó que podía ejecutar comandos localmente y montó infraestructura para transferir datos usando un “puente” de comunicaciones. El análisis indicó que el motor de base de datos utilizado era Microsoft SQL Server 2019 con una configuración que permitía ejecución de comandos del sistema operativo mediante la extensión xp_cmdshell.
En términos prácticos, esa combinación le dio al actor un canal para ordenar comandos sobre el servidor y, dentro de su alcance, sobre la infraestructura local. Este tipo de falla convierte un punto “de datos” en un punto “de control”.
Despliegue de RMM y cifrado progresivo con BitLocker
Entre las prioridades del atacante estuvo identificar sistemas y recursos compartidos que entregaran acceso a información crítica. El análisis confirmó su interés en componentes de configuración para redes, gestión empresarial y servicios en la nube.
Durante los primeros días de mayo, el actor incrementó escaneos y desplegó herramientas de RMM (Remote Monitoring and Management), específicamente Endpoint Central de ManageEngine, con el fin de establecer persistencia y entrar a las fases finales de la intrusión.
Luego instalaron aplicaciones adicionales de tipo RMM, como Mesh Agent y Tactical RMM. Estas herramientas se usaron para crear tareas programadas que habilitaron el servicio BitLocker e iniciaron el cifrado de discos de forma individual, generando una clave por cada sistema cifrado.
La activación a través de políticas de dominio y el efecto visible en usuarios
En la mitad de mayo, el atacante logró ejecutar un Group Policy Object (GPO) para impulsar tareas de activación y cifrado. Además, configuró políticas para mantener el despliegue de aplicaciones RMM mediante tareas programadas.
El impacto comenzó en sistemas críticos y más tarde se extendió a todos los equipos sincronizados con el controlador de dominio. Como resultado, los usuarios se dieron cuenta del ataque cuando sus máquinas mostraron una pantalla azul con el mensaje “Hacked by XEntry Team”. Poco después, sus credenciales dejaron de funcionar para acceder a los sistemas.
Horas más tarde, aparecieron notas de rescate impresas desde las impresoras de oficina, reforzando el componente de presión física y rápida del esquema.
Qué revelan ambos casos sobre la “extorsión con BitLocker”
Estos incidentes confirman un objetivo claro: lograr acceso a la infraestructura y evitar pagar o depender de actores externos asociados con ransomware “clásico”. En vez de ello, los atacantes aprovechan herramientas integradas del entorno Microsoft y capacidades administrativas para cifrar datos y pedir rescate.
En consecuencia, la defensa no puede enfocarse solo en “tener antivirus”. También requiere disciplina en tres áreas: monitoreo centralizado de logs, atención oportuna a alertas y control riguroso de configuraciones.
Lecciones prácticas para prevención y respuesta
1) Asegura RDP siguiendo buenas prácticas
Para reducir la exposición, es clave configurar RDP con controles estrictos. La investigación subraya que las configuraciones incorrectas y violaciones de políticas siguen siendo una fuente importante de incidentes. Si RDP no está diseñado para acceso público, la exposición debe considerarse una vulnerabilidad.
2) Endurece el control de aplicaciones y el monitoreo de red
Dado que se abusaron herramientas y rutas para ejecución, conviene reforzar políticas de control de aplicaciones y el monitoreo de tráfico de red asociado a comunicaciones de comando y control (C2). Además, el hecho de que el atacante haya empleado más de tres herramientas distintas dentro del mismo incidente hace todavía más importante la correlación de eventos.
3) Trata las alertas como incidentes, no como ruido
En el caso de México, se registraron alertas vinculadas a intentos de manipulación y creación de archivos maliciosos, pero el seguimiento no se realizó. La recomendación es clara: si existe evidencia o indicios, hay que investigar hasta cerrar la causa raíz, no solo desactivar síntomas.
4) Diseña la respuesta a incidentes preservando evidencia
Ambos relatos mencionan, de maneras distintas, limitaciones del proceso de respuesta. En el caso colombiano, la recuperación acelerada del disco impidió recolectar evidencia para evaluar etapas previas. Para una respuesta efectiva, se debe planificar cómo preservar evidencia y cuándo proceder con restauraciones sin perder la capacidad de análisis.
Señales de detección mencionadas por el análisis
El informe incluye algunas firmas y clasificaciones asociadas a actividad maliciosa, entre ellas: Trojan.Multi.Agent.gen, Trojan.Win32.GenAutorunMsSqlServerCommandRun.a, Trojan.Win32.Generic y Exploit.Win32.SCShell.a. Más allá de nombres específicos, lo importante es traducir esto en reglas de monitoreo y búsqueda en sistemas propios.
Conclusión: el factor clave es la disciplina operativa
La extorsión con BitLocker en estos incidentes no se explica por una sola debilidad técnica. Es el resultado de una cadena: exposición de servicios (como RDP), configuraciones peligrosas (como en MSSQL con ejecución de comandos), persistencia mediante herramientas de gestión remota y una fase final de cifrado a gran escala.
La buena noticia es que hay decisiones que disminuyen el impacto: respaldos confiables, control estricto de accesos, endurecimiento de servicios y, sobre todo, una práctica constante de monitoreo y respuesta. Si un ataque logra entrar, la organización necesita poder recuperar datos y cortar la intrusión con rapidez, sin depender de negociar acceso a la propia información.
En última instancia, la defensa más poderosa y simple sigue siendo tener copias de seguridad verificadas. Ni el mejor software evita el 100% de fallos, pero una restauración desde un respaldo puede reducir la extorsión a un problema manejable, en lugar de una crisis.
Fuente: https://securelist.com/new-extortion-scheme-printers-bitlocker/120718/
