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.

Estágio Detecção
1º Win32/TrojanDownloader.Banload.YAV
2º

 Win32/Spy.Banker.ADYR

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).

Estágio Detecção
1º LNK/TrojanDownloader.Agent.GA
2º

 MSIL/TrojanDownloader.Agent.DSW
3º Win64/Spy.Agent.AD (x64)
Win32/Spy.Banker.ADYV
Win32/Spy.Banker.AEBZ

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:

Estágio Detecção
1º LNK/TrojanDownloader.Agent.GM
2º
3º Win64/Spy.Agent.AD (x64)
Win32/Spy.Banker.ADYV
Win32/Spy.Banker.AEBZ

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.

Estágio Detecção
1º Win32/TrojanDownloader.Banload.YAF
2º

 Win32/Spy.Banker.AEAU

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.