Utilizaremos o plugin windows.info.Info que mostra os detalhes do sistema operacional e do kernel do DUMP de memória, aqui conseguimos extrair a versão do Windows, data e hora da coleta, é importante informar que o volatility3 mostra o horário em UTC 0 (zero).

Na primeira execução deste comando tenha paciência, ele irá carregar algumas coisas (aqui uma vantagem em comparação com o volatility antigo, o carregamento da imagem é mais rápido) como informações de kernel, módulos etc., e sim é essencial executar este comando para carregar o contexto no qual alguns plugins irão executar e carregar configurações dentro do contexto desta imagem, resumindo constrói um dicionário hierárquico.

Vocês irão perceber muitas vezes que utilizaremos o plugin com digitação “reduzida”, nem todos os plugins se faz necessário digitar duas vezes a mesma palavra que no caso seria “info.Info”. Estão querendo uma dica né? Vamos lá, os comandos que temos o nome do sistema operacional na frente como Windows não precisa usar, porém comandos como o “yarascan.YaraScan” sim (que nesse caso não é especificado o sistema operacional neste plugin) e em comandos como “Windows.registry.printkey” que a terceira palavra muda.

Fique tranquilo, com o tempo vai se acostumar!

Iremos iniciar nossa análise com o plugin de listagem de processos, Windows.pslist, este comando lista todos os processos em execução no despejo de memória, aqui podemos procurar processos suspeitos, neste comando teremos os processos em execução durante a criação do DUMP de memória.

Observe que inclui o parâmetro “-r pretty” ele deixa a saída da lista um pouco mais agradável, aconselho usar apenas em listagens de processos e conexões já que na listagem de chaves de registro ele não funciona muito bem.

Aqui devemos ficar atentos e observar nomes que possam ser estranhos, por exemplo nomes aleatórios como “bwrtendujekke.exe”, “scvhost.exe” ou o nome original mesmo do processo “svchost.exe” já que muitos malwares se disfarçam com esse nome.

Caso perceba algum processo estranho aqui, foque nele e continue para o próximo plugin.

Diferente do Pslist o Psscan que verifica os processos em execução durante criação do DUMP, ele irá realizar um scan mais detalhado trazendo prováveis processos que foram encerrados de forma anormal, por exemplo, quando um usuário encerra um processo manualmente no gerenciador de tarefas ou um processo com conexão interrompida.

Com esse plugin, encontramos um processo estranho chamado de Lenovo.Modern (no próximo tópico mostraremos como verificar o nome por extenso de um processo) e esse processo abre três processos “svchost.exe” algo bem estranho já que na maioria das vezes é executado com o processo pai (PPID) do services.exe.

O processo svchost.exe é usado na maioria das vezes pelo Windows para fechar/estabelecer uma conexão de rede (socket), não necessariamente externa.

Realizamos o mesmo comando, porém, com o número do processo (PID) filtrado com o grep, para verificar seus processos parentes (PPID), verificamos que o processo com o nome de Lenovo.Modern.ImController.PluginHost.2022.2637.472.AutoIt3.exe está executando três processos “svchost.exe”.

Obs.: A partir daqui não usaremos mais o “-r pretty”, lembre-se que o parâmetro -r pode ser usado para saída de arquivo em outros formatos como json e csv, e o diretório de saída que usaremos em breve deve ser usado com o parâmetro -o (exemplo -o \diretório\) e no final do comando o parâmetro > para incluir as informações dentro de um arquivo.

Dica: Existe um comando Windows.pstree que nos mostra a árvore de processos, porém, optei por não usar por enquanto nesta versão do volatility3, já que esse plugin desde o seu lançamento funciona apenas quando não especificamos o processo, ou seja ele é eficiente quando quero analisar todos os processos, se optar por especificar um processo ele traz todos os outros processos.

Segue o que pode acontecer:

Para verificar o nome por extenso de um processo, executaremos o Windows.cmdline (existe outras formas de verificar também) este plugin apresenta os argumentos da linha de comando do processo.

Aqui já percebemos outro fator suspeito, o arquivo está com nome alterado pois o drive Lenovo.Modern.ImController.PluginHost existe e um programa chamado AutoIt3 também existe (falaremos dele mais tarde), além disso conseguimos a localização do arquivo.

Agora a surpresa desse caso, vamos verificar informações na memória sobre o hardware deste equipamento já que recebemos apenas o DUMP de memória.

Utilizamos o comando Windows.registry.printkey para verificar informações das chaves de registro do S.O analisado junto com o parâmetro recurse (para uma pesquisa recursiva) em todas as chaves.

Para identificar o equipamento que estamos verificando utilizamos as chaves de registro já que para esta análise nos foi entregue apenas o DUMP de memória. Caso não entenda como funciona as chaves de registro do Windows pedimos que verifique o site da Microsoft, mas não vamos largar assim. O registro do Windows é um banco de dados do sistema operacional e das aplicações que instalamos, sempre que realizamos uma alteração em um registro realizamos alguma modificação nesse banco, que por sua vez registra nas chaves de armazenamento. Para essa pesquisa utilizaremos um pouco de expressão regular na chave de registro BIOS. Para pesquisas que precisamos usar a barra, informamos ao comando egrep (grep um pouco mais avançado), o “\\” que na verdade queremos apenas informando ao meu comando que o próximo caractere depois da primeira barra é ele mesmo efetivamente e os parênteses servem para separarmos em grupos.

A chave que usamos é \HARDWARE\DESCRIPTION\System\BIOS, nela encontraremos muitas das informações de hardware como modelo e fabricante do equipamento. Aqui já temos uma surpresa! O que um possível “drive” de outra fabricante está fazendo por aqui já que nosso equipamento é da Acer?

Dica: No plugin registry.printkey existe uma maneira de pesquisar por chave (exemplo: ./vol.py -f estudo_AFC.mem Windows.registry.printkey –key “Software\Microsoft\Windows\CurrentVersion” – -recurse), porém devemos ter alguns cuidados, por exemplo, quando usamos com \REGISTRY\HARDWARE\… – -recurse muitas das vezes não traz a informação contida dentro do registro.

Segue o que pode acontecer:

Agora que descobrimos alguns processos suspeitos vamos realizar a extração desses arquivos da memória e realizar algumas verificações.

Primeiro criaremos um diretório usando o comando mkdir com o nome de “processos suspeitos”, para direcionar os arquivos do dump.

Usaremos o comando psscan para realizar os dumps dos processos, lembrando que podem utilizar os plugins pslist e/ou dumpfiles, execute os comandos para os processos 3908, 11784, 13296 e 3604, para especificar o diretório de saída dos arquivos devemos usar o parâmetro “-o” ou “- -output-dir”.

Vamos dar uma olhada no nosso diretório e nos dumps que realizamos. Aqui devemos perceber um comportamento interessante, veja que temos dois processos com os HASHs iguais, seria uma boa ver o tempo em que os processos iniciaram olhando a figura 7, e vemos que o processo 3908 é o único que mudou após as chamadas do PPID 3604, verifique também o tempo de chamadas que parece um padrão certo? Entre 17 e 18 segundos.

Calma eu sei que quando geramos um HASH já dá aquela vontade de jogar lá no Vírus Total e verificar se algum é classificado como malware. Vamos seguir com as análises, não sabemos se é um malware novo e se já devemos compartilhar em plataformas de terceiros.

Depois de ver esse padrão, fiquei achando que poderia ser uma tentativa de conexão, vamos verificar as conexões do equipamento e verificar se achamos algo estranho.

Para isso temos dois plugins o netstat e o netscan. Qual a diferença dos dois? O netstat nos trans as conexões que estão no momento que realizamos o dump de memória e o netscan são conexões que podem ter sido encerradas antes do dump porém não foram sobrescritas na memória.

Não vamos marcar com linha vermelha nem circular um IP e porta para vocês terem a mesma sessão nossa aqui procurando por um IP que possa nos deixar em atenção.

Acharam?

O IP 172.67.137.149 na porta 80 foi esse? Também fiquei com vontade de pesquisar um pouco mais, porém, percebemos que não temos o PID do processo que iniciou essa conexão, sendo assim vamos realizar um teste com o netscan?

Usando o comando netscan verificamos que não temos a conexão em questão e nem tão pouco alguma conexão suspeita, diferente do que muitos acham o netscan não traz a soma do netstat mais as conexões encerradas.

Realizei um filtro apenas na interface de rede com a internet. Podemos dizer aqui que poucas conexões foram sobrescritas então agora vamos tentar relacionar essa conexão com algum PID suspeito.

Dica: É importante saber que quaisquer conexões de rede ativas ou fechadas recentemente permanecem na memória.

O plugin malfind nos ajuda a encontrar códigos e/ou DLLs injetadas ocultas em um espaço de memória, com base em características de sinalizadores descritores de endereço virtual e permissões definidas no VAD de processo (veremos VAD no próximo tópico).

Para não saímos da linha de raciocínio vamos seguir com os processos já extraídos, lembrando que estou seguindo uma linha e se no meio do caminho perceber que se perdeu ou que nada, faz mais sentido, volte sua análise.

Usando malfind nos processos extraídos.

Aqui no primeiro processo já vemos que há uma possível injeção, também existe a permissão leitura, gravação e execução do processo, e temos exibição de alguns cabeçalhos e dados hexadecimais que causaram a necessidade de memória adicional.

Para não restar dúvida decidimos executar o malfind em mais um processo e escolhemos um daqueles que os HASHs eram iguais, e percebemos que o processo não foi injetado e isso nos ajuda a começar a entender em que momento ocorreu uma injeção de código.

Dica: Quando executamos o plugin do malfind sem especificar o PID precisamos ter cuidado em falsos positivos, como no processo MsMpEng.exe que se trata do mecanismo de defesa contra malware da Microsoft. Não vamos nos aprofundar aqui, mas é importante saber que precisamos correlacionar dados para uma definição mais assertiva.

VADs ou Endereço Virtual corresponde à memória virtual em seu espaço de endereço virtual, o VAD descritor de endereço virtual (em inglês: Virtual Address Descriptor) que em resumo é usado pelo gerenciador de memória do S.O para descrever intervalos de memória usados por um processo na medida em que são alocados, quando um processo aloca memória com VirtualAlloc, por exemplo, o gerenciador cria uma entrada no VAD, os VADs são compostos por informações como endereço de memória, intervalos de memória, proteção alocada e alguns sinalizadores do S.O.

Quando ocorre alguma alteração no VAD na maioria das vezes é por motivo de injeção no espaço de memória de um processo em execução, sendo assim podemos identificar alterações feitas nesses espaços de endereço de memória virtual.

Extrair strings de conexões

Primeiro vamos tentar extrair strings de conexões http/https (isso por termos encontrado a porta 80 nas conexões) no processo extraído de número 3908 até o momento nosso suspeito.

Vemos que não temos nada aqui, vamos seguir para extração dos endereços VADs do processo.

Para extrair os VADs de um processo use o plugin “Windows.vadinfo” com os parâmetros – -pid e – -dump, aqui direcionei a saída dos arquivos para um diretório chamado vads_3908, teremos vários arquivos .dmp.

Agora sim, achamos algo realizando a extração de strings, encontramos uma conexão bem suspeita e na porta 80, http, será que conseguimos alguma relação dessa URL com o IP em questão?

Sim, aqui vemos que o domínio está associado ao IP que encontramos com conexão estabelecida.

Aqui já conseguimos realizar extração de vários IOCs, saber um pouco sobre o comportamento do malware e conceito sobre injeção de processo.

Observação enquanto realizamos essa análise a URL já foi retirada do ar.

Vamos prosseguir com a análise e encontrar algum arquivo de persistência, aqueles que iniciam junto com o sistema ou tem uma tarefa agendada no sistema operacional.

Nesta primeira imagem vamos verificar o quanto devemos confiar apenas em ferramentas, e que mesmo o volatility sendo um dos melhores para análise de memória não podemos confiar totalmente.

Percebam que ao executar o plugin Windows.registry.printkey com o parâmetro – -key ele não trouxe todas as chaves com os arquivo .lnk conforme as próximas imagens, onde usei com expressão regular.

Usando o plugin registry.printkey com expressões regulares vemos que temos uma cadeia de informações maior, pois ele inclui algumas palavras que podem vim desconfiguradas (por exemplo: juntas) no comando padrão do volatility.

Separei em duas imagens a saída para um melhor entendimento.

Veja que na figura 24 temos dois arquivos winupdate.setup com extensão lnk (atalho), esses nomes suspeitos como vemos ocorre porque ferramentas e estruturas automatizadas, por exemplo a empire criam arquivos aleatórios na memória e um malware pode gerar esses processos na pós-exploração como ao instalar serviços ou criar backdoor.

Vamos verificar a localização do arquivo em disco para uma possível extração procurando nas chaves de registro, porém, não obtive sucesso usando o volatility, o arquivo com o final 241 não estava mais em disco, sendo assim prosseguir com o arquivo final 217.

Logo decidimos usar o foremost para extrair todos os arquivos lnk da memória, calma que voltaremos ao volatility.

Dica: Arquivos localizados nessa pasta startup do windows e na chave de registro acima são iniciados junto ao sistema, e não necessariamente é encontrado nos dois locais como visto aqui.

Criando o arquivo de configuração, se não quiser criar seu próprio arquivo utilize o arquivo padrão, aqui usei um arquivo criado por nós para extração, basta retirar o # para linha com informação do arquivo que pretende extrair, usamos o cabeçalho de arquivos lnk conforme linha em laranja.

Executando o foremost no arquivo de memória com o arquivo de configuração que criamos e direcionando a saída para o diretório “files_foremost”.

Será criado um diretório dentro da pasta files_foremost com o nome lnk acesse o diretório e terá vários arquivos .lnk, conforme figura 27.

Usamos o exiftool para verificar todos os arquivos para localizar um arquivo que possa levantar suspeita, peço que pesquisem sobre comandos lolbas, e puxando comandos via powershell que usam hidden (ocultar) encontramos o arquivo 00403296.lnk com um comando bem suspeito.

O amcache é um arquivo do S.O que podemos encontrar informações sobre programas que são ou foram executados. Entre as informações que podemos coletar são localização, valor da chave, metadados e hash em SHA1 do arquivo.

Sua localização é: C:\Windows\AppCompat\Programas\Amcache.hve

Pesquisando pelo caminho do diretório achamos o binário abaixo.

Um dos campos do amcache é o nome do long path podemos dizer que é um hash do caminho associado ao arquivo, ou seja é único para esse caminho e ele fica logo após do nome do arquivo aqui o no caso userinit.exe seguido de pipe e “e85e4d63a0a04f8e”.

Vamos realizar uma busca com ele para ter o resultado completo.

Antes perceba que o horário bate com a imagem 32, onde o arquivo Winupdate.setup9c36d30d0217.lnk foi registrado também no amcache, logo concluído que foi possível verificar o que tínhamos como execução nesse arquivo lnk.

Direto na chave de registro nosso FileID é o campo que temos o HASH em SHA1 lembre-se de retirar os zeros a esquerda, SHA1: 6742c7a8f91bc1ad06908767b1bb01302f457bd3, e o OriginalFileName: tracker.exe. Peço que verifique no Vírus Total e verá a confirmação do nome do arquivo.

E aqui temos a hora da criação do lnk, a mesma que o diretório e arquivo do suposto “userinit.exe” falso. Para arquivo lnk, o amcache não guarda última execução.

Ao pesquisar a linha de comando executado no arquivo lnk, nos deparamos com um comportamento já conhecido, que nos leva a um trojan bancário conhecido como Guildma.

Sobre o Autoit é uma linguagem projetada para automatizar a GUI do Windows e criar scripts, existem casos de uso para criação de artefato malicioso por atacantes, ressalto que o Autoit não tem ou é um artefato malicioso. Caso utilize o AutoIt3 da versão aqui encontrada em seu ambiente desconsidere o HASH da versão encontrada no tópico IOCs.