14 de MARÇO
Ao mesmo tempo que as tecnologias de proteção evoluem, as táticas utilizadas por atacantes também tornam-se cada vez mais robustas. Uma das técnicas que vêm sendo utilizadas para entrega de malwares é a distribuição em dois estágios. No primeiro estágio, é enviado ao usuário (geralmente através de phishing/engenharia social) um arquivo pequeno, que tenta imitar algum arquivo legítimo. Porém este arquivo contém algum tipo de código ou script malicioso que fará o download e a execução do segundo estágio do malware.
Nossa equipe de SOC identificou um destes arquivos e coletou para análise. Na imagem abaixo, é possível identificar que o artefato consiste em um arquivo .zip, que, ao ser extraído, revela um arquivo de atalho do Windows.
Ao analisar as propriedades deste arquivo, verificamos que ele executa (através do conhost.exe - janela da console) o executável mshta.exe, passando como parâmetro um código Javascript com um certo grau de ofuscação. Podemos identificar algumas chamadas da função try, alguns caracteres em hexadecimal, e por fim, uma chamada da função GetObject, revelando que, ao executar este script, será feita uma chamada para alguma URL maliciosa para então fazer o download do malware real.
Após realizar o processo de desofuscação, substituindo os caracteres hexadecimais por seus correspondentes e identando melhor o script, a URL é revelada. O próximo passo da análise consiste em entender o que o script tenta baixar e executar. Mas como não é uma boa ideia simplesmente executar o script, a primeira tentativa foi utilizar algum navegador para obter o conteúdo do arquivo.
E aqui temos mais uma proteção que é implementada para não entregar o código do Malware para qualquer um. Quando a página é acessada através de um navegador, ou até mesmo através do software curl, é retornado um Header Location, forçando um redirecionamento para alguma outra página. Durante os testes, foram obtidos redirecionamentos para Facebook, Instagram, GitHub e Youtube.
Mas como é que a aplicação que irá entregar o malware sabe que estamos acessando de um navegador e que não é o próprio script que está fazendo a requisição? Este é um recurso que é inclusive utilizado em sites legítimos. Já reparou que alguns sites "mudam seu layout" quando acessados de um dispositivo móvel (um celular ou um tablet)? Isso ocorre da maneira semelhante ao redirecionamento citado acima. Da mesma forma que a aplicação responde à nossa requisição com um Header, nosso navegador também envia Headers para a aplicação durante a requisição. Um deles é chamado User-Agent, que, em linhas gerais, descreve o software utilizado para fazer a requisição. A aplicação então verifica qual é o software que está sendo utilizado para o acesso e responde com a página adequada para o dado acesso.
Existem alguns métodos para descobrir os valores válidos. Um deles é utilizar uma lista com diversos valores possíveis para este cabeçalho e enviar requisições até que um valor seja identificado como válido (técnica conhecida como fuzzing). Após encontrar um valor válido, é possível fazer uma requisição que retorna mais um código Javascript:
Novamente, o código retornado está ofuscado. O que faz sentido, já que o processo de ofuscação não altera o resultado da execução do código e já que a existência de funções try no atalho irá forçar a execução do bloco de instruções recebido. Depois de finalizar o processo de desofuscação neste novo script, conseguimos verificar que este sim, realiza o download e a execução do malware em si.
Este novo script possui uma lista com diversos domínios, todos com nomes fazendo referências à "contratos", "cancelamentos", "pagamentos", "emails" e similares, todos com TLD ".top". O código então escolhe um destes domínios de maneira aleatória e monta as requisições com o nome do arquivo a ser baixado. Na amostra que coletamos, o estágio final do malware é salvo na pasta C:\ProgramData\servicing\HDD, e possui nome de algum fabricante de Hardware, que também parece variar de amosrta para amostra. Após concluir o download do malware, o script tenta fazer a execução do mesmo.
Mas qual o motivo de um atacante fazer todas estas "manobras" para enviar um malware? Não seria mais fácil simplesmente enviar um link por e-mail para o usuário baixar?
Então. A utilização de duas etapas na distribuição de malware (download e execução) permite um maior controle por parte do atacante sobre as variáveis que podem existir. Uma técnica comum, que já foi encontrada em outras oportunidades, consiste em checar o idioma do alvo antes do download antes de prosseguir com a execução dos scripts. Malwares que fazem esta verificação geralmente possuem um alvo (geralmente, identificar o idioma de instalação do sistema operacional revela que o alvo é geográfico - um país ou até mesmo uma empresa com sede em determinado país). E, por algum motivo, no malware que analisamos, ele checa se existe uma pasta chamada C:\ProgramData\Public\fw. Conforme mostrado na imagem abaixo, se esta pasta já existir, o malware não é executado. (Vale lembrar que o código recebido estava ofuscado. O código apresentado na imagem já passou pelo processo de desofuscação e teve as variáveis renomeadas para uma melhor interpretação).
Além disso, como no exemplo analisado aqui, a utilização do executável Mshta.exe também é uma técnica bem conhecida e descrita no MITRE, inclusive utilizada por grupos famosos, como o Lazarus Group. Utilizar o Mshta ao invés de um Microsoft Edge, ou Google Chrome é preferível, pois como se trata de uma ferramenta "legada", muitas checagens de segurança implementadas pelos navegadores modernos são ignoradas.
Nosso Security Operations Center (SOC) está sempre à frente na identificação e mitigação de ataques cibernéticos sofisticados, como os malwares distribuídos em dois estágios. Com monitoramento contínuo, análise proativa e resposta rápida a incidentes, garantimos a segurança dos seus dados e a proteção do seu ambiente digital.
Quer saber como podemos fortalecer sua defesa cibernética?
Entre em contato e conheça nossas soluções!
Nossa equipe de SOC identificou um destes arquivos e coletou para análise. Na imagem abaixo, é possível identificar que o artefato consiste em um arquivo .zip, que, ao ser extraído, revela um arquivo de atalho do Windows.
Ao analisar as propriedades deste arquivo, verificamos que ele executa (através do conhost.exe - janela da console) o executável mshta.exe, passando como parâmetro um código Javascript com um certo grau de ofuscação. Podemos identificar algumas chamadas da função try, alguns caracteres em hexadecimal, e por fim, uma chamada da função GetObject, revelando que, ao executar este script, será feita uma chamada para alguma URL maliciosa para então fazer o download do malware real.
Após realizar o processo de desofuscação, substituindo os caracteres hexadecimais por seus correspondentes e identando melhor o script, a URL é revelada. O próximo passo da análise consiste em entender o que o script tenta baixar e executar. Mas como não é uma boa ideia simplesmente executar o script, a primeira tentativa foi utilizar algum navegador para obter o conteúdo do arquivo.
E aqui temos mais uma proteção que é implementada para não entregar o código do Malware para qualquer um. Quando a página é acessada através de um navegador, ou até mesmo através do software curl, é retornado um Header Location, forçando um redirecionamento para alguma outra página. Durante os testes, foram obtidos redirecionamentos para Facebook, Instagram, GitHub e Youtube.
Mas como é que a aplicação que irá entregar o malware sabe que estamos acessando de um navegador e que não é o próprio script que está fazendo a requisição? Este é um recurso que é inclusive utilizado em sites legítimos. Já reparou que alguns sites "mudam seu layout" quando acessados de um dispositivo móvel (um celular ou um tablet)? Isso ocorre da maneira semelhante ao redirecionamento citado acima. Da mesma forma que a aplicação responde à nossa requisição com um Header, nosso navegador também envia Headers para a aplicação durante a requisição. Um deles é chamado User-Agent, que, em linhas gerais, descreve o software utilizado para fazer a requisição. A aplicação então verifica qual é o software que está sendo utilizado para o acesso e responde com a página adequada para o dado acesso.
Existem alguns métodos para descobrir os valores válidos. Um deles é utilizar uma lista com diversos valores possíveis para este cabeçalho e enviar requisições até que um valor seja identificado como válido (técnica conhecida como fuzzing). Após encontrar um valor válido, é possível fazer uma requisição que retorna mais um código Javascript:
Novamente, o código retornado está ofuscado. O que faz sentido, já que o processo de ofuscação não altera o resultado da execução do código e já que a existência de funções try no atalho irá forçar a execução do bloco de instruções recebido. Depois de finalizar o processo de desofuscação neste novo script, conseguimos verificar que este sim, realiza o download e a execução do malware em si.
Este novo script possui uma lista com diversos domínios, todos com nomes fazendo referências à "contratos", "cancelamentos", "pagamentos", "emails" e similares, todos com TLD ".top". O código então escolhe um destes domínios de maneira aleatória e monta as requisições com o nome do arquivo a ser baixado. Na amostra que coletamos, o estágio final do malware é salvo na pasta C:\ProgramData\servicing\HDD, e possui nome de algum fabricante de Hardware, que também parece variar de amosrta para amostra. Após concluir o download do malware, o script tenta fazer a execução do mesmo.
Mas qual o motivo de um atacante fazer todas estas "manobras" para enviar um malware? Não seria mais fácil simplesmente enviar um link por e-mail para o usuário baixar?
Então. A utilização de duas etapas na distribuição de malware (download e execução) permite um maior controle por parte do atacante sobre as variáveis que podem existir. Uma técnica comum, que já foi encontrada em outras oportunidades, consiste em checar o idioma do alvo antes do download antes de prosseguir com a execução dos scripts. Malwares que fazem esta verificação geralmente possuem um alvo (geralmente, identificar o idioma de instalação do sistema operacional revela que o alvo é geográfico - um país ou até mesmo uma empresa com sede em determinado país). E, por algum motivo, no malware que analisamos, ele checa se existe uma pasta chamada C:\ProgramData\Public\fw. Conforme mostrado na imagem abaixo, se esta pasta já existir, o malware não é executado. (Vale lembrar que o código recebido estava ofuscado. O código apresentado na imagem já passou pelo processo de desofuscação e teve as variáveis renomeadas para uma melhor interpretação).
Além disso, como no exemplo analisado aqui, a utilização do executável Mshta.exe também é uma técnica bem conhecida e descrita no MITRE, inclusive utilizada por grupos famosos, como o Lazarus Group. Utilizar o Mshta ao invés de um Microsoft Edge, ou Google Chrome é preferível, pois como se trata de uma ferramenta "legada", muitas checagens de segurança implementadas pelos navegadores modernos são ignoradas.
Nosso Security Operations Center (SOC) está sempre à frente na identificação e mitigação de ataques cibernéticos sofisticados, como os malwares distribuídos em dois estágios. Com monitoramento contínuo, análise proativa e resposta rápida a incidentes, garantimos a segurança dos seus dados e a proteção do seu ambiente digital.
Quer saber como podemos fortalecer sua defesa cibernética?
Entre em contato e conheça nossas soluções!
