Hey guys… Vamos lá para mais uma análise… Se não a gente perde o ritmo novamente… haha…

Desta vez temos um sample para analisar… Recebi um phishing se passando pelo Ministério Público Federal com uma intimação bem engraçada… desta vez o cara não teve tanta sagacidade na construção do e-mail…

Veja o texto integral da intimação(vou postar em plain-text caso alguem use o tradutor):

—–

Intimacao de n. 7743872. O MINISTERIO PUBLICO FEDERAL, no desempenho de suas atribuicoes institucionais, com fundamento nos artigos 229 e 241, inciso VI da constituicao Federal e artigo 61 , inciso VII da lei complementar n, 676, de 28 de Maio de 1998, INTIMA Vossa Senhoria a comparecer nessa procuradoria Regional da Republica —

Data do comparecimento 16/01/2014 (Sexta feira) as 9:00 AM

—–

Mesmo sem conhecer as técnicas e funcionamento de um phishing, um usuário “sem dedo nervoso”, leria esta mensagem e independente dos artigos da lei(quem os pesquisaria só por que recebeu um e-mail?) iria ver que não há o local da procuradoria regional e a data para comparecer é 16 de janeiro de 2014.. hahaha.. 14.. O cara passou totalmente batido nessa… Isso é muito comum acontecer na época de mudança de ano com a maioria das pessoas… normalmente só se acostumam com o novo ano em fevereiro ou março… agora sei que a galera que cria phishing/malware também passa pelo mesmo problema ou será que isso foi algum template usado ano passado e o cara não atualizou?

A tela do e-mail:

O link para baixar o arquivo era: hxxp://www.georepp.com.br/site/images/Ministeiro.php

O Georepp é uma empresa de geologia, consultoria e construção de poços artesianos, que está atualmente com o site fora, provavelmente para manutenção(talvez devido a invasão relacionada ao phishing):

Destaques do cabeçalho são estas linhas que mostram a forma de envio do phishing:

Received: from 127.0.0.1  (EHLO s17333737.onlinehome-server.info) (82.165.171.231)
  by mta1236.mail.ne1.yahoo.com with SMTPS; Fri, 09 Jan 2015 00:20:17 +0000
Received: by s17333737.onlinehome-server.info (Postfix, from userid 10009)
	id 14C30AF7099A; Fri,  9 Jan 2015 01:20:10 +0100 (CET)
To: xxxxxx@yahoo.com.br
X-PHP-Originating-Script: 10009:meu.php

Verificamos pelo PEiD que o executável esta sem packer, e pelo RDG vimos que está sem packer no código:

Ao usarmos o ExeinfoPE vimos que trata-se de um AutoIt:

SHA1 deste AutoIT: 66f8073817ab9bf994096bdbb1ff884e45fa7de9

Usamos o Exe2Aut para extrair o sample que provavelmente também possui proteção de VM, pois não executou em meu ambiente. Quanto tentei executa-lo na VM recebi a seguinte mensagem:

Após ter acesso ao fonte do malware vi que isto estava relacionado à detecção de VM como visto abaixo. Antes da função de vm_detect havia um timer talvez para evasão de sandbox e logo após havia a função.

Timer:

Sleep(40000)

Detecção de VM:

Func _isvirtualmachine()
Local $owmiservice = ObjGet("winmgmts:\\localhost\root\cimv2")
Local $ocolitems = $owmiservice.execquery("Select * From Win32_ComputerSystemProduct", "WQL", 48)
If IsObj($ocolitems) Then
For $oobjectitem In $ocolitems
If StringRegExp($oobjectitem.name, "(?i)VirtualBox|VMWare|Virtual PC") Then
Return 1
EndIf
Next
EndIf
Return SetError(1, 0, 0)
EndFunc

If (_isvirtualmachine() = 1) Then
MsgBox(64, "Erro", "Não foi possível executar o aplicativo.")
Exit
EndIf

Removi tanto o timer quanto a detecção de vm e compilei novamente o script gerando um novo arquivo .exe e em seguida executei-o.

Abaixo segue o uso de SeDebugPrivilege em disco:

Func _winapi_openprocess($iaccess, $finherit, $iprocessid, $fdebugpriv = False)
Local $aresult = DllCall("kernel32.dll", "handle", "OpenProcess", "dword", $iaccess, "bool", $finherit, "dword", $iprocessid)
If @error Then Return SetError(@error, @extended, 0)
If $aresult[0] Then Return $aresult[0]
If NOT $fdebugpriv Then Return 0
Local $htoken = _security__openthreadtokenex(BitOR($token_adjust_privileges, $token_query))
If @error Then Return SetError(@error, @extended, 0)
_security__setprivilege($htoken, "SeDebugPrivilege", True)
Local $ierror = @error
Local $ilasterror = @extended
Local $iret = 0
If NOT @error Then
$aresult = DllCall("kernel32.dll", "handle", "OpenProcess", "dword", $iaccess, "bool", $finherit, "dword", $iprocessid)
$ierror = @error
$ilasterror = @extended
If $aresult[0] Then $iret = $aresult[0]
_security__setprivilege($htoken, "SeDebugPrivilege", False)
If @error Then
$ierror = @error
$ilasterror = @extended
EndIf
EndIf
_winapi_closehandle($htoken)
Return SetError($ierror, $ilasterror, $iret)
EndFunc

e em memória:

Func __mem_openprocess($iaccess, $finherit, $iprocessid, $fdebugpriv = False)
Local $aresult = DllCall("kernel32.dll", "handle", "OpenProcess", "dword", $iaccess, "bool", $finherit, "dword", $iprocessid)
If @error Then Return SetError(@error, @extended, 0)
If $aresult[0] Then Return $aresult[0]
If NOT $fdebugpriv Then Return 0
Local $htoken = _security__openthreadtokenex(BitOR($token_adjust_privileges, $token_query))
If @error Then Return SetError(@error, @extended, 0)
_security__setprivilege($htoken, "SeDebugPrivilege", True)
Local $ierror = @error
Local $ilasterror = @extended
Local $iret = 0
If NOT @error Then
$aresult = DllCall("kernel32.dll", "handle", "OpenProcess", "dword", $iaccess, "bool", $finherit, "dword", $iprocessid)
$ierror = @error
$ilasterror = @extended
If $aresult[0] Then $iret = $aresult[0]
_security__setprivilege($htoken, "SeDebugPrivilege", False)
If @error Then
$ierror = @error
$ilasterror = @extended
EndIf
EndIf
DllCall("kernel32.dll", "bool", "CloseHandle", "handle", $htoken)
Return SetError($ierror, $ilasterror, $iret)
EndFunc

O arquivo sem as proteções e com o escalonamento de privilégios, simplesmente age como loader, baixando e executando um novo arquivo:

O AutoIT se conecta ao IP 177.85.103.104 e faz o download de um arquivo data.jpg que é simplesmente o novo executável, como visto em mais detalhes no wireshark tanto pelo magic number quanto por algumas seções do PE:

SHA1 do sample baixado: 3a68ec8d95f9f1c0665fd3b419ca61ae56e7a35a

Após o download do novo arquivo, o mesmo é adicionado à inicialização do sistema e monitora o acesso da vitima a sites de banco. No exemplo abaixo vemos uma tentativa de conexão ao C&C:

assuero@malwar ~ $ host 187.79.5.147
147.5.79.187.in-addr.arpa domain name pointer 187-79-5-147.user.veloxzone.com.br.

Ao acessar algum site de banco, vemos diversos outros acessos simultâneos a este IP que o .exe “loadeado” está se conectando e pelo GeoIP vemos a origem:

…… Depois de quase dois meses ……

Cá estamos nós continuando o post, durante o Carnaval(quando eu tive tempo)…

Ao retomar a análise vi algumas coisas que mudaram… O AutoIT não consegue se conectar ao servidor para baixar o sample, porém ao executarmos o sample previamente baixado vi que o executável estabelece conexões com sucesso:

O mesmo sample esta se comunicando com um novo servidor C&C:

No início da conexão, são enviadas para o atacante informações do sistema local e uma senha(fucker0202#@), provavelmente para acesso do/no C&C:

Agora também podemos visualizar a checagem do C&C feita pelo malware e os avisos enviados ao acessar bancos(no teste abaixo acessei o Bradesco, Banco do Brasil e Itaú):

…… Um longo inverno depois, continuando ……

Abaixo vemos o RDG informando que o arquivo usa o Obsidium:

Porém o ExeinfoPE e o PEiD nos dão informações diferentes(pra variar, esses caras nunca falam a mesma coisa…):

Sabendo que se trata de um Delphi sem packer, antes de usar o DeDe, rodei o ResourceHacker para ver as imagens e seções do PE, porém as únicas imagens visíveis em Cursor e icon, estavam respectivamente relacionadas com cursor do mouse e o ícone do app. Em RCData haviam varias seções idênticas(e relacionadas com diversos bancos além do Bradesco… No caso abaixo ITAU),  porem não foi possível visualizar as imagens. Veja que o inicio da imagem em Picture.Data:

Para reconstruir esta imagem, provavelmente seria necessário criar um projeto em delphi…

Vamos pelo mais prático se o que queremos é visualizar as imagens basta abrir o DeDe carregar o arquivo e depois de visualizar os forms e tudo mais, exportar o projeto e abrir pelo delphi… Certo? Sim.. Certo… Mas não neste caso pois o DeDe não mostrou nem as imagens nem os forms, e quando exportei para o delphi, nada feito tb:

No Delphi, ao abrir o projeto:

Como recurso final antes de partir pra um editor hexa ou criar um projeto no delphi, resolvi testar o PE Explorer que funcionou. Agora que já estamos chegando ao fim desta analise, quem já leu até aqui, prepara o saco porque vai ter uma chuva de telas… e olha que só peguei uma tela de cada banco, pois haviam varias telas do mesmo banco e varias outras do mesmo banco porém outro segmento. Depois da telada, uma rápida reflexão sobre este phishing…

Banco do Brasil:

Bradesco:

Caixa Econômica:

HSBC:

ITAU:

Santander:

Estes últimos são mais raros, mas mesmo assim “os truta” não liberam…

SICOOB:

SICREDI:

Banrisul:

Existe possibilidade de conexão remota e monitoramento da vitima… Abaixo a parte de acesso remoto do sample:

Inicialmente o AutoIT detecta o IP local:

Func _getip()
Local $areturn, $bread, $sread
$bread = InetRead("http://checkip.dyndns.org/")
$sread = BinaryToString($bread)
$areturn = StringRegExp($sread, "(?s)(?i)Current IP Address: (.*?)", 3)
If @error = 0 Then
Return $areturn[0]
EndIf
$bread = InetRead("http://automation.whatismyip.com/n09230945.asp")
$sread = BinaryToString($bread)
If @error Then
Return SetError(1, 0, -1)
EndIf
Return $sread
EndFunc

Que é usado nas telas abaixo para conexão com o C&C:

No ResHacker vemos a senha coletada anteriormente no Wireshark:

Na tela abaixo vemos uma parte do código do botão  “conectar”:

 

E para finalizar minha simples reflexão:

Ataque bem mais “eficiente” que o phishing apenas via web sem download de sample.

Neste caso existe aviso ao atacante e conexão remota além das telas para “coleta” dos dados serem bem parecidas com as telas originais facilitando que até mesmo usuários com perfil mais um pouco mais avançado acabem caindo no golpe.

Também achei interessante a detecção de VM e o uso do SeDebugPrivilege para escalonar privilégios…

Mas o que fiquei mais impressionado é que devido correrias do dia-dia fiquei mais de 2 meses sem executar o sample e  após 2 meses.. sim isso mesmo, DOIS MESES o C&C ainda estava ativo recebendo comunicação das vitimas… Olhando no VT, muitos dos principais fabricantes já detectavam os samples como maliciosos, porém o C&C ainda estava ativo e quem tivesse o sample já ativo com AV desatualizado ou algo do tipo, fica vulnerável? Os fabricantes fazem o trabalho deles adicionando detecção aos samples e replicando essas assinaturas aos produtos de proteção de borda… Porém pensando no usuários final… O que falta para o CERT conseguir fazer takedowns mais rápido? Boa vontade ou a burocracia aqui é demais? Enfim, com essa situação só me lembro de uma imagem:

Link para download dos arquivos analisados(senha: malwar)