ACTUALIZACIÓN: 2022-01-28: modificamos algunas líneas en la historia para aclarar cómo configuraciones de ZTNA podrían haber permitido al operador de red ejercer un mayor control sobre sus dispositivos.
Un ataque a un proveedor de tecnología en diciembre de 2021, utilizando el ransomware conocido como Midas, se apalancó en al menos dos herramientas comerciales de acceso remoto diferentes y una utilidad de Windows de código abierto en el proceso.
Después de llamar al equipo de Rapid Response de Sophos para ayudar con el análisis, se descubrió evidencia de que los atacantes habían estado activos en la red durante al menos dos meses antes de la aparición del ransomware en un controlador de dominio y en otras computadoras en la red.
El objetivo usa Citrix para virtualizar todos los escritorios de los empleados, pero la topología de la red de la organización era plana, con acceso a toda la red a través de su VPN. Los servidores de Windows, ejecutados como hipervisores de máquinas virtuales, comprendían la mayoría de los dispositivos físicos del objetivo. Las redes planas sin segmentación son un factor de riesgo en los ataques de ransomware; Si hubiera existido una configuración de acceso a la red de confianza cero (ZTNA), podría haber ayudado a limitar la capacidad de los atacantes para moverse lateralmente y conectarse a los recursos una vez entraron a la red.
El ataque involucró iteraciones repetidas de los actores criminales que crearon servicios de Windows diseñados para ejecutar, en una máquina a la vez, varios scripts de PowerShell que habían ubicado en algunos de los otros servidores comprometidos, cualquier otra máquina (Virtual o servidor) podía alcanzar estos activos comprometidos a través de SMB. Usando ZTNA, los controles de acceso correctamente configurados podrían haber evitado que los atacantes pudieran aprovechar un servidor comprometido contra otro, impidiendo afectar otros recursos.
La empresa objetivo, que estaba usando una solución de seguridad de Endpoint de otro fabricante para proteger sus servidores, nunca vio una alerta de que los atacantes habían ingresado a la red. Ejecutaron comandos, iniciaron conexiones RDP internas, aprovecharon el software comercial de acceso remoto ya instalado, exfiltraron datos a la nube y movieron archivos hacia y desde uno de los controladores de dominio del objetivo durante un período de dos meses, que culminó con la implementación del ransomware a principios de diciembre de 2021.
Debido a la falta de datos de registro, se desconoce cómo los atacantes accedieron inicialmente al controlador de dominio, o cómo se comprometió la cuenta de administrador y tomaron el control de esa máquina. Pero una vez que lo hicieron, los atacantes aprovecharon los permisos de esa cuenta, y la apertura de la topología de la red, para propagar puertas traseras y, más tarde, el ransomware a las máquinas en toda la red.
El manual de juego
Si bien Midas no es una amenaza tan común como algunas de las otras familias de ransomware que encontramos con más frecuencia, los atacantes parecían seguir un playbook familiar durante todo el incidente. Aprovecharon las herramientas y los procesos de administración de Windows convencionales (como PowerShell y la herramienta de Administración y mantenimiento de imágenes de implementación) y programas comerciales de acceso remoto (como AnyDesk y TeamViewer) que tienen menor probabilidad de activar una alerta antimalware para moverse lateralmente y extraer archivos de la red de la empresa.
En este incidente, el personal de TI del objetivo había probado previamente AnyDesk y TeamViewer, así como varias otras herramientas de acceso remoto, y ya no las usaba. Desafortunadamente, todavía estaban instaladas en algunos de los servidores que los atacantes usaron su beneficio.
En algunos casos, los atacantes desplegaron la herramienta de código abierto Process Hacker para identificar y detener los productos de seguridad de Endpoint que el objetivo estaba usando para proteger sus sistemas.
Nota de extorsión de Midas
El primer indicador de compromiso tuvo lugar el 13 de octubre, cuando los registros en uno de los controladores de dominio comprometidos indican que se realizó una conexión de escritorio remoto (RDP) entre máquinas de la red interna de la organización objetivo y el controlador de dominio. La conexión RDP fue un inicio de sesión exitoso por parte de la cuenta de administrador, desde dos máquinas diferentes. Se desconoce cómo, antes de este punto, los atacantes obtuvieron acceso a las dos máquinas internas que usaron para conectarse por RDP al controlador de dominio.
La primera fase del ataque tuvo lugar entre el 13 de octubre y el 2 de noviembre, después de lo cual no hubo actividad hasta tres semanas después, el 22 de noviembre. Si bien es inusual en incidentes recientes de ransomware ver esa cantidad de tiempo de permanencia de los atacantes en las redes, aún sucede.
El uso de Process Hacker por parte de los atacantes solo tuvo éxito parcial, ya que algunas de las máquinas comenzaron a detectar y bloquear el uso de la herramienta de recopilación de credenciales Mimikatz en uno de los servidores de la empresa el Día de Acción de Gracias, el 25 de noviembre. Sin embargo, la investigación descubrió que los atacantes parecen haber tenido éxito al ejecutar Mimikatz en un servidor diferente un día antes. Un análisis forense del servidor comprometido reveló un archivo llamado Passwords.txt que contenía algunas de las credenciales recolectadas.
Orquestación a través de PowerShell
Los atacantes se apoyaron en gran medida en scripts personalizados de PowerShell, en algunos casos instalándolos como servicios de Windows para ejecutarlos. También orquestaron partes del ataque utilizando Visual Basic Script y archivos por lotes, ejecutados con la utilidad DISM.exe que, en circunstancias normales, se utiliza para reparar instalaciones de Windows que se han corrompido.
Durante la primera semana que los atacantes estuvieron conectados a la red, claramente ya habían obtenido acceso a varias máquinas internas dentro de la organización objetivo. Cargaron varios scripts de PowerShell en el directorio TEMP de algunas de las máquinas que controlaban, luego crearon servicios de Windows en otras máquinas a las que podían acceder que llamarían a esos scripts desde la red y ejecutarían los scripts alojados en esas otras máquinas.
Si bien muchas de las secuencias de comandos de PowerShell usaban nombres de archivo aleatorios, algunos de los nombres de archivo dieron pistas sobre su propósito, como “dism_els.ps1”, que los atacantes ejecutaron en el servidor donde luego se usó la herramienta DISM para instalar una puerta trasera. Veinte minutos después, se ejecutó el mismo comando en un segundo servidor. Es posible que se haya utilizado otro script, “adtest.ps1”, para verificar si tenían privilegios de administrador de dominio en el servidor.
Los atacantes utilizaron combinaciones extrañamente complejas de secuencias de comandos para realizar una sola tarea. Por ejemplo, una secuencia de comandos de PowerShell ejecutaba un archivo por lotes, que a su vez iniciaba una secuencia de comandos de PowerShell, que ejecutaba un comando para invocar una herramienta de carga lateral de DLL para inyectar un proceso del sistema con la carga maliciosa DismCore.dll. Vimos varias instancias de Visual Basic Script iniciar PowerShell, que luego lanzó un script por lotes que invocó DISM para cargar DismCore.dll. Los archivos involucrados tenían nombres de cuatro, ocho o doce caracteres alfanuméricos aleatorios de longitud. Algunos de los scripts de PowerShell usaban el sufijo de archivo .log en lugar del predeterminado .ps1. Algunos no usaban ningún sufijo de archivo.
Los atacantes fueron metódicos, iterando a través del mismo proceso repetidamente en diferentes máquinas entre el 13 y el 19 de octubre, habilitando puertas traseras en varios servidores de la red del objetivo. Pero luego, repentinamente dejaron de tomar acciones y de conectarse el día 19, reanudando actividades el 2 de noviembre.
El 2 de noviembre, los atacantes iniciaron sesión e iteraron a través del proceso de creación de servicios/ejecución de PowerShell en dos máquinas de escritorio más, con la diferencia de que los atacantes habían usado AnyDesk 13 veces por separado en uno de los servidores que encontramos se había visto comprometido durante las primeras fase del ataque. Después de observar este comportamiento, no hubo más actividad durante tres semanas más.
Sin acción de gracias
Después de una pausa en la actividad, los atacantes reanudaron su trabajo el 22 de noviembre, instalando servicios y usándolos para ejecutar scripts de PowerShell que se corrieron en otras máquinas internas que se habían visto comprometidas anteriormente.
Los atacantes solo ejecutaron un único script de PowerShell el día 22, luego, un día después, instalaron más servicios en otras tres máquinas y usaron esos servicios para ejecutar scripts de PowerShell.
El 25 de noviembre, los logs indicaron que uno de los controladores de dominio comprometidos escribió un archivo llamado Passwords.txt en la ruta C:\Compaq\!logs\ en su almacenamiento local, pero no fue hasta después de la medianoche que el el software antivirus detectó Mimikatz ejecutándose en un servidor diferente. Se realizaron varias otras conexiones RDP internas entre el 25 y el 29, y luego el rastro se enfrió cuando los atacantes se escondieron.
La fase final
Más de una semana después, a altas horas de la noche del 7 de diciembre, los atacantes comenzaron a desplegar el binario del ransomware en las máquinas del objetivo. El archivo se ubicó en la ruta C:\hp\ y su nombre incluía el nombre de la organización atacada. El mismo directorio fue donde también se guardó una copia de Process Hacker.
Luego, los atacantes ejecutaron Process Hacker bajo un servicio que crearon llamado KProcessHacker3, y presumiblemente lo usaron para detener el software de antivirus que había frustrado la ejecución de Mimikatz varias semanas antes.
También recuperamos las secuencias de comandos de PowerShell que los atacantes usaron en un intento de detener 46 procesos y 216 servicios. Estos incluían servicios como MSSQL, varias herramientas de copia de seguridad, aplicaciones de office y servicios vinculados a los software de seguridad de McAfee, Kaspersky, Trend Micro y Sophos, entre otros. El script que detenía los servicios y procesos tenía varias listas redundantes, lo que indica que los atacantes estaban agregando entradas a mano y no buscando duplicados.
Unos minutos más tarde, los atacantes movieron copias de dos binarios de ransomware, llamados <target>local.exe y <target>share.exe (con el nombre de la organización) a un servidor interno y lo ejecutaron.
Luego repitieron este mismo proceso en varios otros servidores de la red: instalar un servicio de Windows para ejecutar Process Hacker, luego, unos minutos más tarde, copiar y ejecutar los dos binarios de ransomware. Los atacantes se tomaron su tiempo, solo lo hicieron una vez por hora durante las siguientes horas.
Más tarde ese día, 8 de diciembre, el objetivo se comunicó con el equipo de Rapid Response de Sophos después de que descubrieron notas de rescate (y cuando los servidores no estaban haciendo lo que se suponía que debían hacer).
Afortunadamente para el objetivo, el daño se limitó solo a una pequeña cantidad de servidores. Con la contratación de Rapid Response, los analistas instalaron las herramientas de Endpoint de Sophos en las máquinas de toda la organización, que detectaron y bloquearon el uso de DISM y Process Hacker por parte de los atacantes, y el intento de instalación de ejecutables de ransomware adicionales en otras máquinas de la red.
La huida
Los atacantes involucrados en este ataque del ransomware Midas, se apalancaron en gran medida en el proceso de instalar nuevos servicios de Windows que se usaron para ejecutar scripts de PowerShell. Estos servicios tenían nombres bastante obvios para el ojo humano que no eran solo revoltijos aleatorios de letras y números, pero la victima no monitoreaba las computadoras de su red en búsqueda de creación de nuevos servicios, o de movimiento lateral de cualquier tipo entre los servidores. .
Los atacantes también se apalancaron tanto en RDP como en herramientas de acceso remoto de terceros que la empresa normalmente no usaba en el curso de su negocio. Contamos al menos 14 herramientas diferentes de acceso remoto comerciales o de código abierto que se habían instalado previamente y se habían dejado en las máquinas comprometidas. No hace falta decir que esto proporcionó una gran oportunidad para su mal uso. Uno de estas herramientas pudo haber sido la fuente de acceso inicial de los atacantes a una computadora interna. El consejo fundamental es este: si instala herramientas de control remoto y no las está usando activamente, la acción correcta es desinstalarlas completamente de la máquina.
El monitoreo de actividades inusuales por parte de programas no maliciosos o herramientas de administración de Windows debería ser obligatorio para los equipos de ciber-seguridad, ya que es muy difícil para un producto de protección de Endpoint reconocer la diferencia entre el uso benigno o malicioso de una herramienta legítima. Una lista de aplicaciones permitidas puede restringir aún más la capacidad de un actor criminal para usar sus habilidades y herramientas preferidas.
El siguiente consejo básico que hemos dado durante años también se aplica para este caso: los atacantes lo habrían tenido mucho más difícil si el objetivo hubiera utilizado autenticación multifactor en sus servicios y máquinas internas, y una red segmentada en zonas discretas con acceso limitado entre ellas. Estas acciones pueden parecer abrumadoras, especialmente para pequeñas y medianas empresas, peero el esfuerzo y la planificación valdrán la pena si se rompe el corazón de un hacker al arruinar su ataque.
Detecciones y orientación
Sophos detecta el uso malicioso de DISM como un exploit de DynamicShellcode, sin activar un falso positivo en el archivo benigno. La utilidad Process Hacker se detecta como una aplicación potencialmente no deseada (PUA) y los archivos binarios del ransomware Midas se detectan como Troj/Ransom-GLY. Otros componentes del ataque pueden detectarse como Troj/PSInj-BI (secuencias de comandos de PowerShell), Troj/MSIL-SDB (el dismcore.dll malicioso), Harmony Loader (PUA) o ATK/sRDI-A (la herramienta de carga lateral sRDI DLL ).
SophosLabs ha publicado una lista parcial de indicadores de compromiso relacionados con este ataque en SophosLabs Github, y eliminó ciertos detalles de este informe y capturas de pantalla para proteger la identidad de la organización atacada.
SophosLabs agradece la ayuda de Jason Jenkins del equipo de Rapid Response por su trabajo en el análisis del ataque.
Leave a Reply