HotPage: Adware oculto em um suposto bloqueador de anúncios

A pesquisa sobre malware envolve o estudo das TTPs dos cibercriminosos, o mapeamento da infraestrutura, a análise de novas técnicas... E, embora a maioria destas pesquisas se baseie na investigação existente, por vezes começam com um palpite, algo que parece demasiado simples. No final de 2023, deparámo-nos com um instalador chamado HotPage.exe que implementa um controlador capaz de injetar código em processos remotos e duas bibliotecas capazes de intercetar e adulterar o tráfego de rede dos navegadores. O malware pode modificar ou substituir o conteúdo de uma página solicitada, redirecionar o usuário para outra página ou abrir uma nova página em um novo separador com base em determinadas condições.

O instalador foi detectado pela maioria dos produtos de segurança como um componente de adware, mas o que realmente despertou o nosso interesse foi o controlador incorporado assinado pela Microsoft. De acordo com a sua assinatura, foi desenvolvido por uma empresa chinesa chamada 湖北盾网网络科技有限公司 (tradução automática: Hubei Dunwang Network Technology Co., Ltd), cuja falta de informação é intrigante. O método de distribuição ainda não é claro mas, de acordo com a nossa pesquisa, este software foi anunciado como uma "solução de segurança para cibercafés" destinada a indivíduos de língua chinesa. Pretende melhorar a experiência de navegação na Web, bloqueando anúncios e sites maliciosos, mas a realidade é bastante diferente - aproveita as suas capacidades de interceção e filtragem do tráfego do navegador para apresentar anúncios relacionados com jogos. Também envia algumas informações sobre o computador para o servidor da empresa, muito provavelmente para recolher estatísticas de instalação.

Para além do seu óbvio comportamento malicioso, este componente do kernel deixa involuntariamente a porta aberta para que outras ameaças executem código no nível de privilégio mais elevado disponível no sistema operativo Windows: a conta SYSTEM. Devido a restrições de acesso inadequadas a este componente do kernel, qualquer processo pode comunicar com ele e tirar partido da sua capacidade de injeção de código para atingir qualquer processo não protegido.

Comunicámos este controlador à Microsoft em¹⁸ de março de 2024 e seguimos o seu processo coordenado de divulgação de vulnerabilidades. O Centro de Resposta de Segurança da Microsoft (MSRC) determinou que esta já não é uma vulnerabilidade, uma vez que o driver ofensivo foi removido do Catálogo do Windows Server em¹ de maio de 2024. As tecnologias da ESET detectam esta ameaça como Win{32|64}/HotPage.A e Win{32|64}/HotPage.B.

Quem é o 湖北盾网网络科技有限公司 ?

Durante sua execução, o malware HotPage instala um driver, mas antes de mergulhar nos detalhes técnicos de seu funcionamento interno, queríamos saber mais sobre a assinatura de código desse driver. O que primeiro chamou nossa atenção foi o proprietário do certificado de assinatura, conforme ilustrado na Figura 1.

Desde a versão de 64 bits do Windows 7, os drivers no modo kernel precisam ser assinados para serem carregados pelo sistema operacional. Conforme detalhado anteriormente pelas equipas da Mandiant Intelligence, SentinelLabs e G DATA, o processo de assinatura baseia-se na confiança, mas houve casos em que esta foi abusada. Parece que a empresa chinesa passou pelos requisitos de assinatura de código de driver da Microsoft e conseguiu obter um certificado de verificação estendida (EV), conforme mostrado na Figura 2.

Para obter o nome da empresa associada a esta assinatura, foi necessário extrair os atributos dos signatários. A Figura 3 mostra o atributo SpcSpOpusInfo identificado pelo ID de objeto 1.3.6.1.4.1.311.2.1.12.

Utilizando o analisador binário do LIEF, é possível extrair o membro da estrutura programName que identifica a empresa por detrás desta assinatura, como mostra a Figura 4.

Encontrámos uma referência a esta empresa no Catálogo do Windows Server, como mostra a Figura 5. A empresa usou várias categorias de produtos ao submeter seus drivers para certificação. Com base em seu nome, parece que a empresa desenvolveu dois programas de filtragem de rede: um componente netfilter e o driver HotPage referido como adsafe ou por seu nome interno KNewTalbeBase (observe o erro de digitação [Tt]albe, que também ocorre em outro lugar no código do HotPage).

A investigação da empresa através de motores de busca não produziu muitos resultados. De acordo com o registo da empresa dingtalk, descobrimos que a empresa foi criada em⁶ de janeiro de 2022 e forneceu o endereço de correio eletrónico dwadsafe@mail[.]io. O âmbito de atividade inclui: actividades relacionadas com a tecnologia, tais como desenvolvimento, serviços, consultoria, etc., mas também actividades publicitárias. Como se pode ver na Figura 6, o principal acionista é agora a Wuhan Yishun Baishun Culture Media Co., Ltd, uma empresa muito pequena que parece ser especializada em publicidade e marketing.

No separador Propriedade Intelectual, ficamos a saber que, em abril e maio de 2022, a empresa solicitou o nome comercial Shield Internet Café Security Defense e que o sítio Web dwadsafe[.]com foi criado em²² de fevereiro de 2022. O domínio está agora a ser resolvido para localhost(127.0.0.1), pelo que está inacessível. No entanto, uma captura de ecrã do sítio Web foi obtida em¹⁰ de novembro de 2023 por um web crawler, como se pode ver na Figura 7.

Captura

O corpo HTTP do URL https://www.dwadsafe[.]com/login/reg.html (SHA-1: 744FFC3D8ECE37898A0559B62CC9F814006A1218) também foi capturado pelo VirusTotal. O código fonte contém a descrição 网吧主动防御云平台 (tradução automática: Internet café plataforma de nuvem de defesa ativa). Esta página inclui um contrato de licença que detalha o objetivo do software, embora com contradições. A Tabela 1 lista algumas partes interessantes dessa informação.

Tabela 1. Tradução das partes relevantes do contrato de licença

De acordo com o contrato de licença, o software é efetivamente comercializado como uma solução de segurança para os cibercafés bloquearem os anúncios. No entanto, apesar das afirmações da empresa de que o DwAdsafe não tem qualquer capacidade de interceção, a nossa investigação revelou que o software tem uma capacidade bastante intrusiva e vem com regras pré-escritas e não modificáveis.

Para além destas informações, a empresa por detrás deste componente malicioso continua a ser um mistério.

Análise do HotPage

Nesta secção descrevemos como os diferentes componentes são instalados e interagem uns com os outros para atingir o seu objetivo: injetar anúncios no navegador. Até agora, não descobrimos como é que o malware foi distribuído, mas acreditamos, com pouca confiança, que pode ter sido incluído noutro pacote de software ou anunciado como um produto de segurança devido ao nível de privilégios necessários para instalar o controlador. Em 2022, foram encontradas algumas referências que anunciavam o produto em alguns fóruns; um exemplo pode ser visto na Figura 8.

cibercafés

O instalador coloca o controlador no disco e inicia um serviço para o executar. Descriptografa o seu ficheiro de configuração, que contém uma lista de navegadores e bibliotecas baseados no Chromium. Se esses executáveis forem encontrados em execução ou a serem carregados, o controlador tenta injetar uma das bibliotecas listadas no processo do navegador. Depois de ligar as funções da API do Windows baseadas na rede, a biblioteca injectada verifica o URL que está a ser acedido e, em determinadas condições, apresenta outra página ao utilizador através de diversos meios.

O instalador

O instalador que analisamos (SHA-1: 941F0D2D4589FB8ADF224C8969F74633267B2561) é um arquivo compactado UPX que foi carregado no VirusTotal em 2023-08-26. A Figura 9 fornece uma visão geral de alto nível da instalação do driver.

Visão geral

O instalador contém as versões encriptadas (operação XOR de byte único com a chave 0xE3) do componente do controlador, as bibliotecas que serão injectadas nos processos do navegador Web e três ficheiros de configuração formatados em JSON:

• chromedll contém os nomes das bibliotecas do browser visadas para enganchar e o padrão das funções visadas para as enganchar,
• hotPage (não utilizado) contém a lista de navegadores visados, listas de permissão de parâmetros de linha de comando e sites e o URL da página inicial que pode ser usado, e
• newtalbe contém regras de filtragem, um ponto final da API para enviar informações básicas sobre o computador comprometido e outro para gerir actualizações de configuração.

O malware começa por executar a instrução CPUID (ver Hypervisor Discovery), para verificar se está a ser executado num ambiente virtualizado. Depois verifica se o nome de ficheiro do dispositivo do controlador \\ .\KNewTableBaseIo existe e, se não existir, desencripta o controlador e armazena-o em C:\Windows\ShieldNetWork\Business\. O seu nome é uma cadeia de 7 caracteres gerada aleatoriamente seguida da extensão .sys. É criado um serviço com o caminho do ficheiro do controlador armazenado e a cadeia aleatória é utilizada como o nome do serviço. Uma vez que o tipo de início está definido como SERVICE_DEMAND_START, o serviço precisa de ser explicitamente iniciado para carregar o controlador. Estranhamente, este adware não implementa quaisquer mecanismos de persistência, ou pelo menos não nesta versão.

O instalador comunica e configura o controlador através do seu nome de ficheiro de dispositivo usando códigos de controlo de E/S na seguinte ordem:

1. 0x9C4013FC - envia a biblioteca de hooking de 32 bits que será injectada nos processos do navegador web alvo.
2. 0x9C400FFC - envia a biblioteca de hooking de 64 bits que será injectada nos processos do navegador Web de destino.
3. 0x9C40173C - envia a configuração chromedll .

O instalador recupera a chave de registo associada ao serviço criado e verifica se os valores IP e porta estão presentes. Esses valores nunca são definidos por esse código, portanto, presumivelmente, são criados por outro componente. Sem entrar nos detalhes do protocolo de rede, o servidor remoto deve servir uma atualização da nova configuração do . A comunicação é encriptada com RC4, usando uma chave derivada da string ID:f~WdH+K?KD)r*sD4mk usando a função BCryptGenerateSymmetricKey do Windows. A Figura 10 mostra o conteúdo do ficheiro de configuração.

do

A Tabela 2 descreve os valores importantes utilizados a partir deste ficheiro, listados pela ordem em que aparecem no ficheiro de configuração (Figura 10).

Quadro 2. Descrição da configuração donewtalbe

Utilizando o valor URL hostapi deste ficheiro, é efectuado um pedido HTTP GET através de TLS com uma cadeia genérica User-Agent. Os dados recebidos são desencriptados utilizando RC4 com o valor hostapikey ; este contém um dicionário de nomes de anfitriões relacionados com jogos com o seu endereço resolvido correspondente.

Uma vez feitas estas actualizações, o instalador envia a configuração newtalbe actualizada para o controlador, emitindo um pedido de I/O com o código de controlo 0x9C400BFC.

Finalmente, o malware itera sobre a lista de pontos finais fornecidos pelo elemento JSON apiurl e para cada um deles cria uma cadeia de caracteres formatada em JSON contendo informações sobre o computador comprometido, encripta-a com RC4 usando a chave Abc123!@#&XM derivada através da API do Windows BcryptGenerateSymmetricKey, e envia as informações recolhidas para o servidor remoto através de um pedido HTTP POST. As informações recolhidas incluem o nome do computador, o endereço MAC da interface de rede, a versão do sistema operativo e as dimensões do ecrã.

Controlador do injetor

O principal objetivo do controlador é injetar bibliotecas nas aplicações do browser e alterar o seu fluxo de execução para alterar o URL acedido ou abrir uma página num novo separador. São criadas duas threads para tratar os pedidos de abertura de um novo separador e de injeção de bibliotecas utilizando o projeto Blackbone, disponível publicamente. Além disso, as rotinas de notificação de criação de processos e carregamento de imagens são definidas para monitorar processos recém-criados e imagens executáveis sendo carregadas. A lógica simplificada do driver é ilustrada na Figura 11.

simplificada do controlador

Por uma razão desconhecida, o controlador começa por apagar a sua imagem do disco. Depois, cria um objeto de dispositivo chamado \\ .\KNewTableBaseIo e define a sua rotina IRP_MJ_DEVICE_CONTROL para tratar os vários pedidos de E/S listados na Tabela 3. Os códigos de controlo (IOCTL) utilizados para configurar ou definir as bibliotecas injectadas só podem ser chamados uma vez; por conseguinte, as definições não podem ser actualizadas. Estes códigos de controlo especiais são protegidos pela verificação de que o caminho do ficheiro do chamador corresponde à expressão regular *ShieldNetWork\\Business\\DwBusiness_*.

Tabela 3. Lista de IOCTLs disponíveis e respectiva descrição

Ao tratar os códigos de controlo 0x9C400BFC e 0x9C40173C, o controlador itera sobre os módulos carregados de todos os processos em execução. Se for encontrado um dos módulos alvo listados na configuração chromedll , é colocado em fila de espera um pedido para injetar uma biblioteca nesse processo.

Finalmente, o driver termina sua inicialização criando duas threads e configurando as rotinas de notificação mencionadas acima.

É importante notar que a configuração hotPage nunca é definida. Quaisquer menções a este ficheiro são apenas feitas para descrever como seria utilizado de acordo com o fluxo de controlo do controlador. Essencialmente, a configuração hotPage é usada para redirecionar o utilizador para uma página específica (ou homepage) cheia de anúncios quando um browser alvo é iniciado.

A versão do software que analisámos dependia apenas das configurações chromedll e newtalbe para conseguir a sua injeção de anúncios.

Tópico de injeção da biblioteca

Esta thread verifica os pedidos de injeção em fila de espera e, para cada um deles, liga-se ao processo alvo através de KeStackAttachProcess, atribui pedaços de memória e copia o seu código de shell. Utilizando a função ZwCreateThreadEx da biblioteca Blackbone, o controlador chama o shellcode, que implementa o seu próprio carregador PE e chama o ponto de entrada da biblioteca injectada.

Nova thread de separador

A segunda thread utiliza a mesma lógica; no entanto, o shellcode injetado é diferente. Chama a função CreateProcessW da API do Windows com o parâmetro de linha de comando sendo o nome do processo alvo concatenado com o URL que deve ser aberto. Este último é constituído pelo URL seguido da soma das variáveis idindex e userid da configuração hotPage . Por exemplo, a configuração mostrada na Figura 12 criaria a string https://www.hao774[.]com/?90386-00001. Uma vez que os navegadores baseados no Chromium criam um novo processo para cada novo separador, a criação de um processo a partir do processo do navegador criará efetivamente um novo separador.

A Figura 12 mostra o conteúdo do arquivo de configuração hotPage .

do

Este ficheiro de configuração contém a lista de navegadores Web visados e os parâmetros da linha de comandos que determinam se o processo deve ser injetado. Os nomes de domínio estão relacionados com anúncios de jogos ou com a manutenção de cibercafés.

Rotina de notificação de criação de processos

Essencialmente, esta rotina assegura que a página inicial da nova instância do navegador Web é redireccionada para um URL específico presente na configuração hotPage . Esta secção descreve como o driver implementa esta funcionalidade mesmo que não seja utilizada, uma vez que esta versão do instalador nunca envia esta configuração para o driver.

Dependendo das seguintes condições, o processo do navegador web será marcado como elegível para abrir o URL na configuração hotPage:

• esta é a primeira instância do navegador e não um novo separador que está a ser aberto,
• o caminho do ficheiro do processo corresponde a uma das expressões regulares na lista do browser na configuração hotPage ,
• a linha de comando do processo não corresponde a nenhuma expressão regular na lista wlist da configuração hotPage , e
• se a linha de comando do processo incluir o seu próprio caminho de ficheiro, não deve corresponder a nenhuma expressão regular na lista ppwlist da configuração hotPage .

Conforme detalhado na próxima secção, quando o processo do navegador começa a carregar as primeiras imagens executáveis, é colocado em fila de espera um pedido para abrir um novo separador. A Figura 13 e a Figura 14, respetivamente, mostram a diferença entre o diretório Web legítimo 2345[.]com e a página com anúncios apresentada ao utilizador.

Rotina de notificação de carregamento de imagens

Esta rotina lida essencialmente com dois tipos de cenários. Se a imagem que está a ser carregada estiver na lista chromedll , é colocada em fila uma rotina APC que carregará uma das bibliotecas de hooking através do seu próprio carregador PE.

Caso contrário, se o processo foi marcado como elegível para abrir uma nova página, o malware consegue fazê-lo abrindo-a num novo separador ou no separador atual. Se o nome do ficheiro do processo corresponder a uma das expressões regulares na lista browser1 da configuração hotPage , um pedido para abrir um novo separador é colocado em fila de espera e será tratado pela thread apropriada (note-se que o elemento da lista browser1 não estava presente no ficheiro de configuração que recuperámos). No outro caso, a página será aberta no separador que está a ser criado, colocando em fila de espera um work item (via IoQueueWorkItemEx) que modificará a linha de comando do processo que está a ser criado. Este último se anexa ao processo, encontra o endereço de exportação de GetCommandLineA e GetCommandlineW dentro da biblioteca kernelbase.dll e modifica a string Unicode armazenada em BaseAnsiCommandLine. A linha de comando é substituída pelo caminho do ficheiro executável do processo concatenado com o URL na configuração hotPage . A Figura 15 mostra uma comparação lado a lado do código responsável por encontrar o buffer da linha de comando e a desmontagem da função GetCommandLineA .

ontagem

Biblioteca injectada

A primeira coisa que a biblioteca injectada faz é obter as configurações hotPage e newtalbe consultando o controlador. Se o nome de ficheiro do browser injetado for 360Chrome, elimina a chave de registo HKCU\Software\360chrome\Homepage e corrige o ficheiro Preferences (localizado no diretório predefinido do browser 360chrome\chrome\User Data\Default\Preferences) para que a página inicial aponte para o valor URL da configuração hotPage.

Utilizando a biblioteca de hooking Microsoft Detours, a amostra faz hooking a SetProcessMitigationPolicy para que esta devolva 1, de modo a impedir que as políticas de segurança sejam aplicadas ao processo, permitindo assim a injeção de código. Em seguida, o getaddrinfo é ligado para forçar o navegador a resolver certos nomes de anfitrião para endereços IP específicos para garantir que o redireccionamento é feito para o servidor correto no caso de os nomes de domínio já não existirem.

Enganchamento de SSL_read e SSL_write

O malware faz hook às funções SSL_read e SSL_write para permitir a manipulação do tráfego TLS desencriptado do navegador; fá-lo procurando padrões específicos dentro dos módulos carregados, uma vez que estas funções não são exportadas. Por exemplo, o dicionário chromewrite dentro da configuração chromedll contém dois tipos de padrões, sslcode e oldchrome, como visto na Figura 16. Eles são, respetivamente, usados para encontrar versões mais recentes e mais antigas da função DoPayloadWrite. Testámos e confirmámos que os padrões correspondem à biblioteca do Microsoft Edge msedge.dll versão 122.0.2365.80.

O valor do modo é utilizado para determinar a versão do padrão, 32 ou 64 bits; o valor do código é o padrão de bytes atual e o deslocamento é a distância entre o início do padrão e o ponteiro para a função SSL_write (ver Figura 17).

iro para a

Uma vez que SSL_write e SSL_read são encontrados, eles são conectados usando a biblioteca Detours. No caso da primeira, o malware inspecciona os dados e depois chama a função original, que os encripta e envia. Quanto à segunda, a biblioteca injectada faz o contrário para manipular os dados desencriptados. Para ambas as funções, os dados são inspeccionados pelo código que manipula, respetivamente, os códigos de controlo AFD_SEND e AFD_RECV na função que liga o NtDeviceIoControlFile.

Ligação ao NtDeviceIoControlFile e inspeção dos dados de entrada e de saída

A biblioteca maliciosa liga a função NtDeviceIoControlFile para manipular códigos IOCTL específicos, como se pode ver na Figura 18.

Para o código de controlo 0x12023(AFD_SEND_DATAGRAM usado ao enviar pacotes UDP), o malware cancela quaisquer pedidos DNS devolvendo STATUS_INVALID_PARAMETER se o número da porta remota for 53. Isto assegura que o navegador Web apenas utiliza os anfitriões fornecidos pela configuração do newtalbe .

A rotina que trata o código de controlo 0x1201F (AFD_SEND) começa por extrair o URL e o cabeçalho Referrer do pedido. Com base no facto de o URL corresponder a determinados valores nas configurações newtalbe e hotPage, o malware executa acções variadas, conforme descrito na Tabela 4. Nalguns casos, o pedido é enviado, mas a resposta é modificada na rotina que manipula o código de controlo AFD_RECV através de diferentes métodos de redireccionamento explicados mais adiante.

Quadro 4. Lista de acções realizadas em determinadas condições no envio de pedidos HTTP

Para o código de controlo 0x12017(AFD_RECV), o malware começa por recuperar os dados recebidos pelo cliente e verifica se a resposta foi marcada como elegível para redireccionamento. Existem quatro tipos de redireccionamentos, conforme descrito na Tabela 5. A cadeia xxx na resposta modificada é alterada para o URL na nova configuração .

Tabela 5. Métodos de redireccionamento

A Figura 19 ilustra o método de redirecionamento 0 sendo aplicado após a navegação para um URL que corresponde a um dos padrões de URL do blist da configuração newtalbe (www.5zy[.]cn). Outro separador é aberto e aponta para o URL especificado na mesma configuração.

Problemas de segurança e escalonamento de privilégios

Ao inicializar o seu objeto de dispositivo, o controlador não especifica quaisquer listas de controlo de acesso(ACLs) para restringir quem pode comunicar com ele; por conseguinte, qualquer pessoa pode enviar-lhe pedidos de E/S. Como mencionado anteriormente, alguns códigos de controlo de E/S requerem que o processo requerente esteja num caminho que corresponda ao regex:

*ShieldNetWork\\Business\\DwBusiness_*

Isto não é claramente suficiente para verificar se o processo de comunicação é um dos componentes da HotPage e pode ser facilmente contornado criando os directórios necessários numa pasta gravável pelo utilizador.

Criámos dois cenários que permitiriam a um utilizador com o controlador HotPage em execução no seu sistema executar código como a conta NT AUTHORITY\System. Criámos um script de prova de conceito (PoC) em Python para alcançar ambos os cenários.

Cenário #1: Escalonamento de privilégios via injeção arbitrária de DLL em processos arbitrários

Neste primeiro cenário, assumimos que o driver foi carregado, mas que a configuração do chromedll e as bibliotecas para injetá-lo não foram definidas. Nesse caso, é possível criar e definir nossa própria biblioteca para injetar. Criamos uma pequena biblioteca que simplesmente registraria o PID do processo injetado, se ele está sendo executado com privilégios de administrador e o caminho do arquivo do processo injetado.

Como visto na captura de tela do arquivo de log na Figura 20, muitos processos foram injetados com nossa biblioteca, incluindo processos com privilégios de administrador.

Arquivo de

Deve-se notar, no entanto, que os processos protegidos não podem ser injetados usando essa técnica.

Cenário nº 2: Escalonamento de privilégios por meio da alteração da linha de comando de processos recém-criados

No primeiro cenário, contámos com o facto de que tanto as bibliotecas injectadas como a configuração chromedll não estavam definidas, mas, como se vê na análise do instalador, ambas são definidas assim que o controlador é inicialmente carregado. No entanto, a configuração hotPage nunca é definida. Com base na análise do fluxo de controlo, concebemos uma forma de aproveitar a lógica das rotinas de notificação de criação de processos e carregamento de imagens do controlador para executar novamente o mesmo executável, mas com uma linha de comando diferente.

Sob certas condições, como explicado nas secções Rotina de notificação de criação de processos e Rotina de notificação de carregamento de imagens, o controlador pode abrir um novo separador apontando para o URL presente na configuração hotPage. Isto é conseguido substituindo a linha de comando do processo do navegador recém-criado ou duplicando o processo do navegador e alterando a sua linha de comando para o URL na configuração hotPage. Se especificarmos qual o processo que pode ser duplicado e a nova linha de comando, podemos conseguir um escalonamento de privilégios visando um processo com privilégios SYSTEM, por exemplo.

Conclusão

A análise desta peça de malware de aspeto bastante genérico provou, mais uma vez, que os criadores de adware ainda estão dispostos a ir mais longe para atingir os seus objectivos. Além disso, desenvolveram um componente do kernel com um grande conjunto de técnicas para manipular processos, mas também passaram pelos requisitos impostos pela Microsoft para obter um certificado de assinatura de código para o seu componente de driver.

O driver HotPage nos lembra que o abuso de certificados de Verificação Estendida ainda é uma coisa. Uma vez que muitos modelos de segurança se baseiam, em certa medida, na confiança, os agentes de ameaças tendem a jogar na linha que separa o legítimo do duvidoso. Quer esse software seja anunciado como uma solução de segurança ou simplesmente incluído num pacote com outro software, as capacidades concedidas graças a essa confiança expõem os utilizadores a riscos de segurança.

Por mais irritante que o adware possa ser, as vulnerabilidades introduzidas por este malware deixam o sistema aberto a ameaças ainda mais perigosas. Um atacante com uma conta sem privilégios pode aproveitar o driver vulnerável para obter privilégios de SISTEMA ou injetar bibliotecas em processos remotos para causar mais danos, tudo isto enquanto utiliza um driver legítimo e assinado.

As tecnologias da ESET detectam essa ameaça - que a Microsoft removeu do Catálogo do Windows Server em^1º de maio de 2024 - como Win{32|64}/HotPage.A e Win{32|64}/HotPage.B.

Para qualquer dúvida sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco em threatintel@eset.com.

A ESET Research oferece relatórios privados de inteligência de APT e feeds de dados. Para qualquer dúvida sobre este serviço, visite a página ESET Threat Intelligence.

IoCs

Uma lista abrangente de IoCs e amostras pode ser encontrada em nosso repositório GitHub.

Ficheiros

Rede

Técnicas MITRE ATT&CK

Esta tabela foi construída utilizando a versão 15 da estrutura MITRE ATT&CK.