O segundo webinar contou com a palestra do Analista da Kaspersky Fabio Assolini que realizou uma excelente apresentação sobre utilização de proxies maliciosos por malwares brasileiros para o roubo de informações.
Nela ele contou um pouco da história da evolução do uso por parte dos atacantes e técnicas utilizadas .
Após a apresentação ele respondeu inúmeras questões.
Quem não assistiu vale a pena e quem viu provavelmente assistira novamente (1h10min)!
https://trustwave.webex.com/trustwave-pt/lsr.php?AT=pb&SP=MC&rID=60315972&rKey=4069486ea128ec19
Links:
http://www.twitter.com/assolini
http://brazil.kaspersky.com/
http://www.trustwave.com/spiderlabs
http://www.snort.org.br
Até o próximo!
Equipe Malwares-BR
sexta-feira, 15 de julho de 2011
segunda-feira, 11 de julho de 2011
Local Threats - Fighting malicious proxies com Fabio Assolini
Caros,
Nesta próxima quinta-feira dia 14/07 teremos mais uma edição do Local Threats e quem falara será Fábio Assolini da Kaspersky .
O assunto dessa edição sera Fighting malicious proxies.
Nessa palestra ele comentará sobre os ataques de MitB com os .pac que estao usando nas infecções dos malwares brasileiros.
Para se inscrever:
Data: Quinta-feira, 14 de Julho de 2011
Hora: 15:30, Horário Padrão da América do Sul - Leste (Brasília, GMT-03:00)
-----------------------------------------------------
Para se registrar nesta reunião
-----------------------------------------------------
1. Vá para https://trustwave.webex.com/trustwave-pt/j.php?ED=152521652&RG=1&UID=0&RT=MjQjMTY%3D
2. Registre-se na reunião.
Depois que o organizador aprovar sua solicitação, você receberá um e-mail de confirmação com instruções para se associar à reunião.
-----------------------------------------------------
Para se registrar nesta reunião
-----------------------------------------------------
1. Vá para https://trustwave.webex.com/trustwave-pt/j.php?ED=152521652&RG=1&UID=0&RT=MjQjMTY%3D
2. Registre-se na reunião.
Depois que o organizador aprovar sua solicitação, você receberá um e-mail de confirmação com instruções para se associar à reunião.
Esperamos voces por lá!
Malwares-BR
segunda-feira, 27 de junho de 2011
Slides Local Threats Edição Inicial
Caros,
Primeiramente agradecer ao apoio e participação do pessoal na edição inicial. Em breve enviarei alguns assuntos que abordamos bem como o convite para o próximo bate-papo e assunto.
Slides para quem interessar: http://snort.org.br/LocalThreats/LocalThreats-Ed1.pdf
No caso algumas perguntas que seria interessante responderem nos comentários:
1-) Horário foi bom ou preferem fora do horario comercial ?
2-) Algo quinzenal ou preferem mensal ?
3-) Tem alguma pauta/sugestão para os próximos ?
Obrigado!
Rodrigo Montoro
Primeiramente agradecer ao apoio e participação do pessoal na edição inicial. Em breve enviarei alguns assuntos que abordamos bem como o convite para o próximo bate-papo e assunto.
Slides para quem interessar: http://snort.org.br/LocalThreats/LocalThreats-Ed1.pdf
No caso algumas perguntas que seria interessante responderem nos comentários:
1-) Horário foi bom ou preferem fora do horario comercial ?
2-) Algo quinzenal ou preferem mensal ?
3-) Tem alguma pauta/sugestão para os próximos ?
Obrigado!
Rodrigo Montoro
sexta-feira, 10 de junho de 2011
Local Threats - O webinar de ameaças brasileiras ( Edição Inicial )
A idéia do webinar será um bate papo quinzenal do grupo Snort-BR e Malwares-BR apoiado pela Trustwave via Webex sendo o mesmo aberto ao público no geral sendo necessário a inscrição antecipada no link que será publicado em listas e sites. O evento terá como coordenador Rodrigo Montoro (Sp0oKeR) mas não necessariamente ele que estará palestrando/batendo papo virtual sempre. Teremos convidados de outras empresas que se encaixem nas pautas e assuntos tratados e logicamente sempre em português . O grande foco também é falar sobre malwares e tendências para América Latina em especial Brasil e possiveis/correspondente proteções/mitigações .
Assuntos:
- Malwares Regionais
- Brasil
- America Latina no geral
- Analise de artefatos
- Tendências
- O que está acontecendo (análises baseadas nos quinze dias entre os webinars)
- Proteções
- Anti Malwares
- Sistemas de Deteção de Intrusos
- Filtros de Conteúdo
- Analise Comportamental (Correlacionamentos)
Público Alvo:
- Estudantes
- Profissionais de Segurança
- Administradores de Rede
- Interessados no assunto
Como participar ?
Tópico: Local Threats - O webinar de ameaças brasileiras ( Edição Inicial )
Data: Terça-feira, 21 de Junho de 2011
Hora: 15:30, América do Sul Oriental Padrão Hora (Brasília, GMT-03:00)
-----------------------------------------------------
Para se registrar nesta reunião
-----------------------------------------------------
1. Vá para https://trustwave.webex.com/trustwave-pt/j.php?ED=151280752&RG=1&UID=0&RT=MjQjMTY%3D
2. Registre-se na reunião.
Depois que o organizador aprovar sua solicitação, você receberá um e-mail de confirmação com instruções para se associar à reunião.
Data: Terça-feira, 21 de Junho de 2011
Hora: 15:30, América do Sul Oriental Padrão Hora (Brasília, GMT-03:00)
-----------------------------------------------------
Para se registrar nesta reunião
-----------------------------------------------------
1. Vá para https://trustwave.webex.com/trustwave-pt/j.php?ED=151280752&RG=1&UID=0&RT=MjQjMTY%3D
2. Registre-se na reunião.
Depois que o organizador aprovar sua solicitação, você receberá um e-mail de confirmação com instruções para se associar à reunião.
Esperamos vocês lá!
segunda-feira, 8 de novembro de 2010
Another look at bradesco3.exe part3
Introdução
O objetivo desta última parte na análise com o bradesco3.exe é olhar o código, como agora o malware foi "descompactado" é possível verificar o código de uma forma mais fácil. Verificando o código do malware é a melhor forma de ter certeza que a regra criada para detectá-lo foi realmente bem escrita, pois, dependendo do ambiente em que o malware está sendo executado pode não estar executando certas ações. Como este malware é relativamente simples, o que interessa nessa análise de código é descobrir se de alguma forma a URL é randômica ou estática, para que possamos possivelmente melhorar ou encontrar alguma falha na regra do snort criada para detectar a atividade de rede deste malware como mostrado neste post.
Analisando o código
Embora o mais comum seja utilizar um disassembler como o IDAPro, o OllyDBG me serviu para analisar este simples malware, além do que utilizei mais debugging do que realmente ler o código por completo. Além disso, optei por não utilizar um disassembler para Delphi.
Logo no inicio, endereco 0x00472874, vi uma string que já valeu o trabalho fazer o unpack do arquivo:
Deve ser algum stilo Restart de programar. Não faz sentido algom o uso desta string "EUATETEAMEIMASVOCENAOVALENADAMESMO".
Indo ao que interessa (URL), olhando as strings disponíveis após "descompactar" o malware, percebi que a URL e os parâmetros não estão em texto puro, provavelmente sendo gerados na execução. Entretanto, encontrei a string "http" em 0x0046F5B0 e colocando um breakpoint neste endereço percebi que a stack já tinha todos os parâmetros da URL.
00DEFF44 |00B096B8 ASCII "http://www.shanhaiichiba.com/banner_inc.php"
00DEFF48 |00B425B8 ASCII "PAL"
00DEFF4C |00B3AC08 ASCII "A6CECFCDC5BD"
00DEFF50 |00B09778 ASCII "&NOME="
00DEFF54 |00B493D8 ASCII "PWD"
00DEFF58 |00B3A828 ASCII "C4C1C4CFD3BD"
00DEFF5C |00B09738 ASCII "DADOS="
00DEFF64 |00B28358 ASCII "T=C&DADOS=PWD&NOME=PAL"
Portanto, em alguma função acima do endereço 0x0046F5B0, foi extraído a URL e os parâmetros, se observarmos "DADOS=" e "C4C1C4CFD3BD", 'D' = "C4", assim como 'A' = "C1" e 'O' = "CF", pois em "&NOME=" e "A6CECFCDC5BD" "CF" está na terceira posição assim como a letra "O".
Provavelmente, estes dois utilizam as mesmas funções para extrair os parâmetros da URL. O início da função onde está 0x46F5B0 é o 0x0046F524 e colocando um breakpoint neste endereço, notei que esta função é chamada por 0x0046F721 e 0x0046F88E.
Ao verificar a função onde se encontra 0x0046F721 e percorrer a mesma a partir do início 0x0046F67C, notei que esta é a função responsável por extrair os parâmetros da URL:
"T=C&" hard-coded em:
0046F6AC PUSH bradesco.0046F7D8 ; ASCII "T=C&"
0046F6B9 CALL bradesco.0040658C
Retorno: EAX=00B3A828 ASCII "C4C1C4CFD3BD"
0046F6C4 CALL bradesco.0046DF34
Retorno: 00B09738 ASCII "DADOS="
0046F6CF MOV EAX,DWORD PTR DS:[EBX+48]
0x00B41D38 fixo "PWD"
0046F6D2 CALL bradesco.0046F1C4
Retorno: EBP-18 ASCII "PWD"
0046F6E2 CALL bradesco.0040658C
Retorno: 00B3AC08 ASCII "A6CECFCDC5BD"
0046F6ED CALL bradesco.0046DF34
Retorno: 00B09778 ASCII "&NOME="
0046F6FACALL bradesco.0046F988
Retorno: 00B425B8 ASCII "PAL"
0046F70A CALL bradesco.00404CCC
Retorno: 00B28358 ASCII "T=C&DADOS=PWD&NOME=PAL"
0046F712 MOV EAX,DWORD PTR DS:[4748FC]
DS:[004748FC]=0046F454
0046F454: ASCII "E8F4F4F0BAAFAFF7F7F7AEF3E8E1EEE8E1E9E9E3E8E9E2E1AEE3EFEDAFE2E1EEEEE5F2DFE9EEE3AEF0E8F0" 0046F717 CALL bradesco.0046DF34
Resultado: 00B096B8 ASCII "http://www.shanhaiichiba.com/banner_inc.php"
Embora a URL não esteja disponível em texto puro, ela não se modifica, hard-coded em 0x0046F454. Na função 0x0046F988, é utilizada a função GetComputerNameA para obter o hostname:
0046F9AC CALL 'JMP.&kernel32.GetComputerNameA ; \GetComputerNameA
Ajustando a regra
A atual regra para este malware é a seguinte:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Bradesco Malware Communication Detected (plugin.exe)"; flow:established; uricontent:"&DADOS=";http_client_body;content:"&NOME=";http_client_body; sid:100000000;rev:1; )
Basicamente, checamos a URI por &DADOS= e &NOME=. Porém, é possível que outras aplicações utilizem &NOME= e &DADOS= na URL, e conforme análise acima podemos também confirmar que a URL em sí e T=C& são fixos, o ideal da URL é adicionar na blacklist de um proxy, portanto apenas adicionando T=C& na regra pode ajudar a diminuir os possívels falsos-positivos.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Bradesco Malware Communication Detected (plugin.exe)"; flow:established; uricontent:"T=C&DADOS=PWD&NOME=";http_client_body; sid:100000000;rev:1; )
Conclusão
Na prática, dificilmente um malware como este levaria a esta análise, porém serviu apenas para demonstrar a importância de verificar o código, pois, embora não tenha detectado alguma atividade diferente da já analisada, foi possível atualizar a regra, diminuindo possíveis falsos positivos.
O objetivo desta última parte na análise com o bradesco3.exe é olhar o código, como agora o malware foi "descompactado" é possível verificar o código de uma forma mais fácil. Verificando o código do malware é a melhor forma de ter certeza que a regra criada para detectá-lo foi realmente bem escrita, pois, dependendo do ambiente em que o malware está sendo executado pode não estar executando certas ações. Como este malware é relativamente simples, o que interessa nessa análise de código é descobrir se de alguma forma a URL é randômica ou estática, para que possamos possivelmente melhorar ou encontrar alguma falha na regra do snort criada para detectar a atividade de rede deste malware como mostrado neste post.
Analisando o código
Embora o mais comum seja utilizar um disassembler como o IDAPro, o OllyDBG me serviu para analisar este simples malware, além do que utilizei mais debugging do que realmente ler o código por completo. Além disso, optei por não utilizar um disassembler para Delphi.
Logo no inicio, endereco 0x00472874, vi uma string que já valeu o trabalho fazer o unpack do arquivo:
Deve ser algum stilo Restart de programar. Não faz sentido algom o uso desta string "EUATETEAMEIMASVOCENAOVALENADAMESMO".
Indo ao que interessa (URL), olhando as strings disponíveis após "descompactar" o malware, percebi que a URL e os parâmetros não estão em texto puro, provavelmente sendo gerados na execução. Entretanto, encontrei a string "http" em 0x0046F5B0 e colocando um breakpoint neste endereço percebi que a stack já tinha todos os parâmetros da URL.
00DEFF44 |00B096B8 ASCII "http://www.shanhaiichiba.com/banner_inc.php"
00DEFF48 |00B425B8 ASCII "PAL"
00DEFF4C |00B3AC08 ASCII "A6CECFCDC5BD"
00DEFF50 |00B09778 ASCII "&NOME="
00DEFF54 |00B493D8 ASCII "PWD"
00DEFF58 |00B3A828 ASCII "C4C1C4CFD3BD"
00DEFF5C |00B09738 ASCII "DADOS="
00DEFF64 |00B28358 ASCII "T=C&DADOS=PWD&NOME=PAL"
Portanto, em alguma função acima do endereço 0x0046F5B0, foi extraído a URL e os parâmetros, se observarmos "DADOS=" e "C4C1C4CFD3BD", 'D' = "C4", assim como 'A' = "C1" e 'O' = "CF", pois em "&NOME=" e "A6CECFCDC5BD" "CF" está na terceira posição assim como a letra "O".
Provavelmente, estes dois utilizam as mesmas funções para extrair os parâmetros da URL. O início da função onde está 0x46F5B0 é o 0x0046F524 e colocando um breakpoint neste endereço, notei que esta função é chamada por 0x0046F721 e 0x0046F88E.
Ao verificar a função onde se encontra 0x0046F721 e percorrer a mesma a partir do início 0x0046F67C, notei que esta é a função responsável por extrair os parâmetros da URL:
"T=C&" hard-coded em:
0046F6AC PUSH bradesco.0046F7D8 ; ASCII "T=C&"
0046F6B9 CALL bradesco.0040658C
Retorno: EAX=00B3A828 ASCII "C4C1C4CFD3BD"
0046F6C4 CALL bradesco.0046DF34
Retorno: 00B09738 ASCII "DADOS="
0046F6CF MOV EAX,DWORD PTR DS:[EBX+48]
0x00B41D38 fixo "PWD"
0046F6D2 CALL bradesco.0046F1C4
Retorno: EBP-18 ASCII "PWD"
0046F6E2 CALL bradesco.0040658C
Retorno: 00B3AC08 ASCII "A6CECFCDC5BD"
0046F6ED CALL bradesco.0046DF34
Retorno: 00B09778 ASCII "&NOME="
0046F6FACALL bradesco.0046F988
Retorno: 00B425B8 ASCII "PAL"
0046F70A CALL bradesco.00404CCC
Retorno: 00B28358 ASCII "T=C&DADOS=PWD&NOME=PAL"
0046F712 MOV EAX,DWORD PTR DS:[4748FC]
DS:[004748FC]=0046F454
0046F454: ASCII "E8F4F4F0BAAFAFF7F7F7AEF3E8E1EEE8E1E9E9E3E8E9E2E1AEE3EFEDAFE2E1EEEEE5F2DFE9EEE3AEF0E8F0" 0046F717 CALL bradesco.0046DF34
Resultado: 00B096B8 ASCII "http://www.shanhaiichiba.com/banner_inc.php"
Embora a URL não esteja disponível em texto puro, ela não se modifica, hard-coded em 0x0046F454. Na função 0x0046F988, é utilizada a função GetComputerNameA para obter o hostname:
0046F9AC CALL 'JMP.&kernel32.GetComputerNameA ; \GetComputerNameA
Ajustando a regra
A atual regra para este malware é a seguinte:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Bradesco Malware Communication Detected (plugin.exe)"; flow:established; uricontent:"&DADOS=";http_client_body;content:"&NOME=";http_client_body; sid:100000000;rev:1; )
Basicamente, checamos a URI por &DADOS= e &NOME=. Porém, é possível que outras aplicações utilizem &NOME= e &DADOS= na URL, e conforme análise acima podemos também confirmar que a URL em sí e T=C& são fixos, o ideal da URL é adicionar na blacklist de um proxy, portanto apenas adicionando T=C& na regra pode ajudar a diminuir os possívels falsos-positivos.
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Bradesco Malware Communication Detected (plugin.exe)"; flow:established; uricontent:"T=C&DADOS=PWD&NOME=";http_client_body; sid:100000000;rev:1; )
Conclusão
Na prática, dificilmente um malware como este levaria a esta análise, porém serviu apenas para demonstrar a importância de verificar o código, pois, embora não tenha detectado alguma atividade diferente da já analisada, foi possível atualizar a regra, diminuindo possíveis falsos positivos.
sábado, 16 de outubro de 2010
Another look at bradesco3.exe part2
Introdução
In my last post I analyzed bradesco3.exe focused on screen captures and the trojan functionality, on this post I will describe how to unpack this sample, actually how to manually unpack PECompact.
By decision of malwares-br group (4.5 vs 1.5), this post is in Portuguese (pt_BR). I don't see any issue since unpack PECompact tutorials are available in English. In any way, if you have any doubts, do not hesitate to contact me.
Como já brincamos com o trojan no último post e o Rodrigo também já submeteu o trojan para análise comportamental ao anubis, resta agora fazer a análise do código. Embora após executar o trojan várias vezes, tivemos o mesmo resultado (mesma URL e parâmetros), é interessante análisar o código para confirmar que a URL não é modificada, ou qualquer outra informação como descobrir o autor ou até mesmo para se divertir.
Este post está dividido em cinco partes:
1) Identificando Packer
2) Encontrando OEP
3) Dump do processo e recuperando IAT
4) Resultados do VirusTotal
5) Conclusões
Identificando Packer
Antes de iniciar a análise de código eu costumo verificar o md5hash do arquivo, verificar se existe alguma string disponível interessante e analisar o mesmo com o o PEiD.
Para analisar as strings, utilizei o BinText e a mensagem inicial já indica que o arquivo pode estar compactado.
No início das strings é possível identificar as strings "PEC2" e "PECompact2", provavelmente este arquivo foi compacto com o packer PECompact versão 2. Além destas, nenhuma outra string interessante, somente as DLLs e funções utilizadas pelo trojan.
O melhor "identificador" de arquivos PE que conheço é o PEiD, ele consegue detectar vários packers e linguagens de programação. Portanto, para melhorar a tese de que este arquivo foi compactado com o PECompact, utilizei o PEiD. Note que pode acontecer do autor inserir algumas strings que aparentemente sejam de algum packer e na verdade não são. Por exemplo, neste caso caso o PEiD identifique o arquivo como sendo compactado pelo PECompact a partir das strings "PEC2" e "PECompact2", o autor poderia inserir essas strings somente para dificultar a análise, fazendo com o que o analista acredite que o arquivo foi compactado com o PECompact onde na verdade não foi. Isso pode dificultar ferramentas automatizadas de unpacking.
Já sabemos que o arquivo está provavelmente compactado com o PECompact, então agora é hora de análisar o código e possivelmente descompactar o mesmo. Para isso, irei utilizar o OllyDBG.
Encontrando o OEP
Basicamente, descompactar ou "desempacotar" o arquivo consiste em encontrar o OEP (Original Entry Point) do programa, ou seja, o início do programa. Note que a primeira instrução salva o endereço 0x00525c48 no EAX.
Verificando este endereço foi possível notar um "JMP EAX" um pouco abaixo, no endereço 0x00525D0A.
Por quê o interesse pelo "JMP EAX"? Em alguns packers, e é o caso do PECompact, eles salvam o OEP no EAX e quando terminam de descompactar o arquivo, retornam para o OEP para que o programa seja executado normalmente. Portanto, conseguindo acessar o "JMP EAX", provavelmente consigamos acessar o OEP e descompactar (ou fazer um "dump") do arquivo. Portanto, o objetivo é colocar um breakpoint no endereço 0x00525D0A para que possamos
acessar o OEP.
Entretando, como este endereço está fora da seção de códigos (> 0x00521000) então é necessário um hardware breakpoint. Embora o hardware breakpoint possa funcionar para o que queremos que é acessar o OEP, quando fazemos o JMP para o EAX o código ainda não fica legível, mesmo após o Ctrl+A (Analyse code).
Então, uma maneira mais "elegante" é provocar um loop infinito no programa, adicionar o processo em execução ao debugger e alterar a instrução do loop infinito para "JMP EAX" e aí sim acessar o OEP. Para isso, basta alterar 0x00525D0A de "JMP EAX" para "EB FE" ou "JMP 0x00525D0A, "EB FE" é o opcode para JMP $EIP, executar um JMP no atual endereço do EIP, ou seja, do atual endereço de memória, causando um loop infinito.
Após salvar a alteração em um outro arquivo "bradesco3_novo.exe" e executá-lo, é necessário anexar o processo ao Olly
Após anexar o processo, executar (F9) e pausar (F12), irá para no endereço 0x00525D0A.
Alterar para "JMP EAX", basta pressionar a tecla de espaço para fazer a alteração.
E então executar a instrução via F7.
Finalmente chegamos ao OEP, note que as primeiras instruções "PUSH EBP; MOV EBP, ESP" são comumente utilizadas no início do programa ou de qualquer função para salvar o endereço de retorno, portanto este é provavelmente o início "real" do programa.
Dump do processo e recuperando IAT
Agora é necessário fazer o dump do processo, para isso vou utilizar o OllyDump, plugin para o OllyDBG. Das opções padrões, retire a opção "Rebuild Import", por alguma razão essa opção nem sempre funciona e é necessário importar as DLLs manualmente.
Salvei o novo arquivo como "bradesco3_novo_dumped.exe", observe que ele não é executável pois está faltando as DLLs.
Para importar as DLLs, ou recuperar a IAT (Import Address Table) vamos utilizar o ImpREC, porém é necessário descobrir algumas informações que faltam via Olly:
RVA (Relative Virtual Address) - primeiro endereço de memória da IAT
Size - tamanho da IAT, ou seja, (último endereço+0x04) - (primeiro endereço) = size
OEP - já descobrimos 0x00472864
Ainda no Olly, com o "bradesco3_novo.exe", procurar por "FF 25" (Ctrl+B) ou "JMP DWORD PTR DS:" comumente utilizado quando é necessário acessar uma função de uma DLL, a partir daí é possível procurar na memória os endereços da IAT. Basta selecionar a instrução e seguir a instrução do dump de memória (Follow in Dump -> Memory Address).
Na verdade o útimo endereço de memória da tabela é o 0x47AE3C mas como temos que calcular o tamanho, teriamos que adicionar +0x04, ou seja, 0x47AE3C + 0x04 = 0x47AE40. Então, o tamanho da tabela é 0x0047AE3C - 0x0047A140 = CFC. Agora basta utilizar o ImpREC para salvar a IAT no arquivo "bradesco3_novo_dumped.exe".
Clicar em "Fix Dump" e selecionar o arquivo bradesco3_novo_dumped.exe, o novo arquivo com o IAT e pronto para ser executado será salvo com o nome do arquivo "+ _", neste caso "bradesco3_novo_dumped_.exe".
Resultados do VirusTotal
O arquivo descompactado é consideravelmente bem maior que o compactado.
O arquivo descompactado tem menor detecção do que o compactado 8/43, enquanto o compactado atualmente possui 24/42.
Conclusão
Embora o malware esteja compactado, o mesmo foi compactado com um packer conhecido o que não dificultou descompactar o mesmo. É interessante verificar que o arquivo descompactado tenha menor detecção por parte dos softwares de antí-virus, mesmo que alguns deles provavelmente possuem programas automáticos para descompactar arquivos, o hash ou característica dos mesmos não foram adicionado a base de assinaturas.
No próximo e último post sobre o "bradesco3.exe" irei finalmente analisá-lo.
Obrigado pela sua atenção.
Pedro Drimel Neto.
In my last post I analyzed bradesco3.exe focused on screen captures and the trojan functionality, on this post I will describe how to unpack this sample, actually how to manually unpack PECompact.
By decision of malwares-br group (4.5 vs 1.5), this post is in Portuguese (pt_BR). I don't see any issue since unpack PECompact tutorials are available in English. In any way, if you have any doubts, do not hesitate to contact me.
Como já brincamos com o trojan no último post e o Rodrigo também já submeteu o trojan para análise comportamental ao anubis, resta agora fazer a análise do código. Embora após executar o trojan várias vezes, tivemos o mesmo resultado (mesma URL e parâmetros), é interessante análisar o código para confirmar que a URL não é modificada, ou qualquer outra informação como descobrir o autor ou até mesmo para se divertir.
Este post está dividido em cinco partes:
1) Identificando Packer
2) Encontrando OEP
3) Dump do processo e recuperando IAT
4) Resultados do VirusTotal
5) Conclusões
Identificando Packer
Antes de iniciar a análise de código eu costumo verificar o md5hash do arquivo, verificar se existe alguma string disponível interessante e analisar o mesmo com o o PEiD.
Para analisar as strings, utilizei o BinText e a mensagem inicial já indica que o arquivo pode estar compactado.
No início das strings é possível identificar as strings "PEC2" e "PECompact2", provavelmente este arquivo foi compacto com o packer PECompact versão 2. Além destas, nenhuma outra string interessante, somente as DLLs e funções utilizadas pelo trojan.
O melhor "identificador" de arquivos PE que conheço é o PEiD, ele consegue detectar vários packers e linguagens de programação. Portanto, para melhorar a tese de que este arquivo foi compactado com o PECompact, utilizei o PEiD. Note que pode acontecer do autor inserir algumas strings que aparentemente sejam de algum packer e na verdade não são. Por exemplo, neste caso caso o PEiD identifique o arquivo como sendo compactado pelo PECompact a partir das strings "PEC2" e "PECompact2", o autor poderia inserir essas strings somente para dificultar a análise, fazendo com o que o analista acredite que o arquivo foi compactado com o PECompact onde na verdade não foi. Isso pode dificultar ferramentas automatizadas de unpacking.
Já sabemos que o arquivo está provavelmente compactado com o PECompact, então agora é hora de análisar o código e possivelmente descompactar o mesmo. Para isso, irei utilizar o OllyDBG.
Encontrando o OEP
Basicamente, descompactar ou "desempacotar" o arquivo consiste em encontrar o OEP (Original Entry Point) do programa, ou seja, o início do programa. Note que a primeira instrução salva o endereço 0x00525c48 no EAX.
Verificando este endereço foi possível notar um "JMP EAX" um pouco abaixo, no endereço 0x00525D0A.
Por quê o interesse pelo "JMP EAX"? Em alguns packers, e é o caso do PECompact, eles salvam o OEP no EAX e quando terminam de descompactar o arquivo, retornam para o OEP para que o programa seja executado normalmente. Portanto, conseguindo acessar o "JMP EAX", provavelmente consigamos acessar o OEP e descompactar (ou fazer um "dump") do arquivo. Portanto, o objetivo é colocar um breakpoint no endereço 0x00525D0A para que possamos
acessar o OEP.
Entretando, como este endereço está fora da seção de códigos (> 0x00521000) então é necessário um hardware breakpoint. Embora o hardware breakpoint possa funcionar para o que queremos que é acessar o OEP, quando fazemos o JMP para o EAX o código ainda não fica legível, mesmo após o Ctrl+A (Analyse code).
Então, uma maneira mais "elegante" é provocar um loop infinito no programa, adicionar o processo em execução ao debugger e alterar a instrução do loop infinito para "JMP EAX" e aí sim acessar o OEP. Para isso, basta alterar 0x00525D0A de "JMP EAX" para "EB FE" ou "JMP 0x00525D0A, "EB FE" é o opcode para JMP $EIP, executar um JMP no atual endereço do EIP, ou seja, do atual endereço de memória, causando um loop infinito.
Após salvar a alteração em um outro arquivo "bradesco3_novo.exe" e executá-lo, é necessário anexar o processo ao Olly
Após anexar o processo, executar (F9) e pausar (F12), irá para no endereço 0x00525D0A.
Alterar para "JMP EAX", basta pressionar a tecla de espaço para fazer a alteração.
E então executar a instrução via F7.
Finalmente chegamos ao OEP, note que as primeiras instruções "PUSH EBP; MOV EBP, ESP" são comumente utilizadas no início do programa ou de qualquer função para salvar o endereço de retorno, portanto este é provavelmente o início "real" do programa.
Dump do processo e recuperando IAT
Agora é necessário fazer o dump do processo, para isso vou utilizar o OllyDump, plugin para o OllyDBG. Das opções padrões, retire a opção "Rebuild Import", por alguma razão essa opção nem sempre funciona e é necessário importar as DLLs manualmente.
Salvei o novo arquivo como "bradesco3_novo_dumped.exe", observe que ele não é executável pois está faltando as DLLs.
Para importar as DLLs, ou recuperar a IAT (Import Address Table) vamos utilizar o ImpREC, porém é necessário descobrir algumas informações que faltam via Olly:
RVA (Relative Virtual Address) - primeiro endereço de memória da IAT
Size - tamanho da IAT, ou seja, (último endereço+0x04) - (primeiro endereço) = size
OEP - já descobrimos 0x00472864
Ainda no Olly, com o "bradesco3_novo.exe", procurar por "FF 25" (Ctrl+B) ou "JMP DWORD PTR DS:" comumente utilizado quando é necessário acessar uma função de uma DLL, a partir daí é possível procurar na memória os endereços da IAT. Basta selecionar a instrução e seguir a instrução do dump de memória (Follow in Dump -> Memory Address).
Na verdade o útimo endereço de memória da tabela é o 0x47AE3C mas como temos que calcular o tamanho, teriamos que adicionar +0x04, ou seja, 0x47AE3C + 0x04 = 0x47AE40. Então, o tamanho da tabela é 0x0047AE3C - 0x0047A140 = CFC. Agora basta utilizar o ImpREC para salvar a IAT no arquivo "bradesco3_novo_dumped.exe".
Clicar em "Fix Dump" e selecionar o arquivo bradesco3_novo_dumped.exe, o novo arquivo com o IAT e pronto para ser executado será salvo com o nome do arquivo "+ _", neste caso "bradesco3_novo_dumped_.exe".
Resultados do VirusTotal
O arquivo descompactado é consideravelmente bem maior que o compactado.
O arquivo descompactado tem menor detecção do que o compactado 8/43, enquanto o compactado atualmente possui 24/42.
Conclusão
Embora o malware esteja compactado, o mesmo foi compactado com um packer conhecido o que não dificultou descompactar o mesmo. É interessante verificar que o arquivo descompactado tenha menor detecção por parte dos softwares de antí-virus, mesmo que alguns deles provavelmente possuem programas automáticos para descompactar arquivos, o hash ou característica dos mesmos não foram adicionado a base de assinaturas.
No próximo e último post sobre o "bradesco3.exe" irei finalmente analisá-lo.
Obrigado pela sua atenção.
Pedro Drimel Neto.
segunda-feira, 11 de outubro de 2010
Another look at bradesco3.exe part1
I am writing in English so it's easier to share with friends around the globe. Also, I do not expect this blog being visited by Brazilian end-users.
Introduction
On this part1 I will analyze the same sample of the last post within a different point of view, focused on the malware analyze without looking at the code, with some screenshots and some thoughts on the remote host compromise.
In the next posts, I will unpack the malware, compare VT results packed vs unpacked and later analyze the code, figuring out how the malware load the target URL.
So, this post may be interested for only whoever never saw a Brazilian banker.
The sample itself
I won't run through the behavioral analysis (file system, registry access, etc), for that you can take a look at the previous post here. Also, most of the Brazilian bankers (if not all) don't use to be persistent or advanced, like adding itself to registry, perform API hooking, process injection, etc. Most of them are simple applications developed under higher-level languages such as Delphi and Visual Basic and sometimes packed with known packers, I haven't seen yet a Brazilian banker packed by a custom packer. Please, let me know if you have one of those, I would love to have a look.
The design looks good, it says "Atualização de Segurança" which means "Security update". Basically, the attacker is trying to get bank information from the victim providing him a security update, something like you need to provide your bank password in order to be secure, you would not do that but someone will, for sure. In my point of view, there are only two mistakes by the author, the hyperlinks are not working and "Modulo de Seguraça" should be "Módulo de Segurança" which means "Security Module", classic typo, not a big deal, my mom would not even notice that.
Then you just need to choose your account type: "Bradesco - Pessoa Física" or "Bradeco - Prime", I don't know why that since for both you need to provide the same information. Once you choose your account type a message is displayed saying the information exchange will only be available for you and the bank. This is a default behavior for bankers, repeat a couple of times you are secure, I have never saw that amount of messages from my real bank.
Once you type agency and account, a virtual keyboard is displayed, like in real the bank website, it's fairly the same. The application does not even let you type the password if you don't do through the virtual keyboard.
Once you click on "Enviar" which means "Send", another message is displayed saying that your new security card will be sent to your address and then ask if you already received it or not.
What the hell is a "security card"?
On this bank, the second authentication method use a card which the bank calls "security card", they do not use tokens like other banks, so basically if you want to transfer money online you also need to provide the number of position "x" in your security card.
Once you click "Yes" or "No" another message is displayed saying that the security card improves your online transactions and that you should "re-sign" the current one, which means in theory that you need to provide all of the security card position numbers in order to keep the current one.
Then, finally, after you type all the security card numbers and click "Enviar" a HTTP POST is sent to www.shanhaiichiba.com with your data. The author fails again do not mentioning REF stays in the front of the card, they don't even need REF in order to steal money, perhaps it's something additional to pretend being a valid application.
The HTTP Post is the following:
T=P&DADOS=TIPO+......:+Bradesco+-+Pessoa+Física CONTA+.....:+1111-1111111-1 SENHA+4+...:+4444 :::::::+TABELA+::::::: REF+.......:+999999999999 1+..:+222 2+..:+222 3+..:+222 4+..:+222 5+..:+222 6+..:+222 7+..:+222 8+..:+222 9+..:+222 10+..:+222 11+..:+222 12+..:+222 13+..:+222 14+..:+222 15+..:+222 16+..:+222 17+..:+222 18+..:+222 19+..:+222 20+..:+222 21+..:+222 22+..:+222 23+..:+222 24+..:+222 25+..:+222 26+..:+222 27+..:+222 28+..:+222 29+..:+222 30+..:+222 31+..:+222 32+..:+222 33+..:+222 34+..:+222 35+..:+222 36+..:+222 37+..:+222 38+..:+222 39+..:+222 40+..:+222 41+..:+222 42+..:+222 43+..:+222 44+..:+222 45+..:+222 46+..:+222 47+..:+222 48+..:+222 49+..:+222 50+..:+222 51+..:+222 52+..:+222 53+..:+222 54+..:+222 55+..:+222 56+..:+222 57+..:+222 58+..:+222 59+..:+222 60+..:+222 61+..:+222 62+..:+222 63+..:+222 64+..:+222 65+..:+222 66+..:+222 67+..:+222 68+..:+222 69+..:+222 70+..:+222 &NOME=PAL
Thoughts
URLvoid results says the website is clean: http://www.urlvoid.com/scan/shanhaiichiba.com
Most likely this website may not host malware however at some point was used by the attacker to upload the banner_inc.php file and grab the bank account data. The banner_inc.php is not available at this moment,
Just out of curiosity I looked at zone-h archive and found this website was defaced in 2010/08/26: http://www.zone-h.org/mirror/id/11315692
This does not mean the attacker who defaced the website uploaded the banner_inc.php, most likely not. However, it increases the possibility that another attacker uploaded malicious file like the banner_inc.php. This is an example of a valid website being used by attackers to spread malware, on this case just being used as a bridge to gather bank account data.
Conclusion
Even thought the malware has some typos it has a good design and I believe people may trust that's a valid software from the bank, it does not has a valid certificate but I also believe whoever clicked on it will just click OK to open it up. Also, since it uses a non-malicious URL, a web proxy would not detect the traffic.
In the next post, I will show up how to unpack the malware and on part3 we will analyze the code to make sure the malware does not use another URL for sending data.
Thanks for your attention.
Pedro Drimel Neto
Introduction
On this part1 I will analyze the same sample of the last post within a different point of view, focused on the malware analyze without looking at the code, with some screenshots and some thoughts on the remote host compromise.
In the next posts, I will unpack the malware, compare VT results packed vs unpacked and later analyze the code, figuring out how the malware load the target URL.
So, this post may be interested for only whoever never saw a Brazilian banker.
The sample itself
I won't run through the behavioral analysis (file system, registry access, etc), for that you can take a look at the previous post here. Also, most of the Brazilian bankers (if not all) don't use to be persistent or advanced, like adding itself to registry, perform API hooking, process injection, etc. Most of them are simple applications developed under higher-level languages such as Delphi and Visual Basic and sometimes packed with known packers, I haven't seen yet a Brazilian banker packed by a custom packer. Please, let me know if you have one of those, I would love to have a look.
Then you just need to choose your account type: "Bradesco - Pessoa Física" or "Bradeco - Prime", I don't know why that since for both you need to provide the same information. Once you choose your account type a message is displayed saying the information exchange will only be available for you and the bank. This is a default behavior for bankers, repeat a couple of times you are secure, I have never saw that amount of messages from my real bank.
Once you type agency and account, a virtual keyboard is displayed, like in real the bank website, it's fairly the same. The application does not even let you type the password if you don't do through the virtual keyboard.
Once you click on "Enviar" which means "Send", another message is displayed saying that your new security card will be sent to your address and then ask if you already received it or not.
What the hell is a "security card"?
On this bank, the second authentication method use a card which the bank calls "security card", they do not use tokens like other banks, so basically if you want to transfer money online you also need to provide the number of position "x" in your security card.
Once you click "Yes" or "No" another message is displayed saying that the security card improves your online transactions and that you should "re-sign" the current one, which means in theory that you need to provide all of the security card position numbers in order to keep the current one.
Then, finally, after you type all the security card numbers and click "Enviar" a HTTP POST is sent to www.shanhaiichiba.com with your data. The author fails again do not mentioning REF stays in the front of the card, they don't even need REF in order to steal money, perhaps it's something additional to pretend being a valid application.
The HTTP Post is the following:
T=P&DADOS=TIPO+......:+Bradesco+-+Pessoa+Física CONTA+.....:+1111-1111111-1 SENHA+4+...:+4444 :::::::+TABELA+::::::: REF+.......:+999999999999 1+..:+222 2+..:+222 3+..:+222 4+..:+222 5+..:+222 6+..:+222 7+..:+222 8+..:+222 9+..:+222 10+..:+222 11+..:+222 12+..:+222 13+..:+222 14+..:+222 15+..:+222 16+..:+222 17+..:+222 18+..:+222 19+..:+222 20+..:+222 21+..:+222 22+..:+222 23+..:+222 24+..:+222 25+..:+222 26+..:+222 27+..:+222 28+..:+222 29+..:+222 30+..:+222 31+..:+222 32+..:+222 33+..:+222 34+..:+222 35+..:+222 36+..:+222 37+..:+222 38+..:+222 39+..:+222 40+..:+222 41+..:+222 42+..:+222 43+..:+222 44+..:+222 45+..:+222 46+..:+222 47+..:+222 48+..:+222 49+..:+222 50+..:+222 51+..:+222 52+..:+222 53+..:+222 54+..:+222 55+..:+222 56+..:+222 57+..:+222 58+..:+222 59+..:+222 60+..:+222 61+..:+222 62+..:+222 63+..:+222 64+..:+222 65+..:+222 66+..:+222 67+..:+222 68+..:+222 69+..:+222 70+..:+222 &NOME=PAL
Thoughts
URLvoid results says the website is clean: http://www.urlvoid.com/scan/shanhaiichiba.com
Most likely this website may not host malware however at some point was used by the attacker to upload the banner_inc.php file and grab the bank account data. The banner_inc.php is not available at this moment,
Just out of curiosity I looked at zone-h archive and found this website was defaced in 2010/08/26: http://www.zone-h.org/mirror/id/11315692
This does not mean the attacker who defaced the website uploaded the banner_inc.php, most likely not. However, it increases the possibility that another attacker uploaded malicious file like the banner_inc.php. This is an example of a valid website being used by attackers to spread malware, on this case just being used as a bridge to gather bank account data.
Conclusion
Even thought the malware has some typos it has a good design and I believe people may trust that's a valid software from the bank, it does not has a valid certificate but I also believe whoever clicked on it will just click OK to open it up. Also, since it uses a non-malicious URL, a web proxy would not detect the traffic.
In the next post, I will show up how to unpack the malware and on part3 we will analyze the code to make sure the malware does not use another URL for sending data.
Thanks for your attention.
Pedro Drimel Neto
Assinar:
Postagens (Atom)