Rootkit Festi retorna com dropper falso de Adobe Flash Player e indícios de recompilação

Nova atividade do rootkit para Windows usa distribuição pelo RIG exploit kit, elevação via janela falsa de atualização e driver em modo núcleo com alterações de código.

Componente	Festi, rootkit para Windows operando como driver em modo núcleo, com dropper que decodifica e instala o driver malicioso.
Vetor	Distribuição observada principalmente pelo RIG exploit kit; quando não possui privilégios suficientes, o dropper simula uma atualização do Adobe Flash Player para induzir aprovação no UAC.
Impacto	Instalação de driver persistente no sistema, interceptação de IRPs, uso de configuração cifrada, comunicação com C&C e mecanismo DGA de contingência.
Prioridade	Investigar endpoints Windows com execução de atualizadores falsos, criação de serviço de driver, artefatos em system32\drivers, evento Global\irp65289 e atividade de rede compatível com C&C ou DGA.
Artefatos	Foram associados quatro hashes SHA-256 de droppers; a publicação técnica também descreve um arquivo temporário de limpeza usado para apagar o dropper e a si próprio.
Alcance	A telemetria citada indica alguns milhares de infecções, com maior concentração observada na Turquia e no Brasil.

Resumo técnico

Festi voltou a aparecer em atividade após um longo período sem sinais públicos de operação. O malware é um rootkit de Windows conhecido desde 2009, originalmente associado a uma botnet usada para DDoS e envio de spam. A atividade mais recente mantém a lógica de instalação em modo núcleo, mas chega acompanhada por um dropper renovado e por mudanças internas que apontam para recompilação do código. A distribuição observada ocorre principalmente pelo RIG exploit kit, o que coloca a exposição inicial no navegador, em plugins vulneráveis ou em cadeias de entrega que exploram o ambiente do usuário antes da instalação do componente em modo núcleo.

A cadeia atual combina exploração ou entrega inicial com engenharia social para elevação de privilégio. Quando o dropper não tem permissão suficiente para instalar o driver, ele exibe uma janela falsa de atualização do Adobe Flash Player. A interface tenta parecer legítima, incluindo elementos como links para detalhes e contrato de licença apontando para páginas reais da Adobe. A intenção técnica é fazer com que o usuário aprove o prompt de UAC, permitindo que o instalador registre e carregue o driver malicioso. Se o usuário escolhe adiar a instalação, o dropper encerra a execução e apaga a si mesmo, comportamento compatível com uma operação cautelosa que evita insistência ruidosa no host.

A relevância defensiva está no retorno de uma família antiga com sinais de manutenção ativa. As amostras recentes preservam partes da lógica central, como inicialização do driver, uso de configuração cifrada, rotina de despacho para funções principais e mecanismo DGA, mas removem ou modificam alguns trechos presentes em versões mais antigas. As diferenças não parecem apenas empacotamento externo: há alterações em funções de decodificação e em detalhes do algoritmo de geração de domínios. Esse conjunto sugere que o operador atual provavelmente teve acesso ao código-fonte ou a uma base de código suficientemente completa para recompilar e alterar funcionalidades.

Fluxo técnico

O dropper contém o rootkit codificado em sua própria seção de dados. Depois de obter privilégios, ele abre o evento nomeado Global\irp65289, extrai o driver embutido, decodifica o conteúdo e salva o componente no diretório de drivers do Windows com nome compatível com serial.sys. A carga é então registrada e iniciada como driver de kernel por meio de funções WinAPI resolvidas em tempo de execução, incluindo CreateServiceA e StartServiceA. Antes de terminar, o dropper grava um arquivo em lote de limpeza em %TEMP% com nome aleatório; esse arquivo remove o dropper e depois elimina a si próprio, reduzindo a quantidade de artefatos diretos no disco.

O driver do Festi é escrito em C++ e roda em modo núcleo, carregado junto com drivers comuns do sistema durante a inicialização. Na entrada do driver, a amostra executa rotinas de inicialização necessárias ao funcionamento do rootkit: decodifica uma seção de configuração embutida, atribui uma rotina de despacho para a maioria das funções principais, anexa-se ao dispositivo SystemRoot para interceptar IRPs antes que eles cheguem a filtros posteriores e inicia a thread principal de trabalho do malware. Esse desenho coloca a atividade em uma camada de observabilidade mais difícil para ferramentas de usuário e amplia a necessidade de telemetria de kernel, EDR e integridade de drivers.

As variantes novas mantêm uma estrutura geral parecida com amostras antigas, mas removem alguns controles de ambiente. Versões anteriores faziam checagens de VMware, Virtual PC e presença de npf.sys, driver usado pelo Wireshark. Esses testes não aparecem na versão mais recente descrita. O rootkit ainda verifica a presença de depurador por meio de KD_DEBUGGER_ENABLED, mas a checagem adicional para o objeto \Driver\NTICE, associada ao SoftICE, também não está presente. A ausência desses pontos pode indicar uma decisão deliberada de simplificação, uma base de código mais antiga ou alterações feitas durante recompilação.

A comunicação de contingência usa uma função DGA quando o domínio C&C codificado não responde. A estrutura do algoritmo continua baseada em uma data usada como semente para gerar domínios .com de 12 caracteres. Cada parte da semente é convertida em caractere por funções de mapeamento predefinidas. Nas amostras novas, a ordem dos argumentos da semente e os próprios mapeamentos foram alterados. A rotina também incorpora uma operação XOR envolvendo um valor de pilha e BugCheckParameter2, usado por KeBugCheckEx. A seção de configuração também mudou: em vez de aplicar XOR com um valor fixo sobre toda a seção, a versão nova usa uma implementação embutida de crand() para gerar fluxo de chave e decodificar dados como strings de dispositivos, domínios C&C, nomes de funções e chaves de registro.

Superfície afetada

A superfície principal envolve estáções Windows expostas à cadeia de entrega do RIG exploit kit e usuários que podem ser induzidos a aprovar uma falsa atualização do Adobe Flash Player. O componente crítico não é apenas o executável inicial, mas a transição para driver em modo núcleo. Uma vez instalado, o rootkit passa a operar com privilégios elevados e persistência no processo de inicialização, criando uma condição em que remoção manual incompleta pode deixar o ambiente instável ou permitir que partes da atividade continuem fora da visibilidade de ferramentas tradicionais.

Ambientes com usuários locais que possuem capacidade de aprovar UAC, estáções com controles fracos de execução de binários baixados e endpoints sem política rígida de carregamento de drivers ficam mais expostos ao fluxo descrito. A presença de links legítimos dentro da janela falsa aumenta a credibilidade visual da fraude, mas o ponto defensivo central é o comportamento posterior: criação de serviço para driver, escrita em diretório de drivers, resolução dinâmica de APIs de serviço e limpeza do executável inicial. A concentração de infecções observada na Turquia e no Brasil também torna útil revisar telemetria histórica nessas regiões, quando disponível.

O histórico do Festi amplia o risco operacional. A família já foi usada em uma botnet com funções de DDoS e spam, e a arquitetura modular permite personalizar funcionalidades por plugins. A atividade descrita não confirma por si só uma campanha nova com o mesmo volume da botnet antiga, nem confirma a identidade do operador atual. O dado técnico sustentado é que o malware reapareceu, foi observado em milhares de infecções e apresenta alterações compatíveis com acesso ao código ou recompilação de uma base original.

• Endpoints Windows que receberam execução de dropper apresentado como atualização do Adobe Flash Player.
• Sistemas onde houve aprovação de UAC seguida de instalação de driver em modo núcleo.
• Hosts com artefatos compatíveis com Global\irp65289, arquivo de driver em system32\drivers e arquivo temporário de limpeza.
• Ambientes com tráfego de saída para C&C codificado ou domínios gerados por DGA quando o domínio principal falha.

Hunting e telemetria

A investigação deve combinar telemetria de endpoint, eventos de serviço, criação de arquivos em diretórios sensíveis e comportamento de rede. No host, procure sequências em que um processo de usuário com aparência de atualizador solicita elevação, cria ou inicia serviço de driver e grava um arquivo em diretório de drivers do Windows. A resolução em tempo de execução de CreateServiceA e StartServiceA não é isoladamente maliciosa, mas ganha peso quando aparece junto de binário temporário, nome aleatório em %TEMP%, limpeza automática e ausência de cadeia legítima de assinatura ou distribuição.

A caça também deve incluir eventos nomeados e indicadores de persistência em modo núcleo. O evento Global\irp65289 é um marcador de execução citado para o dropper. A existência de um driver com nome similar a serial.sys em local sensível deve ser validada com metadados, assinatura, data de criação e relacionamento com serviços registrados. O objetivo não é tratar qualquer arquivo parecido como compromisso confirmado, mas correlacionar instalação recente, origem do processo, hash conhecido, ausência de assinatura esperada e atividade de rede subsequente.

Na rede, a lógica de DGA exige observar padrões de resolução que não dependem apenas de uma lista estática de domínios. A função descrita gera domínios .com de 12 caracteres a partir de uma semente baseada em data. Isso favorece detecções por forma, frequência e correlação temporal, especialmente quando um host tenta resolver muitos nomes curtos e aparentemente aleatórios depois de falha em um destino C&C codificado. Como a publicação técnica menciona domínios e strings dentro da configuração cifrada, a análise de memória e extração controlada de configuração podem ajudar, mas devem ser feitas em laboratório isolado.

• Criação ou inicialização de serviço de driver logo após uma janela de atualização do Adobe Flash Player fora do fluxo oficial de atualização.
• Abertura do evento nomeado Global\irp65289 durante a fase de instalação do dropper.
• Arquivo de limpeza em %TEMP% com nome aleatório, responsável por apagar o dropper e depois remover a si próprio.
• Driver recém-criado em system32\drivers, especialmente quando associado a processo temporário, UAC aprovado e metadados incompatíveis com fornecedor legítimo.
• Consultas DNS para domínios .com de 12 caracteres com aparência pseudoaleatória, principalmente quando repetidas por um host que também tentou alcançar C&C codificado.

Mitigação

A resposta deve começar pela contenção do endpoint suspeito, porque um rootkit em modo núcleo pode interferir na visibilidade e na confiabilidade de ferramentas executadas no próprio sistema comprometido. Isole a máquina da rede, preserve artefatos de disco e memória quando houver capacidade forense e valide a presença de serviços de driver criados recentemente. A remoção deve considerar que o dropper tenta apagar rastros, então eventos de criação de processo, logs de EDR, registros de serviço e telemetria de armazenamento são mais valiosos do que depender apenas do executável inicial ainda estar presente.

A prevenção passa por reduzir a chance de execução e elevação do dropper. Políticas de controle de aplicação, bloqueio de instalação de drivers não autorizados, validação de assinatura, restrição de privilégios locais e regras de UAC alinhadas ao risco ajudam a quebrar a transição entre entrega inicial e persistência em modo núcleo. Como a engenharia social usa uma atualização falsa do Adobe Flash Player, a defesa também deve remover dependências legadas quando possível e garantir que atualizações de software ocorram por canais gerenciados, não por prompts originados em navegação ou execução transitória.

Depois da contenção, revise a telemetria de rede para identificar hosts com comportamento parecido, principalmente consultas DGA e conexões para infraestrutura C&C defangada ou resumida em inteligência interna. Se forem encontrados hashes de droppers conhecidos, use-os como ponto de partida, não como limite da investigação, porque a própria análise indica variantes recompiladas. A validação final deve confirmar ausência de serviços de driver suspeitos, ausência de eventos nomeados associados ao instalador, inexistência de novos artefatos em diretórios de drivers e normalização do padrão DNS do host afetado.

• Isolar endpoints suspeitos antes de tentar remoção local do driver ou do serviço associado.
• Coletar memória, metadados de driver, eventos de serviço, histórico de UAC e registros de criação de arquivos em system32\drivers e %TEMP%.
• Bloquear carregamento de drivers não autorizados e reforçar políticas de assinatura e controle de aplicação.
• Investigar domínios gerados por DGA e tráfego C&C sem publicar links ativos ou listas extensas de infraestrutura.
• Tratar hashes conhecidos como indicadores auxiliares e manter detecção comportamental para variantes recompiladas.