Qilin e Warlock usam drivers vulneráveis para desativar ferramentas de EDR

Qilin e Warlock usam drivers vulneráveis para desativar ferramentas de EDR

Operações de ransomware adotam BYOVD para interferir em proteções de endpoint, encerrar componentes de segurança e sustentar ações pós-comprometimento em hosts Windows.

ComponenteHosts Windows comprometidos por operações Qilin e Warlock, com uso de DLL maliciosa, drivers vulneráveis e ferramentas de tunelamento.
VetorTécnica BYOVD após comprometimento inicial; no caso Qilin, cadeia iniciada por DLL side-loading de msimg32.dll; no caso Warlock, exploração de servidores Microsoft SharePoint sem correção e uso de driver vulnerável.
ImpactoDesativação ou interferência em produtos de EDR, encerramento de drivers de segurança, supressão de telemetria e aumento da janela para persistência, movimentação lateral e execução de ransomware.
PrioridadeRestringir carregamento de drivers a publicadores explicitamente confiáveis, monitorar instalação de drivers, revisar atividade em nível de núcleo e corrigir servidores SharePoint expostos.
Artefatosmsimg32.dll, NSecKrnl.sys, googleApiUtil64.sys, rwdrv.sys, ThrottleStop.sys e hlpdrv.sys aparecem no contexto da atividade observada.
FerramentasTightVNC, Visual Studio Code, Cloudflare Tunnel e Yuze foram observados em atividade Warlock para controle persistente, tunelamento, proxy reverso e comunicação com infraestrutura do operador.
Resumo técnico

Operações associadas aos ransomware Qilin e Warlock foram observadas usando a técnica conhecida como BYOVD, em que o invasor leva para o ambiente comprometido um driver legítimo, porém vulnerável, para obter capacidade de interferência em camadas privilegiadas do sistema. O objetivo operacional descrito é reduzir a eficácia de ferramentas de detecção e resposta em endpoint antes das fases de maior impacto, especialmente encerramento de processos, neutralização de componentes de segurança e preparação para execução de ransomware. A atividade não depende apenas de um binário malicioso isolado: ela combina carregamento de DLL, execução em memória, manipulação de telemetria, abuso de drivers e ferramentas legítimas que podem se confundir com administração remota ou desenvolvimento.

No fluxo atribuído ao Qilin, a cadeia começa com uma DLL maliciosa chamada msimg32.dll, acionada por DLL side-loading. Esse componente atua como carregador inicial e prepara o ambiente para um segundo payload voltado a interromper produtos de EDR. O payload secundário fica embutido no carregador em forma criptografada e é decriptado e executado em memória. A técnica reduz a exposição do artefato em disco e dificulta a inspeção por mecanismos que dependem de coleta estática. O componente também aplica evasões em modo usuário, interfere em registros de Event Tracing for Windows e tenta ocultar padrões de chamada de API e fluxo de controle.

No conjunto Warlock, também identificado como Water Manaul, a atividade envolve servidores Microsoft SharePoint sem correção como ponto de exploração, além de uma atualização do conjunto de ferramentas para persistência, movimentação lateral e evasão de defesa. A operação passou a usar o driver vulnerável NSecKrnl.sys em ataque BYOVD para terminar produtos de segurança em nível de núcleo, substituindo o driver googleApiUtil64.sys observado em campanhas anteriores. A presença de TightVNC, Visual Studio Code, Cloudflare Tunnel e Yuze indica uma cadeia pós-comprometimento orientada a controle remoto, tunelamento de tráfego e estabelecimento de proxy reverso.

A relevância defensiva está na mudança de camada do ataque. Quando a interferência chega ao núcleo do sistema, controles de endpoint que operam principalmente em modo usuário podem perder visibilidade, sofrer manipulação de callbacks ou ser encerrados antes de gerar alerta útil. Isso não significa que todos os ambientes com EDR estejam automaticamente comprometidos, mas indica que a governança de drivers, a integridade do núcleo, a atualização de componentes de segurança e a correção de servidores expostos precisam fazer parte da resposta. A detecção deve procurar a sequência completa, não apenas o executável final de ransomware.

Fluxo técnico

A cadeia observada no Qilin começa após o invasor já possuir algum nível de acesso ao host. O contexto indica que o grupo depende principalmente de credenciais roubadas para o acesso inicial e investe em atividades pós-comprometimento antes da etapa de ransomware. Em ataques analisados, a execução do ransomware ocorreu em média aproximadamente seis dias após o comprometimento inicial. Essa janela é defensivamente importante porque a etapa BYOVD tende a acontecer depois da entrada no ambiente, mas antes do impacto final. Ela oferece pontos de detecção em autenticação, movimentação interna, escrita de artefatos, carregamento de bibliotecas, instalação de drivers e alterações anormais em processos de segurança.

O artefato msimg32.dll funciona como ponto de entrada da cadeia Qilin por meio de DLL side-loading. Nessa técnica, um binário legítimo ou um fluxo de execução esperado carrega uma biblioteca controlada pelo invasor em vez de uma biblioteca legítima prevista. O carregador inicial prepara a execução do componente destinado a eliminar ou interferir em soluções de EDR. O payload secundário está embutido de maneira criptografada, o que reduz a exposição direta do código principal durante inspeções simples. Quando executado, o carregador decripta o payload, carrega o conteúdo em memória e evita depender de gravação clara do componente principal em disco.

As evasões descritas para a DLL incluem neutralização de hooks em modo usuário, supressão de eventos de ETW e ocultação de padrões de invocação de APIs. Essas ações têm impacto direto na visibilidade de ferramentas que observam chamadas sensíveis, rastreamento de eventos e comportamento de processos. A cadeia também remove callbacks de monitoramento estabelecidos por produtos de EDR antes do carregamento de um segundo driver, criando condição para terminar processos ou componentes protegidos com menor interferência. O ponto central para defesa é que a desativação do EDR não aparece apenas como encerramento de serviço; ela pode começar com degradação de telemetria e manipulação de mecanismos de observação.

No caso Warlock, o uso de SharePoint sem correção amplia a superfície inicial, enquanto o BYOVD com NSecKrnl.sys desloca parte da evasão para o nível de núcleo. A troca do driver previamente usado, googleApiUtil64.sys, indica adaptação do ferramental. Outros drivers listados no contexto incluem rwdrv.sys, descrito como uma versão renomeada de ThrottleStop.sys, usado para obter acesso à memória física e atuar como camada de acesso a hardware em modo núcleo, e hlpdrv.sys, associado ao encerramento de processos vinculados a mais de 300 drivers de EDR. Essa combinação oferece ao operador um caminho para reduzir proteções antes de ações de controle persistente e movimentação dentro da rede.

As ferramentas adicionais observadas na atividade Warlock cumprem papéis complementares. TightVNC aparece como mecanismo de controle persistente, enquanto Visual Studio Code e Cloudflare Tunnel são usados para tunelar comunicações de comando e controle. Yuze é descrito como ferramenta para penetração em intranet e criação de conexão de proxy reverso para infraestrutura do operador por HTTP na porta 80, HTTPS na porta 443 e DNS na porta 53. Para defesa, esses elementos devem ser interpretados como parte de uma cadeia pós-comprometimento: isoladamente, algumas ferramentas podem ser legítimas, mas combinadas com carregamento de driver vulnerável, alterações em produtos de segurança e atividade em SharePoint sem correção, tornam-se altamente suspeitas.

Superfície afetada

A superfície principal são hosts Windows já comprometidos, especialmente aqueles em que o invasor consegue gravar artefatos, acionar DLL side-loading ou carregar drivers. Como BYOVD depende de permissões suficientes para instalar ou interagir com driver, o risco cresce quando há contas privilegiadas comprometidas, políticas permissivas de carregamento de driver, ausência de controle por publicador confiável e baixa visibilidade sobre eventos de núcleo. O problema também alcança servidores de aplicação usados como ponto de entrada, como Microsoft SharePoint sem correção no caso Warlock, porque esses sistemas podem se tornar trampolim para ações posteriores em estáções e servidores internos.

Ambientes com EDR não devem tratar a presença do produto como garantia de contenção quando há abuso de driver vulnerável. O contexto descreve capacidade de terminar componentes ligados a mais de 300 drivers de EDR, abrangendo múltiplos fornecedores. A defesa precisa considerar que o agente pode sofrer degradação parcial, perda de eventos, falha de comunicação, interrupção de processos auxiliares ou remoção de callbacks antes de gerar um alerta conclusivo. O impacto técnico confirmado no contexto está limitado à desativação ou interferência em controles de endpoint, evasão e sustentação de fases pós-comprometimento; não há base para afirmar vazamento de dados ou escopo de exfiltração a partir do material recebido.

A atividade também afeta equipes de identidade, infraestrutura e resposta a incidentes. O uso de credenciais roubadas pelo Qilin como meio principal de acesso inicial conecta o risco de endpoint à higiene de contas e autenticação. O intervalo médio de cerca de seis dias até a execução de ransomware reforça que sinais anteriores, como autenticações incomuns, implantação de ferramentas remotas, criação de túneis, instalação de driver e falhas súbitas em produtos de segurança, podem ser mais úteis para contenção do que a detecção do binário final.

  • Hosts Windows nos quais o invasor consiga carregar drivers ou executar DLL side-loading.
  • Servidores Microsoft SharePoint sem correção associados ao fluxo Warlock.
  • Produtos de EDR com componentes de driver expostos a encerramento ou interferência por BYOVD.
  • Contas com credenciais roubadas ou permissões suficientes para sustentar ações pós-comprometimento.
  • Ambientes onde TightVNC, Visual Studio Code, Cloudflare Tunnel ou Yuze apareçam sem justificativa administrativa validada.
Hunting e telemetria

A investigação deve começar pela linha do tempo de acesso inicial e evoluir para eventos de endpoint e núcleo. Para Qilin, a presença de msimg32.dll fora de caminhos esperados, carregamento incomum dessa biblioteca por processos que normalmente não deveriam depender dela e execução em cadeia com sinais de DLL side-loading são pontos de partida. A telemetria deve correlacionar criação ou modificação de DLL, processo pai, usuário autenticado, host de origem, hash interno se disponível e alteração simultânea em agentes de segurança. O objetivo não é publicar um indicador único como definitivo, mas detectar a sequência: biblioteca suspeita, preparação de ambiente, redução de telemetria e tentativa de encerrar componentes de EDR.

Eventos de ETW ausentes, queda abrupta de volume de logs de endpoint, falhas de comunicação do agente, reinícios inesperados de serviços de segurança e alterações em callbacks ou drivers devem ser tratados como sinais de possível evasão, principalmente quando coincidem com implantação de driver. Em ataques BYOVD, a instalação ou carregamento de um driver assinado não é, por si só, suficiente para classificar a atividade como legítima. O hunting deve cruzar publicador, caminho, horário, processo responsável, usuário, reputação interna, presença em inventário aprovado e relação com outros artefatos da cadeia. Drivers como NSecKrnl.sys, rwdrv.sys e hlpdrv.sys merecem triagem quando surgirem fora de um contexto administrativo conhecido.

Para Warlock, a telemetria de SharePoint deve ser analisada em conjunto com endpoint, rede e identidade. Servidores expostos e sem correção podem apresentar sequência de acesso anormal antes da implantação de ferramentas. Em seguida, a investigação deve procurar TightVNC para controle persistente, Visual Studio Code e Cloudflare Tunnel para tráfego tunelado e Yuze para proxy reverso envolvendo HTTP na porta 80, HTTPS na porta 443 ou DNS na porta 53. Como essas tecnologias podem existir em ambientes legítimos, o critério defensivo deve ser contexto: instalação recente, execução por conta incomum, comunicação para destinos não aprovados, persistência sem chamado associado e proximidade temporal com eventos de driver ou falha de EDR.

A caça também deve incluir sinais de credenciais roubadas, já que o Qilin é descrito como dependente desse vetor para acesso inicial. Autenticação bem-sucedida fora do padrão, uso de contas privilegiadas em hosts incomuns, criação de sessões administrativas antes de eventos de driver, conexão remota seguida de queda de agente de segurança e movimentação entre servidores devem ser priorizados. A janela média até ransomware permite uma abordagem orientada a cadeia: identificar a primeira autenticação anômala, mapear a expansão de controle, verificar carregamento de drivers e isolar sistemas antes da etapa de criptografia ou destruição operacional.

  • Carregamento ou presença de msimg32.dll em caminhos e processos incompatíveis com o perfil do host.
  • Instalação ou carregamento recente de NSecKrnl.sys, rwdrv.sys, hlpdrv.sys ou artefatos renomeados relacionados a drivers vulneráveis.
  • Redução súbita de eventos de EDR, falha de telemetria ETW, encerramento de processos de segurança ou perda de comunicação do agente.
  • Uso inesperado de TightVNC, Visual Studio Code, Cloudflare Tunnel ou Yuze em servidores e estáções fora do inventário aprovado.
  • Conexões de proxy reverso ou tunelamento em HTTP porta 80, HTTPS porta 443 e DNS porta 53 associadas a contas, processos ou hosts incomuns.
  • Autenticações com credenciais válidas seguidas de atividade administrativa, implantação de ferramentas e interferência em controles de endpoint.
Mitigação

A resposta deve priorizar contenção de hosts com sinais de BYOVD, validação da integridade dos agentes de segurança e bloqueio de carregamento de drivers fora da política aprovada. Permitir apenas drivers assinados por publicadores explicitamente confiáveis reduz a capacidade de um operador carregar componentes vulneráveis trazidos para o ambiente. Essa medida precisa ser acompanhada por inventário de drivers aceitos, revisão de exceções, alerta para drivers recém-instalados e monitoramento em tempo real de atividades em nível de núcleo. A assinatura, isoladamente, não garante segurança quando o driver legítimo possui vulnerabilidade explorável.

Em ambientes com SharePoint, a correção de servidores sem atualização deve ter prioridade quando houver exposição ou suspeita de uso como ponto de entrada. A mitigação não deve parar na aplicação de patches: é necessário revisar logs do servidor, contas usadas no período de risco, arquivos gravados, tarefas agendadas, ferramentas remotas e tráfego de saída. Para Warlock, qualquer combinação de SharePoint vulnerável, driver NSecKrnl.sys, ferramentas de tunelamento e falha de EDR exige investigação de comprometimento, não apenas remoção de um arquivo.

Para Qilin, a defesa deve explorar a janela entre acesso inicial e ransomware. Ações de contenção incluem revogação e rotação de credenciais suspeitas, invalidação de sessões, revisão de privilégios, bloqueio de contas usadas de forma anômala e isolamento de hosts onde a cadeia de DLL side-loading ou carregamento de driver tenha ocorrido. Como o contexto indica forte ênfase em pós-comprometimento, equipes de resposta devem preservar evidências de autenticação, processo, driver, rede e agente de segurança antes de reinstalar componentes ou limpar artefatos.

A validação final deve confirmar que o EDR voltou a coletar eventos, que os serviços de segurança estão íntegros, que drivers não autorizados foram removidos ou bloqueados, que túneis não aprovados foram encerrados e que não há persistência remota residual. Controles de detecção devem cobrir tanto nomes de artefatos quanto comportamento: carregamento incomum de DLL, manipulação de telemetria, instalação de driver, encerramento de processos de segurança e uso de ferramentas legítimas em contexto adversário. A defesa mais efetiva é tratar BYOVD como uma classe de técnica pós-comprometimento, não como uma assinatura isolada de malware.

  • Aplicar política de governança de drivers com publicadores explicitamente confiáveis e bloqueio de drivers não aprovados.
  • Monitorar eventos de instalação, carregamento e alteração de drivers, incluindo correlação com processo, usuário e host.
  • Corrigir servidores Microsoft SharePoint sem atualização e revisar sinais de exploração, persistência e tráfego de saída.
  • Investigar e remover uso não autorizado de TightVNC, Visual Studio Code, Cloudflare Tunnel e Yuze.
  • Rotacionar credenciais associadas a autenticações suspeitas e revisar privilégios de contas usadas no período de comprometimento.
  • Validar a saúde dos agentes de EDR após a contenção, incluindo telemetria, serviços, callbacks, comunicação e cobertura de alertas.

Postar um comentário

0 Comentários