Muito já foi escrito sobre os ataques do trojan bancário RTM contra contadores e diretores financeiros, incluindo
especialistas do Grupo IB, mas até agora não houve um único estudo de caso de dispositivos infectados com RTM no campo público. Para corrigir essa injustiça, um dos principais especialistas em computação forense do Grupo-IB,
Oleg Skulkin , falou detalhadamente sobre como conduzir uma investigação forense de um computador infectado por um cavalo de Troia bancário como parte de uma resposta / investigação de incidente.
Como tudo começou
Os pesquisadores aprenderam sobre as atividades do grupo criminoso da RTM em dezembro de 2015. Desde então, as correspondências de phishing que distribuem esse trojan foram enviadas para as caixas de correio eletrônicas das possíveis vítimas com constância invejável.
Como você já sabe, de setembro a dezembro, o grupo RTM enviou mais de 11.000 emails maliciosos. Os cibercriminosos não vão parar no que foi alcançado, como evidenciado por todas as novas correspondências que registramos tanto em sensores que protegem nossos clientes quanto na estrutura de coleta de dados sobre ameaças atuais.
Neste artigo, mostrarei como conduzir uma investigação forense, ou simplesmente forense, da imagem de uma unidade de computador infectada por um Trojan RTM bancário.
Introdutório necessário
Imagine que não sabemos sobre a infecção do computador RTM, mas apenas o fato de comprometimento, cujo resultado foi o roubo de dinheiro - isso nos permitirá construir o processo de pesquisa de maneira mais interessante e torná-lo aplicável a outros casos. Também quero chamar a atenção para o fato de que, no quadro deste artigo, não vou me concentrar na engenharia reversa do trojan: primeiro, essa não é a competência do cientista forense e, segundo, meu colega Semyon Rogachev escreveu sobre isso em detalhes em
Habré .
Então, tudo o que temos é a imagem da unidade do computador no formato "E01" (Encase Image File Format). Para começar, seria bom descobrir o que há dentro. No mínimo, o sistema operacional, porque é dele e de sua versão, é claro, que depende a presença de certos artefatos forenses que precisamos investigar.
1. Usaremos o utilitário mmls do pacote do Kit Sleuth de Brian Carrier:
O que nós temos? Várias partições NTFS semelhantes ao Windows. Precisamos ter certeza - tentaremos encontrar arquivos de registro, por exemplo, SOFTWARE.
2. Usaremos os utilitários fls (o Sleuth Kit) e o findstr para descobrir o número de registro correspondente na tabela principal de arquivos (MFT):
Ok, agora podemos copiar o arquivo necessário para análises adicionais usando o icat (o Sleuth Kit):
icat -o 718848 E: \ RTM.E01 234782> SOFTWARE
Portanto, como temos um arquivo de registro de SOFTWARE, podemos extrair as informações mais significativas das quais, por exemplo, usando o RegRipper Harlan Carvey. No momento, estamos interessados no conteúdo da seção Microsoft \ Windows NT \ CurrentVersion:
Agora sabemos que o computador em estudo estava executando o Windows 7 Professional com Service Pack SP1, o que significa que sabemos quais artefatos forenses podemos encontrar e quais podemos precisar.
Por onde começar nossas pesquisas? Lembre-se do paradoxo de Jesse Kornblum: "O malware pode ocultar, mas deve ser executado". Um bom começo pode ser a busca de possíveis mecanismos de bloqueio no sistema que permitam reiniciar programas maliciosos após a reinicialização do computador.
Vamos começar com um simples: pegue o
arquivo de registro
NTUSER.DAT do diretório do usuário (C: \ Users \% username% \) com a data da modificação mais recente e extraia os dados usando o mesmo RegRipper. Se quisermos obter novamente o número de registro do arquivo que precisamos usando fls e findstr, precisamos adicionar a opção –p a fls - isso permitirá que o utilitário exiba os caminhos completos para os arquivos. Por que isso é necessário? O fato é que cada usuário possui um arquivo NTUSER.DAT no diretório e o SOFTWARE é o único para todo o sistema, portanto, nesse caso, é importante obter o número de registro de um arquivo específico. Em geral, o uso do Kit Sleuth não é necessário, existem ferramentas mais convenientes, por exemplo, o
FTK Imager , uma ferramenta de desenvolvimento gratuita do AccessData que pode ser usada não apenas para criar cópias forenses, mas também para examinar seu conteúdo:
Vamos começar com os frutos baixos, as chamadas
"teclas de execução" :
Então o que nós temos? A seção foi modificada pela última vez em 7 de novembro e vemos que, quando o usuário efetua login, o arquivo apg.exe é iniciado a partir de um local não padrão. Vamos ver o que mais pode ser encontrado no diretório b7mg81:
TeamViewer? Interessante. Vamos dar uma olhada em apg.exe - use
PPEE :
Parece o TeamViewer, inscrito no TeamViewer, então é o TeamViewer? Parece que sim. Mas não é tão simples. Vamos dar uma olhada na tabela de importação:
Então, msi.dll, em algum lugar já vimos esse arquivo, e não é C: \ Windows \ System32, mas o mesmo diretório b7mg81. A julgar pelo tamanho, não tem nada a ver com o msi.dll original, o que significa que está disponível -
Seqüestro de ordem de pesquisa DLL : o sistema operacional começa a procurar as bibliotecas necessárias no diretório atual, o que significa que, em vez do legítimo msi.dll, o arquivo localizado será carregado em b7mg81.
Outro arquivo interessante é o
TeamViewer.ini :
E aqui está o contra-forense: a julgar pelo arquivo de configuração, nosso TeamViewer não manteve nenhum registro e, aparentemente, foi usado como um RAT. Bem, nada mal. É hora de descobrir se tudo começou.
Existem alguns artefatos no Windows que indicam que os arquivos executáveis estão em execução. Vamos continuar trabalhando com o registro, desta vez com o
arquivo SYSTEM . Para extrair dados dele, você pode novamente usar o RegRipper.
Estamos interessados em ControlSet001 \ Control \ Session Manager \ AppCompatCache. Aqui encontramos uma lista de arquivos executáveis com caminhos para eles, datas da última modificação (de acordo com o atributo $ STANDARD_INFORMATION), bem como um sinalizador indicando se o arquivo foi iniciado ou não:
Ótimo, nosso arquivo foi lançado pelo menos uma vez. Portanto, temos um "ponto de articulação", sabemos que, em 7 de novembro, o TeamViewer apareceu na unidade do computador, que não mantinha registros e provavelmente não estava visível para o usuário, pois, em vez da biblioteca legítima, ele carregava a que estava em um catálogo.
É hora de começar a construir uma linha do tempo. Eu acho que é o suficiente do que pode ser construído usando o Kit Sleuth. Vamos começar com o utilitário fls que já conhecemos:
fls.exe -m “C: /” -o 718848 -r -z GMT D: \ RTM.E01> bodyfile.txt
Agora use o mactime para converter o arquivo resultante em uma linha do tempo:
mactime.pl -d -b bodyfile.txt> timeline.csv
As linhas de tempo são muito convenientes para analisar no
Timeline Explorer de Eric Zimmerman . Nossa linha do tempo incluirá apenas eventos do sistema de arquivos. Se você quiser incluir alterações no registro, revistas, etc., use o plaso. Pessoalmente, eu o uso muito raramente, pois o processamento de dados leva muito tempo e o resultado geralmente é bastante redundante.
Voltar para a linha do tempo. O catálogo b7mg81 foi criado em 7 de novembro de 2018 às 13:59:37:
E dois segundos antes disso, o arquivo 21DA.tmp é criado:
Se você procurar sua soma de verificação, por exemplo, no VirusTotal, obteremos resultados bastante interessantes:
Obviamente, nosso RAT foi descompactado deste arquivo. Vá em frente:
Ainda mais cedo, o diretório LocalDataNT é criado com arquivos bastante interessantes. Dê uma olhada no WinPrintSvc.exe, por exemplo:
Utilitários remotos é outra ferramenta de gerenciamento remoto. E aqui está outro arquivo suspeito criado alguns segundos antes:
Verifique sua soma de verificação:
Vários produtos antivírus imediatamente o detectam como "
RemoteAdmin ". Aparentemente, ele é a fonte dos Utilitários Remotos. Verifique se o RAT detectado foi iniciado. Desta vez, usaremos o arquivo de registro AmCache.hve em C: \ Windows \ AppCompat \ Programs (o mesmo RegRipper nos permitirá obter dados dele de forma digerível):
Como você pode ver na ilustração, o AmCache permite obter não apenas a data do primeiro lançamento, mas também a soma de verificação do arquivo.
Então, nós temos dois RATs, mas de onde eles vieram? Boa pergunta! Se você ainda rolar a linha do tempo, veremos traços de criação de um diretório e arquivo bastante suspeitos:
Apesar da extensão estranha, o fnbfdnja.hej tem um cabeçalho familiar:
O que a pesquisa da soma de verificação VirusTotal nos mostra? E aqui está o que:
Como você pode ver na ilustração, alguns softwares antivírus detectam nosso arquivo definitivamente - estamos lidando com o
RTM . A VT pode nos ajudar um pouco mais. Se olharmos para a guia "Relações", veremos o seguinte:
Parece que encontramos o herói da ocasião - este é o "Documents for October.exe". Ou talvez não, o nome associado ao nosso arquivo seja diferente, embora a soma de verificação seja a mesma. Então, novamente .exe, o que significa que precisamos novamente procurar traços de inicialização. Pessoalmente, gosto muito de trabalhar com o registro, então, novamente, usarei a ajuda do já conhecido arquivo NTUSER.DAT e RegRipper. Desta vez, dê uma olhada no
UserAssist - a partir dele, obtemos os nomes e caminhos dos arquivos, as datas de seu último lançamento e o número desses lançamentos. O arquivo "Documents for October.exe" não está visível, mas outro arquivo é visível:
C: \ Usuários \% nome de usuário% \ Desktop \ Documents environment.exe
Bem, isso parece ser o que precisamos. É verdade que há um pequeno problema - não há arquivo no lugar certo. Voltar para a linha do tempo. Após criar o arquivo fnbfdnja.hej, é o que acontece:
Os arquivos no diretório Temp provavelmente pertencem ao RTM, mas não estamos interessados neles. Estamos interessados nos arquivos $ R6K21RQ.exe e $ I6K21RQ.exe. É assim que os arquivos colocados na Lixeira são - o primeiro contém os dados em si, o segundo contém os metadados. Se examinarmos o conteúdo de $ I6K21RQ.exe, veremos imediatamente o caminho para o arquivo desejado - "Documents environment.exe".
É hora de dar uma olhada no que a VT nos oferecerá para sua soma de verificação:
Vemos detecções já familiares para nós - "RTM". Como se viu, a soma de verificação do nosso arquivo coincidiu com a soma de verificação "Documents for October.exe". Além disso, o VT conhece mais alguns arquivos com a mesma soma de verificação:
Seria bom obter algum tipo de indicador de comprometimento da rede. Não temos despejo de memória, despejo de tráfego de rede também, o que devo fazer? Trocar arquivo! Mas como encontrar uma agulha no palheiro? E aqui a VT também nos ajudará um pouco, desta vez
na guia
Comportamento :
Parece C2, certo? Vamos ver se existe algo assim no nosso arquivo de troca (pagefile.sys). Claro, existem:
Portanto, confirmamos que nosso arquivo interagiu com 185.141.61 [.] 246. Vamos tentar encontrar mais indicadores de rede. Um dos RATs era o TeamViewer, tentaremos encontrar algo semelhante ao seu ID. Para isso, você pode, por exemplo, usar expressões regulares:
Ótimo, temos outro indicador de rede - 195.123.219 [.] 87. Obviamente, os arquivos de troca não são adequados apenas para encontrar indicadores de rede. Se retornarmos à guia Comportamento no VT, veremos que nosso arquivo cria tarefas no agendador. Se olharmos para a linha "fnbfdnja.hej", encontramos o seguinte:
A tarefa criada inicia o fnbfdnja.hej através do rundll32.exe.
Bem, é hora de terminar. Está na hora de determinar de onde veio o arquivo "Documents environment.exe". Já sabemos que se trata de RTM e, como é RTM, o vetor mais provável de infecção é um email de phishing. Nesse caso, a vítima usou o Microsoft Outlook; portanto, encontramos o arquivo .ost com correio no local habitual e nele o mesmo email de phishing:
No entanto, não quero terminar nosso post sobre isso, mas sobre outro artefato interessante. Se voltarmos ao arquivo NTUSER.DAT e examinarmos o valor do parâmetro "Shell" na seção Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon, em vez do habitual "explorer.exe", veremos o seguinte:
E isso significa que, depois que o usuário efetuar login, em vez de iniciar o Explorer, o sistema será encerrado e, com isso, a conclusão deste artigo.