FinSpy infecta por meio de bootkits resistentes à reinstalação do SO

05/10/2021 mindsecblog Notícias 2

FinSpy infecta por meio de bootkits resistentes à reinstalação do SO ou mesmo à formatação ou substituição da mídia.

O FinSpy, também conhecido como FinFisher ou Wingbird, é um spyware (tipo de malware usado para espionagem) composto por um conjunto poderoso de ferramentas de vigilância. Capaz de espionar praticamente tudo dentro da máquina e de coletar diversas informações de usuário, o FinSpy foi atualizado para controlar computadores desde o sistema de boot.

Ou seja, ele age naquele processo de inicialização de uma máquina até o carregamento do sistema operacional, fazendo com que nem a formatação do computador resolva o problema.

Especialistas da Kaspersky, empresa de segurança digital, estudam o FinSpy desde 2011, quando seu modo de ação era por meio de instaladores adulterados de aplicativos legítimos, como TeamViewer, VLC e WinRAR. As atualizações subsequentes em 2014 permitiram infecções por meio de bootkits Master Boot Record (MBR), com o objetivo de injetar um carregador malicioso de uma maneira projetada para se passar por ferramentas de segurança.

A nova capacidade do FinSpy é de infectar o bootkit da interface UEFI (Interface Unificada de Firmware Extensível) e substituir o bootloader do Windows por uma variante maliciosa para carregar o spyware. A interface de firmware UEFI é uma melhoria em relação ao sistema básico de entrada/saída (BIOS) com suporte para inicialização segura. Ela age na integridade do sistema operacional para garantir que nenhum malware interfira no processo de inicialização.

Como a UEFI também facilita o carregamento do próprio sistema operacional, as infecções de bootkit são resistentes à reinstalação do SO ou mesmo à formatação ou substituição da mídia – trocar o drive, seja disco rígido ou SSD. Além disso, elas são imperceptíveis para as soluções de segurança em execução no sistema operacional.

Infecção UEFI

Durante nossa pesquisa, os especialistas encontraram um bootkit UEFI que carregava FinSpy. Todas as máquinas infectadas com o bootkit UEFI tiveram o gerenciador de inicialização do Windows ( bootmgfw.efi ) substituído por um malicioso. Quando o UEFI transfere a execução para o carregador malicioso, ele primeiro localiza o Gerenciador de inicialização do Windows original. Ele é armazenado dentro do diretório efi \ microsoft \ boot \ en-us \ , com o nome consistindo em caracteres hexadecimais. Este diretório contém mais dois arquivos: o Winlogon Injector e o Trojan Loader. Ambos são criptografados com RC4. A chave de descriptografia é o GUID da partição do sistema EFI, que difere de uma máquina para outra.

$Conteúdo de amostra do diretório \ efi \ microsoft \ boot \ en-us \$

Conteúdo de amostra do diretório \ efi \ microsoft \ boot \ en-us \

Assim que o bootloader original é localizado, ele é carregado na memória, corrigido e iniciado.

O launcher alterado:

Corrige a função do carregador do SO que transfere a execução para o kernel
A função corrigida conecta a função PsCreateSystemThread do kernel , que, quando chamada pela primeira vez, cria uma thread adicional que descriptografa o próximo estágio do carregador e o inicia.

O próximo estágio:

Localiza o arquivo do carregador do cavalo de Tróia na partição EFI e o descriptografa
Espera até que um usuário faça logon e injete o carregador de Trojan no exe.

O carregador de Trojan:

Extrai o Trojan dos recursos e o coloca sob o nome dll
Descriptografa o cavalo de Tróia com uma cifra baseada em XOR e o descompacta com aPLib
Carrega e inicia o Trojan de maneira reflexiva.

Infecção MBR

Máquinas mais antigas que não oferecem suporte a UEFI podem ser infectadas por meio do MBR. Quando a máquina vítima é inicializada, o MBR infectado copia o código do carregador inicial do último megabyte do disco rígido para a memória mais alta disponível localizada antes do EBDA. Este código intercepta as interrupções do BIOS de 13h e 15h e, em seguida, inicia o MBR original. A interrupção de 15h garante que o carregador do Windows não substitua o código copiado. Quando essa interrupção é chamada para obter o tamanho da área antes do EBDA, o gancho reduzirá a quantidade de memória disponível. Quanto a interrupção 13h (que gerencia a leitura de informações do disco), ele corrige o carregador do SO quando ele é lido do disco. Assim como no caso da infecção EFI, as funções colocam seus próprios hooks em outros estágios de carregamento do sistema operacional. O último hook na cadeia cria um thread no kernel que injeta o próximo estágio em winlogon.exe .

Caso a infecção seja instalada em uma máquina de 32 bits, o processo de injeção de código no winlogon.exe é mais complexo do que o observado na infecção UEFI. É o seguinte:

Um segmento com código de shell de trampolim é criado dentro do exe.
Este shellcode duplica o identificador do processo exe e o transfere para o explorer.exe .
O shellcode injeta outro shellcode trampolim no Explorer.
O segundo shellcode faz com que o exe injete o carregador do Trojan de volta no winlogon.exe .

Essa forma indireta de injetar código tem como objetivo enganar as soluções de segurança.

O carregador de Trojan injetado é igual ao UEFI.

Infecção do modo de usuário

Visão geral

Esta infecção é de longe a mais complexa. Resumindo, o cenário de ataque é o seguinte:

A vítima baixa um aplicativo com Trojan e o executa.
Durante seu curso normal de operação, o aplicativo se conecta a um servidor C2, baixa e, em seguida, inicia um componente não persistente denominado Pré-validador. O pré-validador garante que a máquina da vítima não seja usada para análise de malware.
O pré-validador baixa os códigos de shell de segurança do servidor C2 e os executa. No total, ele implanta mais de 30 códigos de shell. Cada shellcode coleta informações específicas do sistema (por exemplo, o nome do processo atual) e as carrega de volta para o servidor.
Caso a verificação falhe, o servidor C2 encerra o processo de infecção. Caso contrário, ele continua enviando códigos de shell.
Se todas as verificações de segurança forem aprovadas, o servidor fornece um componente que os especialistas chamam de Post-Validator. É um implante persistente provavelmente usado para garantir que a vítima é a vítima. O Post-Validator coleta informações que permitem identificar a máquina vítima (processos em execução, documentos abertos recentemente, capturas de tela) e a envia para um servidor C2 especificado em sua configuração.
Dependendo das informações coletadas, o servidor C2 pode comandar o Pós-validador para implantar a plataforma de cavalo de Tróia completa ou remover a infecção.