Hack Alerta

Ataques BYOVD tornam-se padrão em campanhas de ransomware para desativar antivírus e EDR no Windows

Ataques BYOVD tornam-se padrão em campanhas de ransomware para desativar antivírus e EDR no Windows, exigindo novas estratégias defensivas.

Atacantes estão cada vez mais abusando de drivers confiáveis do Windows para desligar antivírus (AV) e ferramentas de detecção e resposta de endpoint (EDR), usando uma técnica conhecida como Bring Your Own Vulnerable Driver (BYOVD). Uma vez considerada de nicho, o BYOVD rapidamente se tornou um componente padrão de campanhas modernas de ransomware, permitindo que atores de ameaças operem no nível de privilégio mais alto em ambientes Windows.

A evolução da evasão de defesa

Pesquisadores de segurança destacam que a evasão de defesa agora é uma fase crítica em intrusões cibernéticas. Em vez de evitar a detecção, os atacantes estão diretamente mirando e desligando controles de segurança. O BYOVD permite isso explorando drivers legítimos, digitalmente assinados que contêm vulnerabilidades conhecidas. Como o Windows confia nesses drivers, eles podem ser carregados sem levantar alarmes.

O Windows opera usando dois níveis de privilégio: modo de usuário e modo de kernel. Enquanto o modo de usuário restringe aplicativos, o modo de kernel fornece controle quase completo sobre o sistema. Ao aproveitar um driver vulnerável, os atacantes podem executar ações maliciosas no modo de kernel.

Por exemplo, após ganhar acesso administrativo, um atacante pode instalar um driver assinado, mas falho e enviar a ele comandos elaborados para explorar suas fraquezas. O resultado mais comum é a terminação de processos AV ou EDR. Em outros casos, os atacantes podem degradar silenciosamente ferramentas de segurança removendo permissões ou modificando estruturas de kernel para que os sistemas de monitoramento não recebam mais alertas. Isso efetivamente cega as defesas enquanto as mantém parecendo operacionais.

Acessibilidade do BYOVD

O BYOVD tornou-se altamente acessível. Centenas de drivers vulneráveis são documentados publicamente, e novos continuam a emergir. Ferramentas de código aberto e subterrâneas como TrueSightKiller, GhostDriver e AuKill automatizam o processo de abusar desses drivers para terminar processos de segurança. Alguns grupos de ransomware agora integram capacidades BYOVD diretamente em seus payloads, reduzindo a necessidade de tooling separado.

Alternativas ao BYOVD

Embora o BYOVD domine, os atacantes também usam métodos alternativos. O Windows inclui um mecanismo de proteção chamado Protected Process Light (PPL) que impede a manipulação de serviços de segurança. No entanto, os atacantes podem contornar isso suspendendo processos protegidos em vez de terminá-los. Uma ferramenta de segurança suspensa para de funcionar, mas parece estar funcionando normalmente, impedindo a recuperação automática.

Outra técnica envolve explorar hierarquias de confiança do Windows. Se os atacantes ganharem controle de um processo de maior confiança, eles podem manipular ou terminar serviços de segurança de menor confiança. Algumas campanhas também interrompem a comunicação entre agentes de endpoint e serviços de inteligência baseados em nuvem, enfraquecendo a detecção sem alterar o agente local.

Hardening do kernel e limitações

A Microsoft introduziu vários recursos de hardening de kernel, incluindo Kernel Address Space Layout Randomization (KASLR), Hypervisor-Protected Code Integrity (HVCI) e Kernel Control Flow Guard (KCFG). Embora esses mitiguem certas classes de ataque, eles não param efetivamente o BYOVD. A razão é que os atacantes não estão injetando novo código de kernel, mas modificando estruturas de dados existentes, uma abordagem que contorna muitas proteções.

De acordo com a Security.com, a Microsoft não considera a escalada de administrador para kernel uma fronteira de segurança estrita. Como resultado, muitas técnicas BYOVD não são tratadas como vulnerabilidades e podem não receber patches imediatos ou atribuições de CVE.

Estratégias defensivas

Esforços defensivos, como a lista de bloqueio de drivers vulneráveis da Microsoft e detecção baseada em assinatura, fornecem apenas proteção limitada. Listas de bloqueio frequentemente ficam atrás de drivers descobertos recentemente, e os atacantes podem rapidamente mudar para drivers alternativos ou modificar ferramentas para evadir a detecção.

Uma abordagem mais eficaz é o monitoramento comportamental. Em vez de focar em drivers maliciosos conhecidos, soluções de segurança estão começando a analisar como os drivers são usados. Por exemplo, detectar solicitações de controle de entrada/saída (IOCTL) incomuns, como comandos que tentam terminar serviços de segurança, pode revelar atividade BYOVD independentemente do driver específico envolvido.

Por exemplo, se um driver recém-entregue subitamente emitir comandos para matar vários serviços de segurança, sistemas comportamentais podem sinalizar essa anomalia mesmo que o driver em si seja previamente desconhecido. À medida que o BYOVD continua a evoluir, os defensores estão mudando para estratégias de detecção proativa. Monitorar o comportamento do driver em vez de confiar apenas em assinaturas pode ajudar a fechar a lacuna e limitar a capacidade dos atacantes de desligar controles de segurança críticos.

Recomendações para equipes de SOC

  • Monitoramento comportamental: Implemente soluções que analisem o comportamento dos drivers, não apenas assinaturas.
  • Restrição de drivers: Use listas de bloqueio de drivers e restrinja a carga de drivers não assinados.
  • Proteção de kernel: Ative HVCI e KCFG para mitigar ataques de kernel.
  • Resposta a incidentes: Tenha planos para detectar e responder a terminação de processos de segurança.

Perguntas frequentes

Como saber se um driver é vulnerável? Verifique a lista de drivers vulneráveis conhecidos e monitore o comportamento de drivers recém-carregados.

O BYOVD é detectável? Sim, através de monitoramento comportamental e análise de solicitações IOCTL incomuns.

Qual a melhor defesa? Uma combinação de hardening de kernel, monitoramento comportamental e restrições de carga de drivers.


Baseado em publicação original de Cyber Security News
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.