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 Felipe.Silva
      Injeção de código é uma técnica que consiste em adicionar instruções extras em um executável. Essas instruções podem ser adicionadas em vários lugares do programa, inclusive executar antes do entry point original.
      O uso mais comum para injeção de código é para fins maliciosos, onde um shellcode poderia ser inserido no executável e dar acesso remoto para um atacante. Mas um exemplo de uso "justo" para essa técnica é para fins de patching no executável quando você quer que algo seja alterado em tempo de execução no binário.
      Se você já tentou injetar código em um executável manualmente deve saber que não é uma tarefa tão divertida. Pensando neste tipo de impasse, imaginei que seria interessante ter uma ferramenta para automatizar esse tipo de manipulação de um executável. Por esse motivo criei o pei, uma ferramenta para automatizar injeção de código e outros tipos de manipulações em executáveis PE de 32-bit e 64-bit.
      O pei foi programado pensando na automação e por isso é fácil usar a ferramenta a partir de um script. Com ela você pode obter e modificar valores no executável, e é claro, injetar código.
      Antes de qualquer coisa você pode instalar o pei em seu Linux rodando os comandos abaixo:
      git clone https://github.com/Silva97/pei cd pei make sudo make install Nota: Caso use Windows e não esteja usando WSL ou um MSYS2 da vida, você pode compilar o projeto instalando o make e o MinGW (recomendo usar o Chocolatey). No entanto, o “sudo make install” não vai funcionar no Windows, você vai ter que adicionar o executável ao PATH manualmente.
      Se você não estiver a fim de compilar o executável, fiz o favor de adicionar o binário da ferramenta compilado para Windows nos releases dela. Você pode baixá-lo no link https://github.com/Silva97/pei/releases/latest.
      O uso básico da ferramenta segue o seguinte formato:
      pei [opções] <operação> <executável> [argumento] Se você quiser ver mais detalhes de como usar a ferramenta você pode rodar “pei -h”.
      Operações
      As operações são o que determinam o que a ferramenta irá fazer com o executável, indo desde exibir informações sobre ele até modificar campos dos cabeçalhos.
      show
      A operação show serve para exibir informações sobre o executável e campos dos cabeçalhos. Se você não passar argumentos para a operação por padrão ela irá exibir informações básicas do executável:

      Você também pode especificar uma combinação de letras para escolher quais campos serão exibidos, dentre elas: c (COFF header), o (optional header), d (data directories) e s (section). Exemplo:
      $ pei show test.exe co Esse comando, por exemplo, exibe o COFF header e optional header do executável.
      get
      A operação get pega o valor de um campo individual de um dos cabeçalhos (coff, optional ou section) do executável.
      Seguindo uma notação com pontos, semelhante à acessar campos de estruturas em C, você pode especificar o cabeçalho e o nome do campo para ser obtido. Por exemplo, para obter o entry point do executável o comando ficaria:
      $ pei get executavel.exe optional.entry_point '%x' 14f0 Dica: Veja o nome dos campos dos cabeçalhos usando a operação show.
      O argumento após o nome do campo é uma string de formatação idêntica a da função printf() da libc, que aceita quaisquer flags de formatação disponíveis para a função.
      Para acessar os campos de uma seção é necessário especificar o número da seção também, como demonstrado no print abaixo:

      edit
      A operação edit serve para modificar o valor de campos, onde o nome do campo é especificado de maneira idêntica à operação get.
      Você pode utilizar os operadores `=`, `|=` e `&=` que fazem exatamente a mesma coisa que na linguagem C. Exemplos:
      $ pei edit executavel.exe section.0.name = .code $ pei edit executavel.exe optional.entry_point = 0xabcd1234 Esta operação aceita números em decimal, hexadecimal ou octal na hora de definir o valor de campos numéricos.
      zeros
      Esta operação simplesmente exibe uma lista das maiores sequências de bytes nulo em cada seção do executável. É este espaço que é utilizado para injetar o código, tornando a operação útil para você poder escolher em qual seção injetar o código.
      $ pei zeros executavel.exe Section #0 '.text': 0x00000000000022fb of 13 bytes Section #1 '.data': 0x000000000000242c of 1012 bytes Section #2 '.rdata': 0x0000000000002a5b of 37 bytes Section #6 '.idata': 0x0000000000003a26 of 22 bytes Section #7 '.CRT': 0x000000000000420b of 21 bytes Section #9 '/4': 0x0000000000004649 of 23 bytes Section #10 '/19': 0x0000000000004cbe of 10 bytes Section #12 '/45': 0x000000000003e2fc of 5 bytes Section #13 '/57': 0x0000000000041019 of 8 bytes Section #15 '/81': 0x0000000000043c33 of 44 bytes Section #16 '/92': 0x0000000000045509 of 23 bytes inject - A cereja do bolo 🙂
      Esta é a operação que injeta o código. Você pode usar a opção -f para especificar o arquivo contendo o código a ser injetado, que seria um raw binary. Onde esse arquivo deve conter apenas as instruções de código de máquina a ser injetado, como um shellcode por exemplo.
      Opcionalmente, você pode usar a opção -s para especificar o número da seção que você quer injetar o código. Se a opção não for especificada, por padrão o pei vai injetar onde houver mais espaço disponível.
      $ pei -f my_code.bin inject executavel.exe Writed code of 12 bytes on offset 0x0000000000043924 of section #15 '/81' Após o código injetado, o pei insere um jump absoluto para o entry point original do executável, fazendo com que após o código injetado ser executado o fluxo de execução do programa continue normalmente.
      Outra modificação que o pei faz é desabilitar o dynamic base do executável, para evitar que o jump aponte para o endereço errado.
      Dica: Injetando Código Muito Grande
      Se você precisar injetar um código maior do que o espaço disponível apontado pela operação zeros, você pode dividir o código a ser injetado em várias partes e injetar cada parte por vez, seguindo a ordem da última até a primeira parte. Isso funciona porque o pei irá adicionar um jump no final do código para o endereço que está sendo indicado como entry point. Se você já injetou código antes, esse endereço é o endereço do código anteriormente injetado. 🙂
      Dessa forma você pode fazer um chain de saltos da primeira parte até a última e então saltar para o entry point original. Exemplo:
      $ pei inject -f parte-3.bin executavel.exe Writed code of 87 bytes on offset 0x0000000000043833 of section #15 '/81' $ pei inject -f parte-2.bin executavel.exe Writed code of 80 bytes on offset 0x0000000000044924 of section #11 '/23' $ pei inject -f parte-1.bin executavel.exe Writed code of 32 bytes on offset 0x0000000000401a15 of section #1 '.text' Isso irá criar a seguinte ordem de execução: parte-1.bin -> parte-2.bin -> parte-3.bin -> entry point. Onde as setas “->” representam os saltos.
      diff
      Esta operação exibe diferenças entre dois executáveis. Ela compara cada campo dos cabeçalhos do executável e o conteúdo das seções, e depois exibe estas diferenças no terminal. Você pode usar a opção -c (ou --color) para que a saída da operação seja colorida:

      Em vermelho são os valores no executável original que foram modificados e em verde são os valores novos no executável modificado.
      patch
      Essa operação lê um texto de entrada no mesmo formato que a saída da operação diff e replica as mesmas modificações no executável. Exemplo:
      $ pei patch executavel2.exe diff-output.txt Caso você não especifique um patch file, o pei irá ler de stdin. Assim, é possível que você faça um pipe entre uma operação de diff e patch:
      $ pei diff original.exe mod.exe | pei patch outro.exe A diferença de fazer isto e simplesmente fazer uma cópia do executável modificado, é que a ideia é replicar somente as diferenças entre os executáveis. Quaisquer outros campos não são tocados pela operação patch, o que te permite salvar alterações e replicá-las por meio de um script. 🙂
      Se você quiser, também é possível escrever um patch file manualmente, bastando imitar a saída de diff. Uma dica é que os valores dos campos originais (em vermelho) não são necessários para a operação patch, então você pode inserir somente os valores novos. Seguindo o print da saída do diff que utilizamos agora pouco como exemplo:
      optional.entry_point xxx 0x4ca33 section.0.name xxx .code section.15.characteristics xxx 0x62100040 // @O texto não faz diferença, só importa o @ no início da linha // Daqui para baixo qualquer linha que não inicie com + será ignorada. +0x43830 00 30 9f 61 62 63 0a b8 f0 14 40 00 ff e0 00 00 // O formato é: +0xoffset bytes em hexadecimal Nota: Onde há o “xxx” seriam os campos dos valores originais (em vermelho) que não são lidos pelo pei porém são necessários para imitar a saída da operação diff. Você pode colocar qualquer valor aí que não dará erro já que são ignorados.
      Você pode usar a operação patch em scripts para automatizar várias modificações em um executável ao mesmo tempo, inclusive em bytes de um determinado offset.
    • By Bruna Chieco
      O EtterSilent é um novo malware criador de documentos maliciosos que tem utilizado o DocuSign para enganar vítimas. Segundo descoberta do Intel 471, o “produto” tem sido alavancado por vários grupos de crimes cibernéticos, e à medida que cresceu em popularidade, foi atualizado constantemente para evitar a detecção. 
      O grupo de inteligência em cibersegurança diz que o malware foi anunciado pela primeira vez em um fórum russo de crimes cibernéticos, onde o vendedor ofereceu dois tipos de documentos do Microsoft Office como arma aos usuários: um que explora uma vulnerabilidade conhecida no Microsoft Office (CVE-2017-8570) e outro que usa uma macro maliciosa, sendo essa a escolha mais popular do cibercriminosos.
      O documento malicioso, quando aberto, mostra um modelo que se apresenta como DocuSign, popular software que permite que indivíduos e organizações assinem documentos de maneira digital. Ele então aproveita as macros do Excel 4.0 armazenadas em uma planilha oculta, o que permite que uma carga hospedada externamente seja baixada, gravada em disco e executada usando regsvr32 ou rundll32. 
      O Intel 471 diz ainda que o EtterSilent está sendo utilizado em muitas campanhas de malware familiares para a maioria dos especialistas em segurança cibernética, entre elas uma campanha de spam recente para lançar uma versão atualizada do Trickbot. O documento malicioso foi anexado em um e-mail que fingia ser de um conhecido fabricante multinacional de eletrodomésticos, alegando ser uma fatura de pagamento.
      Em 19 de março de 2021, o EtterSilent foi usado como parte de uma campanha do malware Bazar. O documento malicioso, neste caso, não usava um modelo DocuSign, mas a planilha principal do Excel era chamada de “DocuSign®”. Ele baixa, então, a carga útil do Bazar, que por sua vez se conecta a outro URL que baixa a backdoor do Bazar.
      Três cavalos de Troia bancários – BokBot, Gozi ISFB e QBot – também usaram o EtterSilent em conjunto com seus esquemas. O Intel 471 rastreou ainda uma campanha específica ligada ao BokBot contendo URLs de distribuição embutidos nos documentos maliciosos do EtterSilent. 
    • By Bruna Chieco
      Um malware recém-descoberto para Android foi encontrado na Play Store do Google disfarçado de uma ferramenta do Netflix. Segundo o BleepingComputer, ele foi projetado para se espalhar automaticamente para outros dispositivos usando respostas automáticas do WhatsApp às mensagens recebidas.
      Os pesquisadores da Check Point Research descobriram o novo malware, que se disfarça de um aplicativo chamado FlixOnline e tenta atrair vítimas em potencial com promessas de acesso gratuito ao conteúdo da Netflix. Os pesquisadores revelaram seus resultados de pesquisa ao Google, que rapidamente retirou o aplicativo malicioso da Play Store.
      Ainda assim, o app malicioso foi baixado cerca de 500 vezes ao longo dos dois meses em que estava disponível para download na loja. Depois que o aplicativo é instalado em um dispositivo Android, o malware inicia um serviço que solicita sobreposição, ignorar a otimização da bateria e permissões de notificação.
      Quando as permissões são concedidas, o malware gera sobreposições em qualquer janela de aplicativo para roubar credenciais, impedir que o dispositivo desligue seu processo para otimizar o consumo de energia, obter acesso a notificações de aplicativo e gerenciar ou responder a mensagens.
      Em seguida, ele começa a monitorar novas notificações do WhatsApp para responder automaticamente a todas as mensagens recebidas usando cargas de texto personalizadas recebidas do servidor de comando e controle criadas por seus operadores. A Check Point diz ainda que a técnica é sequestrar a conexão com o WhatsApp capturando notificações, realizando ações predefinidas, como 'dispensar' ou 'responder' por meio do gerenciador de notificações.
      Os pesquisadores reforçam que o fato de que o malware foi capaz de ser disfarçado tão facilmente e, em última análise, contornar as proteções da Play Store, levanta alguns sinais de alerta graves.
    • By Bruna Chieco
      Um novo malware chamado BazarCall utiliza call centers para distribuir alguns dos malwares mais prejudiciais do Windows. Segundo o BleepingComputer, o novo malware está sendo distribuído por call centers no final de janeiro e é utilizado para instalar o malware BazarLoader.
      A campanha começa com um e-mail de phishing, mas a partir daí se desvia para um novo método de distribuição, usando call centers para distribuir documentos Excel maliciosos que instalam malwares. Em vez de agrupar anexos, os e-mails do BazarCall solicitam aos usuários que liguem para um número de telefone para cancelar uma assinatura antes de serem cobrados automaticamente. Esses call centers direcionam os usuários a um site especialmente criado para baixar um "formulário de cancelamento" que instala o malware BazarCall.
      O BleepingComputer explica que os ataques BazarCall começam com um e-mail de phishing direcionado a usuários corporativos que afirmam que o teste gratuito do destinatário está prestes a acabar. No entanto, esses e-mails não fornecem detalhes sobre a suposta assinatura, solicitando que o usuário entre em contato com um número de telefone listado para cancelar a assinatura antes de ser cobrado. 
      Quando um destinatário liga para o número, ele é atendido por uma pessoa. Quando ele solicita mais informações sobre como cancelar a assinatura, o agente do call center pede à vítima um ID de cliente exclusiva incluído no e-mail. Um pesquisador da Binary Defense disse ao BleepingComputer que esse ID é um componente central do ataque e é usado pelo call center para determinar se o chamador é uma vítima específica.
      Se um ID de cliente correto for fornecido, o agente do call center direciona o usuário a um site falso que finge ser a empresa de serviços. O agente telefônico permanece ao telefone com a vítima a guiando até uma página de cancelamento onde será solicitada a inserção de seu ID de cliente. Quando o usuário insere seu número de ID de cliente, o site automaticamente solicita ao navegador que faça download de um documento Excel. O agente do call center ajuda a vítima a abrir o arquivo e a clicar no botão 'Habilitar Conteúdo' para habilitar macros maliciosos. Quando os macros do Excel são habilitadas, o malware BazarCall é baixado e executado no computador da vítima.
    • By Bruna Chieco
      Um novo vetor de infecção do malware Purple Fox coloca sistemas Windows voltados para a Internet em risco de ataques de força bruta. A Guardicore Labs emitiu comunicado informando que a campanha ativa de malware que visa máquinas Windows até então utilizada kits de exploração e e-mails de phishing para seus ataques. Agora, o novo vetor de infecção do Purple Fox tem como alvo máquinas Windows voltadas para a Internet, que estão sendo violadas por meio de ataques de força bruta de senha.
      A Guardicore Labs também identificou uma vasta rede de servidores comprometidos hospedando seu dropper e payloads, aparentando ser servidores Microsoft IIS 7.5. Além disso, o malware Purple Fox inclui um rootkit que permite aos agentes da ameaça oculta-lo na máquina, dificultando a sua detecção e a remoção. 
      O Purple Fox foi descoberto em março de 2018, sendo classificado como um kit de exploração voltado para computadores com Internet Explorer e Windows com escalonamento de privilégios. No entanto, ao longo do final de 2020 e início de 2021, a Guardicore Global Sensors Network (GGSN) detectou a nova técnica de propagação por meio de varredura indiscriminada de portas e exploração de serviços SMB expostos com senhas fracas e hashes.
      Em maio de 2020, houve uma quantidade significativa de atividades maliciosas, e o número de infecções observados pela Guardicore aumentou cerca de 600%, atingindo um total de 90 mil ataques.
      Eles relatam que a funcionalidade do Purple Fox não mudou muito após a exploração, mas sim os seus métodos de propagação e distribuição, com um comportamento semelhante a um worm. A Guardicore Labs dá mais detalhes sobre a análise realizada sobre os ataques do Purple Fox.
×
×
  • Create New...