Padrões de ataque dos grupos de cibercriminosos brasileiros

Padrões de ataque dos grupos de cibercriminosos brasileiros

Confira um panorama completo sobre as estratégias de ataque utilizadas pelos cibercriminosos brasileiros nos últimos tempos.

Confira um panorama completo sobre as estratégias de ataque utilizadas pelos cibercriminosos brasileiros nos últimos tempos.

Não é novidade que o cibercrime brasileiro é bastante extensivo, porém tem apresentado uma notória evolução em suas capacidades técnicas nos últimos tempos.

Essa evolução, em conjunto com certa medida de criatividade e impetuosidade de sucessivas campanhas lançadas no Brasil, começou a chamar a atenção de pesquisadores ao redor do mundo para as campanhas brasileiras, que passaram a dar destaque e se dedicaram a analisar essas campanhas.

Nas últimas semanas houve uma série de campanhas, cujas análises propiciaram discussões riquíssimas sobre o cibercrime brasileiro. Portanto, o intento desse post é reorganizar o que foi analisado e debatido, a fim de colocar luz sobre alguns padrões recorrentes nessas campanhas e melhor compreender o funcionamento do cibercrime brasileiro.

Campanhas de setembro

A primeira campanha a receber atenção no Twitter ocorreu no dia 2 de setembro, quando a conta MalwareHunterTeam notou o surgimento de uma grande campanha usando (abusivamente) a infraestrutura do Facebook para sua propagação.

O vetor inicial de ataque escolhido, como ocorre frequentemente no Brasil, foi phsihing. Um email que se passava por uma Nota Fiscal Paulista contendo um link para, aparentemente, realizar o download da nota. No entanto, ao clicar, o usuário era levado a realizar o download de malwares bancários – até aí, não há nada diferente do que já estamos acostumados a ver.

A novidade ficou por conta do lugar escolhido para o armazenamento desse malware bancário: CDN do Facebook. O uso de CND para armazenamento de malware não é algo comumente visto, fato que foi um dos temas de uma publicação do WeLiveSecurity em julho deste ano – também envolvendo malwares bancários focados no Brasil.

Essa coincidência incitou uma análise mais minuciosa dessa campanha. Além disso, colaborou o fato de mais de 200 mil pessoas abrirem o email da campanha em menos de 24h – um número bastante acima do registrado em campanhas “rotineiras”.

A análise mostrou que o ataque consistia de três estágios: no primeiro era baixado um arquivo .RAR contendo um malware downloader .LNK (i.e.: arquivo de link do Windows), que fazia o download (sob certas condições) de outro downloader. Quando executado na máquina, o payload final utilizava-se da mesma técnica vista na campanha de julho para se executar (i.e.: DLL preloading/DLL side-loading).
Esta campanha teve ainda outra coincidência com outra publicada em julho: o mesmo padrão DownAndExec estava também presente: uso do paramêtro “x-id” para download do payload final, funções isOS(), haveAnyPrograms(), isBR(), etc. Desta vez, no entanto, ao invés de codificado em um script JS, estava em C#.

Figura 1: Exemplo de componentes do padrão DownAndExec presentes na campanha de julho, em Javascript, e Setembro, em C#

Dois dias após, em 4 de setembro, houve uma nova campanha abusando da CDN do Facebook para a propagação de malwares bancários. Essa campanha seguiu os mesmos moldes da campanha anterior, tendo um banload detectado como Win32/TrojanDownloader.Banload.XXK e um malware bancário executado via side-loading como payload final, muito semelhante ao observado na campanha DownAndExec de julho.
Nos dias seguintes, pré-feriado e feriado no Brasil, as campanhas se intensificaram. No dia 6 de setembro, surgiu uma nova campanha abusando da CDN do Facebook.  Esta campanha teve características diferentes das anteriores, não estando presente, nesse caso, o padrão DownAndExec.
Neste caso, o phishing induzia ao download de um arquivo ZIP, detectado pela ESET como Win32/TrojanDownloader.Banload.YAV, contendo um arquivo .EXE, cuja função era o download de um payload final que comprometia a máquina para o roubo de credenciais bancárias de diferentes bancos.
Em especial, o payload final, detectado como Win32/Spy.Banker.ADYR, consistia em um ZIP com a senha “102030” – senha, essa, que vimos em outras campanhas. O motivo do uso da senha é o impedimento da detecção do payload durante o seu download, embora conteúdos maliciosos sejam prontamente detectados por proteções proativas durante a descompressão.

No dia 7 de setembro, feriado, novas campanhas surgiram. Na primeira campanha citada (i.e.: campanha #1), além de estar utilizando (novamente) a CDN do Facebook, novamente o malware do segundo estágio consistia em um arquivo ZIP, detectado como Win32/TrojanDownloader.Banload.YAV, com um banload que baixava seu payload do mesmo domínio da campanha do dia anterior. Pode-se concluir que ambos banloads faziam parte de uma mesma campanha, que contava com diferentes arquivos para download de banker de um mesmo C&C a fim de aumentar a sobrevida da campanha.

Figura 2: Campanha com múltiplos banloads entre os dias 6 e 7 de setembro.

Na segunda campanha (i.e.: campanha #2), o downloader do primeiro estágio consistia em um script JS que baixava na máquina um banload (segundo estágio), que, por sua vez, fazia o download do payload final (terceiro estágio), um ZIP contendo uma DLL maliciosa, detectada como:

Na terceira e última campanha publicitada neste dia (i.e.: campanha #3), foi utilizada uma nova técnica para burlar detecções que procuram pelo “powershell” em arquivos .LNK.

O motivo desta técnica é permitir o uso de arquivos .LNK como atalhos para o executável powershell.EXE, que vem por padrão no Windows, para executar scripts contidos nesse arquivo através da opção –EncodedCommand.

Figura 3: Técnica de bypass de detecções de “powershell” em arquivos .LNK.

Em particular, o arquivo .LNK, detectado pela ESET como LNK/TrojanDownloader.Agent.GA, estava hospedado também na CDN do Facebook, e continha o mesmo padrão de nome (inclusive com o erro ortográfico na palavre “FISCAL”) da campanha de 2 de setembro.

A próxima campanha a ser acompanhada ocorreu no dia 11 de setembro. Nesta campanha, semelhantemente a do dia 6 de setembro, o payload final consistia em um ZIP correspondente à campanha de ZIP com senha “102030”. A cadeia de ataque consistia em um banload (primeiro estágio) que fazia o download e executava o payload final (segundo estágio), que estava armazenado na infraestrutura do GoogleDocs.

No dia 13 de setembro voltaram a aparecer diversas campanhas. A primeira delas voltou a apresentar grandes taxas de abertura de email (i.e.: 100-200 por minuto) por parte das vítimas das campanhas de phishing.

Esta campanha, apesar de empregar a recente técnica de bypass de “powershell” em arquivos .LNK, foi essencialmente igual a campanha do dia 2 de setembro: consistia de três estágios, novamente abusando da CDN do Facebook, contendo um downloader .LNK (primeiro estágio) em um arquivo .RAR, o segundo estágio sendo um downloader (segundo estágio) para diferentes payloads finais (terceiro estágio).

A segunda campanha trouxe uma família de trojan referida, pela IBM Trusteer, como Client Maximus. O método de infecção é exatamente o observado nas campanhas anteriores, que faziam uso de preloading/side-loading para carregar DLLs maliciosas em executáveis assinados e legítimos. Com a recente atualização referente ao Client Maximus, é possivel afirmar que se trata exatamente da família de malware que faz uso do padrão DownAndExec.

A terceira campanha abusou do S3 da Amazon AWS, para hospedar um banker, detectado como Win32/Spy.Banker.ADYR, contido em um ZIP com a senha “102030” novamente.

A quarta campanha citada seguiu o mesmo padrão Client Maximus/DownAndExec das anteriores:

No dia seguinte, 14 de setembro, voltamos a ver outra campanha. Desta vez, com uma cadeia de ataque de apenas dois estágios, novamente utilizando preloading/side-loading como forma de ataque. Importante notar que os payloads finais estavam empacotados com VMProtect e Themida, que são soluções avançadas para a proteção de binários contra engenharia reversa.

Dia 16 de setembro foi realizada uma campanha cuja família do payload final estava dormente durante quase todo o ano de 2017. A cadeia de ataque consistia em dois estágios, o primeiro, banload detectado como Win32/TrojanDownloader.Banload.WEL, hospedado no Google Docs, e o segundo com dois arquivos, um executável detectado como Win32/DllInject.IP e uma DLL detectada como Win32/Spy.Banker.ADLZ.

Figura 4: Histórico de detecções de Win32/Spy.Banker.ADLZ criação.

 

Conclusão

O mês de setembro foi marcado por diversas campanhas no Brasil acompanhadas de perto por pesquisadores de todo o mundo. Isso permitiu uma grande troca de informação, rica discussão e o levantamento de padrões depreendidos de algumas características peculiares a cada campanha.

Apesar de ter havido mais campanhas, neste post destacamos apenas onze delas, que foram analisadas cooperativamente no Twitter. Preliminarmente, se analisarmos cada campanha em diferentes capacidades/característica podemos montar a tabela abaixo:

Nela é possivel observar que, o grupo por trás do padrão DownAndExec (que coincide, como evidenciou a campanha de 13 de setembro, com o que a IBM Trusteer já havia publicado a respeito do Client Maximus), possui alta sofisticação técnica.

É provável que a campanha do dia 07 de setembro, que apresentou uma nova técnica para tentar se evadir de detecções de “powershell” em arquivos .LNK também esteja relacionado ao mesmo grupo – o que não foi possível verificar devido à realização célere do takedown.

Assim, é possível notar que o grupo, além de trabalhar com padrão de ataque (i.e.: DownAndExec), fazer uso de packers comerciais, utilizar técnicas avançadas de comprometimento (i.e.: side-loading), também é capaz de inovar e realizar campanhas massivas de phishing com o intervalo de apenas uma semana.

As campanhas, que também apareceram com recorrência, com payload consistindo em um ZIP com a senha “102030” aparentemente também pertencem a um mesmo grupo. No entanto, neste caso, o grupo apresenta capacidade técnica bastante inferior ao anterior, fazendo uso de bankers “clássicos” escritos em Delphi, apesar de se atentarem a detalhes como a inclusão de rabisco nas imagens das telas utilizadas e de realizarem campanhas com frequência.

Outras campanhas também merecem maior atenção para melhor compreender a ação dos grupos que as encabeçam. Em especial, a campanha do dia 16 trouxe um grau técnico elevado, utilizando um banker que permaneceu praticamente dormente ao longo de todo o ano.

Vale ressaltar que as campanhas ainda continuam acontecendo com bastante frequência, e que continuamos atentos à evolução do cibercrime no Brasil.

Discussão