Resumen
El 02 de febrero de 2023, se activó una alerta en un entorno protegido por Huntress. A primera vista, la alerta en sí era bastante genérica: una combinación de certutil usando la bandera urlcache para obtener un recurso remoto, seguida de la creación de una tarea programada. Pero un análisis más profundo reveló un conjunto de circunstancias más interesante. Al investigar el evento en cuestión y realizar un análisis de causa raíz (RCA), Huntress pudo vincular esta intrusión con una vulnerabilidad anunciada recientemente, así como con un conocido marco de post-explotación usado por grupos de ransomware prominentes. Gracias a una combinación de triaje inicial rápido, acción oportuna e investigación más profunda, Huntress pudo mitigar y prevenir una intrusión que probablemente habría derivado en un incidente de ransomware disruptivo.
El evento
El Centro de Operaciones de Seguridad de Huntress recibió dos alertas para un sistema administrado el 02 de febrero de 2023. La primera alerta fue por certutil descargando un archivo desde un recurso remoto:
Usar certutil para descargar un archivo no es malicioso por sí solo. La pregunta importante que siempre hay que hacerse sobre esta actividad es: "¿Qué se descargó?". En este caso, no pudimos obtener mucha información de inmediato. Intentamos conectarnos al recurso nosotros mismos para descargar el archivo y analizarlo, pero el puerto parecía ya estar cerrado.
Al revisar recursos disponibles públicamente, VirusTotal sí mostró un par de recursos que marcaban esta IP como maliciosa, y que estaba alojada físicamente en Bulgaria. Esta información no fue suficiente para confirmar qué estaba pasando, pero sí indicó que la dirección IP probablemente no era una dirección IP conocida y asociada de forma legítima con la organización.
Como no pudimos obtener el archivo en ese momento para analizarlo directamente, y había poca información disponible públicamente, tuvimos que buscar otra evidencia en el sistema mismo para intentar determinar si se trataba de actividad maliciosa. Al observar más de cerca el primer comando ejecutado, el archivo se descargó en el directorio C:\users\Public, seguido de un intento de ejecución del archivo descargado con rundll32.exe. Almacenar y ejecutar archivos desde el directorio C:\users\Public es una táctica común usada por los atacantes, lo que hizo que la actividad pareciera más sospechosa. Saber que la DLL también se ejecutó elevó aún más el nivel de riesgo del incidente, ya que si se trataba de malware descargado, ahora estaba corriendo en el sistema.
La pregunta principal que queríamos responder en este punto era: ¿qué era el dll? ¿Qué hace? Como el archivo ya no estaba presente en el sistema, no pudimos hacer ingeniería inversa ni análisis de malware nosotros mismos. Sin embargo, una parte de la ejecución del dll apuntó a lo que podría estar pasando.
El comando de ejecución intentado fue: rundll32.exe C:\Users\Public\gamft.dll,ChkdskExs lo que indica la ejecución de un recurso exportado específico dentro del DLL. Este es un comportamiento normal, sin embargo, este punto de entrada ESPECÍFICO no es normal y de hecho es bastante singular, y esto dio lugar a la segunda alerta para este sistema. Huntress ha observado anteriormente esta actividad proveniente de un malware llamado Truebot, que hace referencia a la misma exportación. Esto se puede ver en las cadenas de otro DLL de Truebot conocido:
Huntress pudo determinar con mayor certeza que el DLL probablemente era malicioso, según la creación de tareas programadas con nombres muy específicos, utilizadas como persistencia para ejecutar el DLL malicioso. Estas tareas se llamaban:
NvTmRep_CrashReport3_{B2FE1952-0186-36D3-AAHC-AB80CA35AH5B6}
NvTmRep_CrashReport2_{B2FE1952-0186-26H3-AAHC-FB80AA35AH5B1}
Estas tareas apuntaban a la misma ejecución de DLL descrita anteriormente: rundll32.exe C:\Users\Public\gamft.dll,ChkdskExs Cabe destacar que estos nombres de tareas también seguían un patrón coherente con muestras recientes de Truebot que hemos visto, ilustrado en la siguiente expresión regular (regex): NvTmRep_CrashReport[0-9]{1}_{[0-9A-Z]{1}2FE1952-0186-[0-9A-Z]{4}-AAHC-[0-9A-Z]{7,8}AH5B[0-9]{1}} .
El regex anterior proporcionó un punto adicional de detección para Huntress. Estos nombres están diseñados para hacerse pasar por tareas programadas legítimas de informes de fallos de NVIDIA que usan NVTmRep.exe, como se ilustra a continuación:
NvTmRep_CrashReport4_{B2FE1952-0186-46C3-BAEC-A80AA35AC5B8}
Estas tareas normalmente ejecutan un archivo ejecutable legítimo de NVIDIA, como:
C:\Program Files\NVIDIA Corporation\NvBackend\NvTmRep.exe.
Otro factor importante que Huntress observó fue que estos dos comandos (certutil y rundll32) fueron ejecutados por el usuario GoAnywhereSvcAcct en un sistema claramente designado para procesar transacciones de GoAnywhereMFT.
La pregunta ante comandos extraños ejecutados en un servidor debería ser: "¿De dónde vinieron?" En este caso, el proceso principal fue tomcat.exe, ejecutándose desde un subdirectorio dentro del directorio C:\Program Files\Linoma Software\GoAnywhere. Apache Tomcat es un servidor de aplicaciones Java de código abierto, y normalmente se accede a él desde internet como servidor web; ¡esto normalmente no incluye la ejecución de utilidades nativas como certutil.exe o rundll32.exe en el sistema operativo del equipo!
En este punto, la actividad parece ser algún tipo de vulneración del servidor web, que dio lugar a la descarga y ejecución de un archivo malicioso. Las observaciones iniciales indican una probable superposición o relación con Truebot, pero no hay evidencia suficiente para respaldar esta afirmación en este punto de la investigación.
El método usado para obtener acceso al servidor era desconocido hasta este punto, y la actividad prevista después de la explotación en el equipo también se desconoce, ya que no se había observado más actividad a través de la telemetría de EDR. Curiosamente, Huntress identificó que, después de que el servidor fue aislado debido a la actividad observada, se recibió una alerta similar para otro sistema de la organización; este sistema también estaba designado para servicios de GoAnywhereMFT. Esto generó aún más sospechas sobre la naturaleza de este ataque y la participación de la aplicación GoAnywhereMFT, lo que motivó una investigación y un análisis más profundos.
Investigación y análisis de causa raíz
Después de la clasificación inicial y la respuesta al incidente, el equipo de Huntress investigó cómo y por qué ocurrió la actividad observada. Un punto central de este análisis fue entender la relación entre la actividad maliciosa observada —una combinación de creación de tareas programadas y un aparente intento de descarga de un payload de segunda etapa— y los procesos principales y usuarios en ejecución.
En ambos servidores afectados, el origen de la actividad parecía ser el mismo: ejecución bajo una cuenta de servicio (GoAnywhereSvcAcct) en el contexto del servidor web Apache Tomcat. Esta combinación, junto con los nombres de los servidores afectados, apunta al software GoAnywhere Managed File Transfer (MFT). Aunque las razones precisas por las que este software estuvo involucrado siguen siendo indeterminadas por ahora, los analistas de Huntress pudieron rastrear la actividad de la vulneración hasta esta aplicación.
En esta etapa, surgieron varias posibilidades; por un lado, un adversario podría haber forzado por fuerza bruta la conectividad remota de los servidores en cuestión para obtener acceso al entorno y luego ejecutar comandos posteriores en el contexto de la cuenta comprometida. Alternativamente, el servicio mismo podría haber sido explotado, lo que resultó en una ejecución remota de código (RCE) posterior en el entorno de la víctima como procesos secundarios bajo el software GoAnywhere.
En los primeros momentos del análisis y la clasificación, la causa precisa o la vía hacia la ejecución de comandos del adversario era desconocida, una circunstancia no inesperada en medio de una defensa y respuesta gestionadas y sensibles al tiempo. Sin embargo, una investigación y un análisis más profundos, junto con un monitoreo diligente de los informes de fuentes abiertas y publicaciones en redes sociales, pronto resultarían útiles para revelar más sobre este evento y permitir una contextualización adecuada del incidente.
Análisis de fuentes abiertas y enlaces
El 02 de febrero de 2023, aproximadamente al mismo tiempo que el incidente descrito anteriormente, el reportero de seguridad Brian Krebs publicó en Mastodon sobre una vulnerabilidad de ejecución remota de código en el software GoAnywhere MFT. El aviso de seguridad, que no se hizo público y que hasta el momento de esta redacción no tiene un CVE asociado, se describió de la siguiente manera:
Se identificó un exploit de inyección remota de código de día cero en GoAnywhere MFT. El vector de ataque de este exploit requiere acceso a la consola administrativa de la aplicación, que en la mayoría de los casos solo es accesible desde dentro de una red privada de la empresa, a través de VPN, o mediante direcciones IP en lista de permitidos (cuando se ejecuta en entornos en la nube, como Azure o AWS).
Con base en esta descripción, y dada la combinación de los sistemas afectados (servidores de archivos GoAnywhere), los usuarios y procesos afectados posteriormente (vinculados a las operaciones de GoAnywhere), y las acciones observadas (intento de descarga de segunda etapa), llegamos a una explicación plausible para las alertas observadas. Un servidor GoAnywhere con una interfaz de administración expuesta externamente fue comprometido en o antes del 02 de febrero de 2023, lo que llevó a un intento de actividad de reconocimiento y persistencia posterior a la explotación.
Tras el análisis y descubrimiento inicial, surgió más investigación que identificó la vulnerabilidad específica en el software GoAnywhere MFT el 06 de febrero de 2023. Dada la relativa simplicidad de la vulnerabilidad (y la capacidad de hacer ingeniería inversa de un payload a partir del aviso no público del proveedor), Huntress considera que este análisis equivale efectivamente a la publicación de una prueba de concepto (POC) para este exploit en el mundo real. Como resultado, anticipamos una actividad más amplia.
Análisis de artefactos y posible responsabilidad
Aunque Huntress ya realizó un análisis significativo de los endpoints infectados y de las acciones posteriores (intentadas o no) tras la explotación, un verdadero RCA requiere "profundizar más". Aunque los detalles son algo escasos, quedan suficientes elementos, desde la infraestructura de red hasta una muestra de malware, para llevar a cabo más investigación y análisis.
Investigación de la infraestructura
La dirección IP mencionada, 5.188.206[.]76, está asociada con un proveedor búlgaro de servidores privados virtuales (VPS). Aunque esto por sí solo puede resultar sospechoso, como analistas debemos profundizar para entender, de ser posible, la creación, disposición y uso de esta infraestructura.
Según el comando observado mediante la telemetría y las alertas de EDR, el equipo remoto tenía un listener HTTP en el puerto TCP 8000 el 2 de febrero de 2023. Cabe destacar que este puerto está asociado con el puerto de acceso administrativo de GoAnywhere MFT, el objetivo del RCE reportado. Investigaciones posteriores muestran que este puerto (y todos los demás, excepto SSH) se cerraron poco después del incidente, lo que solo deja posibilidades de administración remota. Por lo tanto, es posible que el actor de amenazas rote la infraestructura con frecuencia, lo que limita la utilidad de las listas de bloqueo de IP y herramientas similares para la defensa proactiva, o que esta pieza específica de infraestructura se haya considerado "quemada" y, por ende, se haya "desactivado" para futuras operaciones.
La combinación de comunicación directa con una dirección IP (es decir, sin usar un nombre de dominio con su correspondiente búsqueda DNS) junto con un puerto no estándar para un servicio estándar (HTTP sobre TCP 8000) ofrece un posible punto de detección, aunque limitado. Con pocos detalles adicionales que explorar, esta línea de investigación se cierra; tenemos una dirección IP, pero una capacidad limitada (dado el caso inicial) de profundizar sin observaciones adicionales.
Investigación del binario
Con la investigación de la infraestructura de red cerrada, podemos continuar con el análisis del binario en cuestión que estaba alojado en el recurso remoto. Huntress finalmente logró recuperar una copia de este archivo, con las siguientes características:
Nombre: gamft.dll
MD5: 82d4025b84cf569ec82d21918d641540
SHA1: 62f5a16d1ef20064dd78f5d934c84d474aca8bbe
SHA256: c042ad2947caf4449295a51f9d640d722b5a6ec6957523ebf68cddb87ef3545c
El archivo se compiló a fines de enero de 2023, poco antes, pero no inmediatamente antes, del incidente en cuestión, y contiene varias características interesantes. Un elemento que llama la atención de inmediato es el nombre del archivo. "Gamft" puede parecer semialeatorio al principio, pero parece ser una abreviatura de "GoAnywhere Managed File Transfer". Huntress no tiene conocimiento de ninguna DLL legítima asociada con el software GoAnywhere MFT ni de cuál sería su convención de nombres, pero esta imitación deliberada probablemente representa un esfuerzo del adversario por evadir la detección o un mayor escrutinio.
Además del nombre "legítimo", el archivo es un binario firmado, con el siguiente certificado de firma emitido por Sectigo:
Nombre: SAVAS INVESTMENTS PTY LTD
Estado: Válido
Emisor: Sectigo Public Code Signing CA R36
Válido desde: 12:00 a. m. del 07/10/2022
Válido hasta: 11:59 p. m. del 07/10/2023
Huella digital: 8DCCF6AD21A58226521E36D7E5DBAD133331C181
Número de serie: 00-82-D2-24-32-3E-FA-65-06-0B-64-1F-51-FA-DF-EF-02
Búsquedas rápidas identifican publicaciones en redes sociales, así como en otros recursos, que señalan este certificado (o al menos, certificados asociados con "Savas") como vinculado a actividad maliciosa.
Un análisis más profundo revela señales de funcionalidad, como cadenas que hacen referencia a funcionalidad posterior de PowerShell y WMI, además de actividad POST hacia infraestructura de comando y control (C2). Sin embargo, lo que más llamó la atención fueron referencias a lo que parecen ser comandos o funciones del malware:
KLLS
404NO
Por último, el análisis de la ejecución identificó la infraestructura de C2 para esta muestra:
hXXp://qweastradoc[.]com/gate[.]php
La combinación de elementos, incluido el uso de un certificado de firma de código Sectigo, referencias a cadenas de comandos y patrones de dominio e infraestructura de C2, coincide estrechamente con una campaña descrita inicialmente por Cisco Talos en diciembre de 2022. Según el análisis preliminar, la hipótesis anterior de Huntress sobre la naturaleza de este malware parece ser correcta: la DLL recuperada parece ser una versión actualizada de una familia de malware conocida como Truebot, asociada con un actor de habla rusa conocido como Silence.
Posible responsabilidad
Si bien Huntress pudo identificar y contener este evento de infección antes de que el adversario pudiera realizar más acciones, hay suficiente información disponible para llegar a algunas teorías plausibles sobre la responsabilidad. Como se mencionó anteriormente, Truebot está vinculado a un grupo conocido como Silence. Según lo informado por el CERT francés, Silence ha estado activo de alguna forma desde 2016, con Truebot funcionando como una herramienta de acceso inicial y poscompromiso para las operaciones de esta entidad.
Aunque los vínculos no son concluyentes, el análisis de la actividad de Truebot y sus mecanismos de implementación indican conexiones con un grupo conocido como TA505. Los distribuidores de una familia de ransomware conocida como Clop, según informes de varias entidades, vinculan la actividad de Silence/Truebot con operaciones de TA505. Con base en las acciones observadas e informes anteriores, podemos concluir con confianza moderada que la actividad observada por Huntress tenía como objetivo implementar ransomware, con una posible explotación oportunista adicional de GoAnywhere MFT para el mismo fin.
Orientación y recomendaciones de defensa
El incidente anterior abarca dos problemas de seguridad distintos: la explotación del lado del servidor para el acceso inicial al sistema, y las acciones posteriores a la explotación para "escapar" de un punto de acceso inicial hacia un compromiso más amplio de la red. Una defensa resiliente requiere invertir en contramedidas defensivas y monitoreo a lo largo de estas fases de operación, así como en las acciones de etapas posteriores, en caso de que este incidente en particular no se hubiera identificado en una etapa relativamente temprana.
Detección y prevención de exploits
Idealmente, los defensores pueden identificar (o bloquear) intentos de explotación (especialmente aquellos contra dispositivos de cara externa que conducen a RCE). Sin embargo, en este caso específico, parece que tenemos un verdadero problema de día cero, en el que los adversarios identificaron una falla en el software objetivo (GoAnywhere MFT) antes de que el proveedor pudiera lanzar un parche. Por lo tanto, implementar detecciones mediante monitoreo de seguridad de red se vuelve poco viable, y eliminar la vulnerabilidad tampoco es posible (al momento de escribir esto).
Aproximadamente una semana después de publicar el aviso a los clientes, y tras la explotación activa descrita anteriormente, el proveedor de GoAnywhere, Fortra, publicó un parche para los usuarios el 7 de febrero de 2023. Sin embargo, esto deja un período prolongado de vulnerabilidad incluso si las organizaciones logran probar e implementar rápidamente esta solución. Para eventos como estos en el futuro, las organizaciones deben, ante todo, trabajar para limitar los servicios expuestos externamente solo a los necesarios para su función comercial, y trabajar para proteger y monitorear esos elementos restantes como parte de la gestión de la superficie de ataque.
Lamentablemente, aunque este consejo es acertado, también es difícil de implementar y mantener con el tiempo. Por eso, los propietarios de sistemas y los defensores deben extender la defensa y el monitoreo más allá del perímetro, para asegurarse de que, si (o más probablemente cuando) un adversario logre el acceso inicial, aún existan opciones para detectar y neutralizar dicha actividad.
Defensa e identificación posterior a la explotación
De manera crítica en este incidente, Huntress identificó e inició una respuesta muy temprano en el ciclo de vida de este atacante, mediante la identificación de comportamientos posteriores a la explotación. Los defensores deben buscar oportunidades para marcar y responder a comportamientos fuertemente correlacionados con actividad maliciosa. Los ejemplos vinculados a este evento incluyen, entre otras, las siguientes posibilidades:
- Uso de
certutilpara recuperar y decodificar contenido alojado de forma remota. - Aplicaciones no estándar o inusuales (como Apache Tomcat) que generan procesos como
certutil - (junto con otros mecanismos de desofuscación o ejecución como
PowerShello similares). - Uso inusual de
rundll32.exe, como llamar a binarios desde ubicaciones de disco atípicas. - Intentos de lograr presencia persistente en un sistema mediante la creación de nuevas tareas programadas.
Si bien los adversarios pueden lograr el acceso inicial a la red defendida, el monitoreo en capas de la actividad posterior a la explotación puede detectar (y, con suerte, neutralizar) a los adversarios antes de que puedan consolidar su presencia dentro de la red y moverse lateralmente.
Conclusiones
Huntress identificó y mitigó una intrusión asociada con la explotación de un día cero mediante el monitoreo en capas de un entorno de cliente. Al detectar la actividad posterior a la explotación en una etapa temprana, la organización víctima pudo evitar un probable evento de ransomware que le podría haber costado muy caro.
Mediante una combinación de detección y monitoreo en capas, así como un análisis de causa raíz posterior al incidente, los investigadores de Huntress identificaron no solo la causa probable de este incidente (la explotación de una vulnerabilidad en GoAnywhere MFT), sino también vínculos con una actividad cibercriminal más amplia. Mediante la aplicación repetida de estos mecanismos —respuesta a incidentes, análisis de incidentes e investigación posterior al incidente—, las organizaciones pueden no solo garantizar una respuesta adecuada a las intrusiones, sino también revelar las motivaciones y los comportamientos técnicos más profundos que las sustentan.
Indicadores de intrusión asociados
Indicadores en el sistema
SHA256
Nombre del archivo
Fecha de compilación
Comentario
c042ad2947caf4449295a51f9d640d722b5a6ec6957523ebf68cddb87ef3545c
gamft.dll
25 de enero de 2023
DLL de Truebot identificada en el incidente.
0e3a14638456f4451fe8d76fdc04e591fba942c2f16da31857ca66293a58a4c3
larabqFa.exe
18 de enero de 2023
Muestra relacionada de DLL de Truebot.
c9b874d54c18e895face055eeb6faa2da7965a336d70303d0bd6047bec27a29d
Pxaz.dll
11 de enero de 2023
Muestra relacionada de DLL de Truebot.
Indicadores de red
Observación
Comentario
5.188.206[.]76
Ubicación de alojamiento de Truebot.
qweastradoc[.]com
Dominio C2 de Truebot.
92.118.36[.]213
IP de alojamiento para el dominio C2 de Truebot.
Oportunidades de detección
Además de los indicadores anteriores, las organizaciones pueden aprovechar herramientas como Sigma para identificar comportamientos sospechosos relacionados con esta intrusión. Huntress tiene un ejemplo de este tipo de regla, que busca instancias en las que Apache Tomcat genera un proceso.
Mapeo de MITRE ATT&CK
Táctica
Técnica
Descripción
Acceso inicial
T1190 - Exploit Public Facing Application
El atacante obtuvo acceso inicial mediante la explotación del servicio GoAnywhere MFT.
Ejecución
T1203 - Exploitation for Client Execution
El atacante obtuvo capacidad de ejecución de código mediante la explotación del servicio GoAnywhere MFT.
Persistencia
T1053.005 - Scheduled Task/Job: Scheduled Task
El atacante creó tareas programadas con fines de persistencia.
Evasión de defensas
T1036.004 - Masquerading: Masquerade Task or Service
El atacante usó convenciones de nombres de archivo para hacerse pasar por procesos y archivos de apariencia legítima.
T1553.002 - Subvert Trust Controls: Code Signing
El atacante usó un certificado de firma de código válido para el payload de Truebot.
T1078.003 - Valid Accounts: Local Accounts
El atacante usó la cuenta asociada con el proceso explotado para acciones posteriores.
T1140 - Deobfuscate/Decode Files of Information
El atacante usó certutil para decodificar un payload codificado de Truebot.
T1218.011 - System Binary Proxy Execution: Rundll32
El atacante usó Rundll32 para intentar ejecutar el payload de Truebot.
Comando y control
T1071.001 - Application Layer Protocol: Web Protocols
Las comunicaciones C2 del payload de Truebot se realizaron a través de HTTP.
T1105 - Ingress Tool Transfer
El atacante intentó obtener y compilar el payload de Truebot mediante un comando de certutil.
T1571 - Non-Standard Port
El atacante usó HTTP a través de un puerto no estándar para obtener el payload de Truebot.
T1132.001 - Data Encoding: Standard Encoding
El atacante codificó el payload de Truebot para su decodificación estándar mediante certutil.
*Un agradecimiento especial a Matt Anderson por su ayuda con la redacción de este blog.
