Blog do Laboratório

Archivo para la Categoria 'Análise de malware'

Analisando malware em Android: Primeiros passos.

janeiro, 2, 2013 9:23 am

Ao longo deste ano, temos compartilhado com você uma grande quantidade de análises e situações em  que um código malicioso para dispositivos móveis afetou aos usuários de Android, não somente a nível mundial como também na América Latina. Por outro lado, temos comentado sobre os resultados das investigações que realizamos no Laboratório da ESET Latinoamérica, não tínhamos compartilhado com vocês sobre as metodologias de análises, as técnicas ou ferramentas que podem-se utilizar para este assunto.

Na primeira instancia, uma vez que definimos os objeticos das análises deveríamos falar sobre as ferramentas que podemos utilizar, onde encontrá-las e como preparar um correto ambiente para a análise de malware em Android. Para simplificar um pouco esta tarefa, vamos nos centrar em uma distribuição de Linux:  Santoku. Esta distribuição vem especialmente armada para poder analisar códigos maliciosos, buscar vulnerabilidades ou outra grande quantidade de tarefas em relação as plataformas móveis portanto conta com muitas ferramentas úteis e efetivas para analisar malware, atualmente a versão disponível é a 0.3 Alpha.

Ferramentas como apktool, dex2jar, Droidbox, Androguard, são de grande utilidade no momento de analisar um malware para Android. Cada uma delas tem distintas funcionalidades e somodas a um pouco de trabalho o resultado é ótimo.  Uma aplicação de Android é na realidade um arquivo com extensão “.apk” o qual da mesma forma, se alguém tentar abrir um arquivo compactado que se parece com a seguinte estrutura:

O diretório META-INF encontram-se os certificados da aplicação e outra  informação sobre sua estrutura. A pasta res contém os recursos da aplicação como por exemplo os ícones, imagens e outros dados mas que não se encontram compilados. Logo temos 3 arquivos no diretório raiz, o arquivo resources.arsc contém todos os recursos compilados para a aplicação, classes.dex que contém o código da aplicação compilado em um formato que interpreta a máquina virtual de Dalvik e o arquivo AndroidManifest.xml é onde se encontra informação sobre a aplicação como por exemplo, permissões, serviços, recebimentos e a versão de Android com a qual é mais compatível.

Sem extrairmos o AndroidManifest.xml e tentarmos ler seu conteúdo é possível observar que não se encontra legível, o mesmo ocorre com o arquivo classes.dex, para evitar um trabalho complicado de compreender estes formatos, veremos de que maneira levá-los a uma linguagem mais legível e fácil de entender. Acompanharemos a aprendizagem das análises de malware para Android com um caso real, pelo tanto vamos a analisar o arquivo como MD5: b1ae0d9a2792193bff8c129c80180ab0.

Vamos utilizar apktool para decodificar o arquivo e poder ler seu conteúdo e desta maneira analisar as permissões que solicita a aplicação para sua instalação e execução. É muito importante ler com atenção a informação fornecida pelo AndroidManifest.xml já que se podem identificar características importantes da aplicação ou sessões de seu código das quais vamos prestar atenção a medida que avançamos com as análises:

Ao ler o conteúdo do arquivo, pode-se identificar sua estrutura e suas sessões. Dentro da informação que provê este arquivo pode-se identificar a versão  da aplicação (android: versionCode e android:VersionName) em que versão de Android funciona  (android:minSDKVersion) como assim também as permissões que requer para sua execução. No caso de ameaça analisada, pode-se observar que solicita uma grande quantidade de permissões, os quais devemos analisar em detalhe e com o tempo aprender a identificar quais são mais perigosas que outras.

Uma vez que identifiquemos as principais seções da aplicação e os pontos mais importantes chega o momento de analisar o código e ver em detalhe quais são as ações tomadas em caso de que sucedam os eventos que nos importam. Neste momento, é importante entender que é o que devemos buscar e como encontrá-lo. Por exemplo, se se tenta analisar que código que se executa quando chega um mensagem de texto, tem que se buscar dentro da pasta  smali o arquivo SecurityReceiver.smali, ao abri-lo podemos ver o bytecode da aplicação e analisar seu funcionamento:

Recapitulemos, ao iniciar as análises de um código malicioso para Android uma das primeiras coisas que se deve fazer é entender sua estrutura, buscar as permissões e para logo investigar em detalhe o que se faz na aplicação e tentar acessar seu código. Até agora vimos como descompilar o malware com apktool e acessar os recursos como no AndroidManifest.xml e encontrar o bytecode da aplicação e os métodos e classes que queremos analisar, ainda que fique muito por fazer. Na próxima parte veremos a estrutura dos componentes mais importantes de uma aplicação e como obter o código de uma maneira mais legível, para continuar com as análises, se querem conhecer mais informações sobre o código malicioso que estamos analisando, podem acessar ao Trojan em Android: Violando sistemas dedupla autenticação  e Android Botnets: o roubo de mensagens de texto.

Mantenham-se atentos porque continuaremos as análises de malware em Android nas próximas semanas!

Pablo Ramos

Security Researcher

Trojans bancários no Brasil agora usam certificado digital

setembro, 6, 2012 7:08 pm

Já foram reportados vários casos de phishing com geolocalização e outros casos de códigos maliciosos direcionados a usuários brasileiros. Recentemente, detectamos um novo trojan que afeta aos usuários de instituições financeiras no Brasil.

O código malicioso é detectado pelas soluções de detecção proativa da ESET como Win32/Spy.Banker.YJS trojan. Assim que é executado na máquina do usuário, o malware cria um arquivo na pasta System32, iniciando um processo que é executado e espera que o usuário acesse a página do banco na Internet:

 

Se o usuário inserir a página de seu banco utilizando um navegador diferente no Internet Explorer, este automaticamente fecha e mostra um aviso para que se utilize o navegador mencionado. Este comportamento pode ser um sinal de alerta para o usuário, já que se antes o banco permitia a utilização de diferentes navegadores para o acesso, não é normal que restrinja o uso a um só navegador em particular.

Uma vez que o usuário insere os dados de sua conta, o código malicioso inicia a captura da informação. Toda essa captura é feita simulando uma página do banco, mas sem gerar tráfego de rede. Nesse ponto, novamente há um alerta para o usuário: apesar de estar lidando com informações sensíveis, a conexão utilizada não está criptografada, o que não é normal em uma conexão de confiança como a que se estabelece com as entidades financeiras. Isto é detectado facilmente ao observar a barra de endereço do navegador e descobrir que não se está utilizando o protocolo seguro https://.

 

Se o usuário continua inserindo sua informação pessoal, além de pedir os dados de seu cartão, também pede para inserir dados pessoais como números de identificação e de confirmação pessoal; chegando a um ponto em que o código malicioso simula um teclado virtual onde deve ser inserida a senha associada com a conta. Tudo isso se faz simulando as páginas do banco, mas novamente há alertas que poderiam levantar a suspeita de haver algo errado. Ao clicar nos ícones de ajuda não aparece nenhuma informação, o que seria habitual na página original de uma entidade financeira:

 

Finalmente uma vez que o usuário inseriu toda sua informação na página falsa, o código malicioso envia um e-mail ao atacante com um resumo de toda a informação inserida: senhas, números de conta e números de identificação. Além disso, ocorre a captura de informação do computador a partir do momento em que o usuário se conectou à Internet:

 

Algo particular deste código malicioso é que utiliza um certificado eletrônico roubado, da Comodo, uma entidade certificadora real, como se pode observar nas capturas a seguir.

 

Esta característica faz com que o código malicioso possa se propagar por servidores de correio e sistemas sem que seja detectado por muitas ferramentas de segurança. Além de contar com a solução de segurança podemos ter em conta práticas de boa navegação realizar transações seguras na Internet.

Fernando Catoira, Analista de Segurança
H. Camilo Gutiérrez Amaya, Especialista de Awareness & Research

Dias após o DNSChanger

julho, 12, 2012 4:57 pm

Tempos atrás surgiu uma ameaça conhecida sob a nomenclatura DNSChanger, que é detectada pelo ESET NOD32 Antivirus como Win32/DNSChanger. Este malware tem como finalidade redirecionar os usuários infectados a sites maliciosos. Os redirecionamentos são feitos com a modificação dos endereços IP dos DNS do sistema infectado. No último dia 9 de julho, o FBI tirou de funcionamento os servidores DNS maliciosos, sobre os quais a própria instituição havia tomado controle. Desta forma, todos os usuários que continuem infectados com o DNSCHanger estão sem acesso à Internet por não terem como converter os nomes em endereços IP.

Além da ESET e do FBI terem oferecido ferramentas para ajudar a informar os usuários que estiveram infectados, sendo que o Google também ofereceu ajuda nesse sentido. O buscador analisava os servidores dos endereços que faziam buscas no site, e no caso de identificar um servidor malicioso, alertava o usuário, indicando que seu sistema poderia estar infectado.

A equipe da ESET América Latina recompilou dados baseados nas detecções reportadas do DNSChanger. Desta forma, é possível considerar quais foram os países mais afetados da região latino-americana. O México conta com 42,4% das detecções. Na posição seguinte, com taxas de detecção similares, estão a Argentina com 10,9%; Peru com 10,7% e o Brasil com 10,1% do total de infecções na América Latina. A seguir, você pode observar um gráfico que reflete a situação na região:

Outro dado que vale a pena destacar é que essa porcentagem está baseada em detecções, e por isso o número de usuários que realmente ficaram sem acesso à Internet pode ser inferior, devido à possibilidade de muitos sistemas já terem sido limpos.É importante destacar que o México, juntamente com a Argentina, Peru e Brasil reflitam aproximadamente 80% do total das infecções na América Latina. Contudo, existem outros países dentro da região que, em menor medida, também foram afetados pelo DNSChanger.

Para os usuários que tenham ficado sem acesso à Internet devido a este malware, é recomendável que baixem o ESET NOD32 Antivirus em um computador que tenha acesso à Internet e utilizem algum dispositivo de armazenamento removível (USB, cartão SD, discos externos, dentre outros) para instalá-lo no computador infectado. Nesse momento será necessário executar uma análise para limpar o sistema infectado. É importante destacar que é importante, além disso, contar com um software antivírus com capacidade de detecção proativa para se proteger contra ameaças que circulam na rede, incluindo o DNSChanger.

Fernando Catoira
Analista de Segurança

Trojans que utilizam proxies permanecem ativos

abril, 19, 2012 9:00 am

Esta semana recebemos no Laboratório da ESET América Latina uma amostra de um trojan detectado pelo ESET NOD32 Antivirus como BAT/Agent.NLF Trojan. A ameaça se propaga através de um e-mail contendo um suposto vídeo do namorado de uma das integrantes do programa Big Brother Brasil 2012, tentando persuadir os usuários a baixarem um arquivo. Após realizarmos uma análise mais profunda, pudemos observar que o comportamento mudou a respeito das ações efetuadas no golpe:

Como primeiro passo, imediatamente depois de executar a ameaça, é aberta uma janela do navegador, acessando um popular site de vídeos online. Contudo, isso não é mais que uma distração, já que o malware está executando operações em segundo plano, sem que o usuário veja.

Analisando as mudanças que são feitas no sistema, é possível ver que várias entradas de registro foram alteradas, porém o que mais chama a atenção é a mudança nas entradas de registro correspondentes aos diferentes navegadores instalados no sistema operacional. A alteração dessas entradas tem como finalidade, cada vez que o navegador é iniciado, seja baixado um arquivo com extensão TXT a partir de um site remoto, que contém código  oculto para evitar ser detectado, e que permite comparar os endereços URL que o usuário acessa com uma lista armazenada no referente código.

Desta maneira, se o usuário acessa uma URL que se encontra listada no arquivo de texto, é redirecionado a um site de phishing relacionado à URL acessada. Dessa maneira, o trojan não realiza pharming local como fazem muitos outros, mas utiliza um site remoto como proxy para redirecionar o usuário a determinados sites de phishing de acordo com os sites que o usuário acessa dentro da lista contida no arquivo de texto baixado:

Essas operações tem como finalidade o roubo de credenciais de múltiplos serviços através do mesmo malware. Isto inclui serviços de e-mail muito populares, como também o roubo de credenciais de home banking de diferentes entidades bancárias de renome, dentre outros.

Na imagem anterior, podemos ver a inserção de credenciais de acesso a um serviço popular de e-mail (na verdade um site de phishing). Os dados serão roubados e armazenados no servidor malicioso como mostra a imagem a seguir:

Outro ponto que vale a pena destacar é que através desta técnica os cibercriminosos por trás desse código malicioso podem modificar o arquivo de texto baixado e atualizá-lo com novos sites e campanhas para expandir o roubo de credenciais a outros serviços, sem que o usuário seja infectado com algum outro tipo de malware.

Finalmente, aconselhamos ao usuário que conte com uma solução antivírus com capacidade de detecção proativa para poder se proteger contra este tipo de ameaça, assim como também bloquear as URLS pertencentes a servidores maliciosos.

Fernando Catoira
Analista de Segurança

Facebook, trojans e botnets

dezembro, 8, 2011 4:58 pm

Hoje vamos apresentar a vocês a análise de um código malicioso que se propagava através de e-mails falsos se passando por uma notificação do Facebook. A ameaça, detectada pelo ESET NOD32 Antivirus como Win32/VB.NRE, tenta transformar o computador em um integrante de uma botnet. Observaremos como é que este código malicioso infecta o sistema e logo se comunica com o painel de administração.

Em primeiro lugar, para que um computador seja infectado, o usuário deve ter sido vítima do golpe, baixando e executando o trojan. Lembre-se que a engenharia social é utilizada para chamar a atenção de vítimas em potencial. Aqueles que não contam com boas práticas para navegar na Internet, nem contam com uma solução de segurança, podem estar expostos a esse tipo de ataques.

Quando se executa o arquivo, o usuário não vê a suposta postagem no Facebook. O que na verdade acontece é que o arquivo se adiciona ao início automático do sistema e, além disso, entrará em contato com o Centro de Controle (C&C) da botnet para receber novas ordens. Vejamos o que acontece em cada uma dessas duas etapas. Através de uma análise dinâmica do trojan, é possível determinar onde se armazena uma cópia dele mesmo: “C:\Windows\csrcs.exe”. Essa informação pôde ser comprovada utilizando o ESET SysInspector, uma ferramenta de diagnóstico da ESET, como se pode observar na imagem a seguir:

Uma vez que se conhece a localização do arquivo é possível eliminá-lo manualmente, além de ser recomendável apagar a entrada no início automático. Anteriormente, já havíamos comentado que essa técnica é muito comum entre as estratégias dos criminosos virtuais com o objetivo de executar seu código malicioso na inicialização do sistema.

Este trojan também se comunica com o painel de controle da botnet, enviando informação sobre o sistema operacional, usuário, senha e o endereço IP do novo computador zumbi. Com essa informação, o botmaster pode identificar de maneira exclusiva os equipamentos que estão sob seu controle, acessando os recursos remotamente. Outro dos pontos a considerar sobre este comportamento é que a conexão é feita a partir do computador infectado até o endereço URL remoto através do protocolo HTTP na porta 80. Com esse comportamento, é mais difícil para um firewall detectar a atividade anormal.

Na tela anterior, observamos o tráfego de saída até o painel de administração e todos os dados que mencionamos anteriormente. Uma vez que o computador é ativado como parte da botnet Volk, em sua versão 4.0, o criminoso poderá utilizar o sistema para o roubo de credenciais de acesso ao Internet banking, envio de spam e outras atividades maliciosas. O método GET utilizado ao enviar os dados permite baixar outros arquivos executáveis e armazená-los nos arquivos temporários do Windows para sua posterior execução. Por último, podemos observar que o painel de administração desta botnet se encontra ativo:

Mais uma vez, esse tipo de atividade foi reportada na região, assim como a detecção de redes de computadores zumbis que atacam usuários da América Latina. Para evitar este tipo de situação, é necessário contar com uma solução antivírus com capacidade de detecção proativa, como também poder identificar falsos e-mail e nunca abrir os arquivos anexos sem antes analisa-los.

Pablo Ramos
Especialista de Awareness & Research

Contato | Política de Privacidade | Informações Legais © Copyright 1992-2013 por ESET, LLC e ESET, spol. s.r.o. Todos os direitos reservados