A família Reynolds combina criptografia e evasão por BYOVD no mesmo payload, usando o driver NsecSoft NSecKrnl para encerrar processos de segurança antes do impacto.
| Componente | Ransomware Reynolds com componente BYOVD embutido e driver vulnerável NsecSoft NSecKrnl. |
| Vetor | Execução do payload de ransomware em host já comprometido; o binário solta o driver vulnerável e tenta encerrar processos de produtos de segurança. |
| Impacto | Desativação ou degradação de ferramentas EDR e antivírus antes da etapa de ransomware, aumentando a chance de criptografia sem intervenção inline. |
| Prioridade | Bloquear o driver NSecKrnl vulnerável, revisar listas de drivers vulneráveis, validar proteção independente de processos em modo usuário e investigar sinais de carregadores side-loaded anteriores ao ransomware. |
| Vulnerabilidade | O driver NSecKrnl é associado à falha CVE-2025-68947, com CVSS 5.7, explorável para terminar processos arbitrários. |
| Artefatos | A campanha também teve presença de carregador suspeito side-loaded semanas antes e uso do programa de acesso remoto GotoHTTP um dia após a implantação do ransomware. |
A família de ransomware Reynolds foi observada com uma característica relevante para defesa de endpoint: o payload incorpora sua própria etapa de BYOVD, em vez de depender de uma ferramenta separada para desativar controles de segurança. BYOVD é a técnica em que operadores abusam de drivers legítimos, assinados e vulneráveis para obter capacidade privilegiada no sistema operacional e interferir em componentes de proteção. No caso descrito, o ransomware é capaz de soltar o driver NsecSoft NSecKrnl e usá-lo como parte da mesma cadeia de execução que antecede o impacto do ransomware.
A diferença operacional está na consolidação. Em intrusões de ransomware, a desativação de EDR costuma ocorrer antes da execução do criptografador, com binários separados, scripts auxiliares ou ferramentas dedicadas. No Reynolds, a evasão e o impacto ficam agrupados, reduzindo a quantidade de artefatos externos que precisam ser transferidos para a rede da vítima. Isso não elimina sinais detectáveis, mas altera o ponto de intervenção: a defesa precisa reconhecer o comportamento de drop de driver, tentativa de carga em nível de núcleo e encerramento de processos de segurança antes que a etapa de ransomware avance.
O driver NSecKrnl citado na campanha é associado à vulnerabilidade CVE-2025-68947, com pontuação CVSS 5.7, que permite terminar processos arbitrários. Essa capacidade é especialmente sensível quando aplicada contra serviços de antivírus, EDR, XDR e componentes auxiliares de proteção. A campanha Reynolds teria como alvos processos associados a Avast, CrowdStrike Falcon, Palo Alto Networks Cortex XDR, Sophos, HitmanPro.Alert e Symantec Endpoint Protection, entre outros. O impacto técnico confirmado é a tentativa de neutralização desses controles; qualquer efeito posterior, como criptografia em massa, depende da execução bem-sucedida do ransomware no ambiente comprometido.
A cadeia começa em uma condição já adversa para a organização: o atacante possui execução suficiente no host para iniciar o payload do Reynolds. A partir desse ponto, o ransomware não precisa buscar um utilitário BYOVD separado na rede; ele traz o componente de evasão no próprio binário. O fluxo observado envolve a gravação do driver vulnerável no sistema, a tentativa de carregá-lo e a utilização de sua capacidade para encerrar processos selecionados. Como drivers assinados podem parecer menos suspeitos do que binários claramente maliciosos, a defesa baseada apenas em reputação superficial de arquivos legítimos tende a ter uma janela menor para agir.
A função do driver no ataque é permitir interferência em processos que normalmente seriam protegidos por controles de endpoint. Quando o operador consegue acionar um driver vulnerável em contexto apropriado, a fronteira entre modo usuário e núcleo passa a ser explorada para afetar ferramentas que dependem de serviços em modo usuário ou de agentes que não conseguem reagir inline antes do encerramento. A campanha mostra esse risco ao agrupar a etapa de terminação de EDR com a etapa de ransomware, criando uma sequência curta entre evasão e impacto.
A consolidação em um único payload tem vantagens e limitações para o atacante. A vantagem é reduzir a necessidade de implantar um arquivo externo de evasão antes do ransomware, o que pode diminuir algumas oportunidades de detecção por transferência de ferramenta. A limitação é que o comportamento do binário fica mais denso: drop de driver, tentativa de carga privilegiada, enumeração ou encerramento de processos de segurança e atividade de ransomware passam a aparecer próximos no tempo. Soluções com monitoramento comportamental abrangente, bloqueio de drivers vulneráveis e proteção contra ransomware que não dependa apenas de processos facilmente encerráveis têm mais chance de interromper a cadeia.
A presença de um carregador suspeito side-loaded na rede semanas antes da implantação do ransomware indica que a intrusão pode ter tido uma fase preparatória anterior ao evento de impacto. Também foi observado o programa de acesso remoto GotoHTTP um dia depois da implantação do ransomware, o que sugere tentativa de manter acesso persistente ou operacional aos hosts afetados. Esses artefatos ampliam a investigação além do binário do Reynolds: a linha do tempo deve incluir execução anômala anterior, bibliotecas carregadas lateralmente, conexões de acesso remoto e alterações recentes em controles de endpoint.
A superfície mais exposta é formada por endpoints Windows onde o atacante consegue executar o payload e carregar ou abusar do driver NSecKrnl vulnerável. O risco não se limita a um produto de segurança específico, porque a técnica busca encerrar processos de várias plataformas de proteção. Ambientes que mantêm listas de bloqueio de drivers vulneráveis desatualizadas, permitem carga indevida de drivers ou dependem de agentes em modo usuário sem mecanismos robustos de autoproteção ficam mais suscetíveis à interrupção dos controles antes da criptografia.
A campanha Reynolds também deve ser analisada dentro de uma tendência maior de ransomware com evasão agressiva. O mesmo driver NSecKrnl já apareceu em incidentes envolvendo LockBit/Warlock e Nitrogen, e também foi usado por Silver Fox antes da entrega de ValleyRAT. Outros drivers legítimos e vulneráveis, como truesight.sys e amsdk.sys, foram citados em ataques BYOVD anteriores. Esse padrão reforça que a superfície de defesa inclui o inventário de drivers permitidos, a política de carga no núcleo e a capacidade de detectar drivers assinados mas vulneráveis, não apenas executáveis com reputação maliciosa.
Produtos e componentes de segurança citados como alvos de terminação exigem validação específica. A existência de proteção contra o driver desde novembro de 2025 em um dos fornecedores citados mostra que bloqueios preventivos podem estar disponíveis, mas a cobertura real depende da configuração do cliente, atualização de política, integridade do agente e arquitetura de prevenção. O ponto operacional é verificar se o ambiente consegue impedir a carga do driver vulnerável mesmo quando o atacante já obteve execução local.
- Hosts Windows com execução não autorizada do payload Reynolds e possibilidade de carga de driver vulnerável.
- Controles de endpoint associados a Avast, CrowdStrike Falcon, Palo Alto Networks Cortex XDR, Sophos, HitmanPro.Alert e Symantec Endpoint Protection, conforme processos visados na campanha.
- Ambientes com listas de drivers vulneráveis pouco atualizadas ou proteção contra ransomware dependente apenas de serviços em modo usuário.
- Redes com sinais prévios de carregamento side-loaded e presença posterior de GotoHTTP em hosts comprometidos.
A investigação deve reconstruir a sequência temporal em torno do primeiro host afetado. O sinal central é a tentativa de introduzir ou carregar o driver NsecSoft NSecKrnl em proximidade com eventos de encerramento de processos de segurança. Mesmo quando o driver é legítimo, o contexto de uso é anômalo: carga recente, origem em diretório incomum, associação com processo desconhecido ou execução imediatamente antes de falhas em agentes EDR e antivírus devem ser tratados como indicadores de comprometimento operacional.
Eventos de terminação ou parada inesperada de serviços de segurança precisam ser correlacionados com telemetria de kernel, criação de arquivos, logs de driver, alertas de autoproteção do EDR e eventos do Windows relacionados a serviços. A defesa deve procurar padrões em que múltiplos processos de segurança falham em sequência ou em que um processo recém-executado tenta interagir com vários produtos de proteção. Como a campanha também incluiu carregador side-loaded semanas antes, a busca deve retroceder no tempo para identificar executáveis legítimos carregando bibliotecas inesperadas, caminhos fora do padrão e persistência que anteceda o ransomware.
A presença de GotoHTTP um dia após a implantação do ransomware cria uma segunda linha de hunting. Esse artefato deve ser tratado como ferramenta de acesso remoto possivelmente usada para manter controle sobre hosts já afetados. A telemetria de rede deve procurar conexões de acesso remoto incomuns, criação de serviços relacionados, execução por contas administrativas e presença em máquinas que também apresentaram eventos de driver vulnerável ou encerramento de processos de segurança. O objetivo não é apenas confirmar o ransomware, mas identificar se o operador preservou acesso após o impacto.
- Criação, gravação ou tentativa de carga do driver NSecKrnl em endpoints sem justificativa administrativa válida.
- Eventos de encerramento em sequência envolvendo agentes EDR, XDR, antivírus ou serviços de autoproteção.
- Falhas ou paradas inesperadas de processos de Avast, CrowdStrike Falcon, Cortex XDR, Sophos, HitmanPro.Alert ou Symantec Endpoint Protection em proximidade temporal com execução desconhecida.
- Execução side-loaded anterior ao evento de ransomware, especialmente binários legítimos carregando bibliotecas fora de caminhos esperados.
- Instalação, execução ou tráfego associado ao GotoHTTP após a implantação do ransomware.
A primeira ação defensiva é impedir que o driver vulnerável seja carregado. Isso exige atualização e validação efetiva de listas de bloqueio de drivers vulneráveis, políticas de controle de aplicação e mecanismos de segurança do Windows voltados à integridade de código. O bloqueio precisa ser testado em endpoints reais, porque a existência de uma regra ou assinatura no console não garante que o host esteja aplicando a política. O inventário de drivers deve diferenciar drivers legítimos necessários ao negócio de drivers assinados mas vulneráveis que não têm uso operacional aceitável.
A arquitetura do endpoint deve ser revisada com foco em resistência à terminação. Soluções que dependem somente de serviços em modo usuário podem perder a capacidade de detecção local se o processo for encerrado antes da criptografia ou se a atividade ocorrer de forma remota. Controles mais robustos combinam autoproteção, monitoramento comportamental, bloqueio inline, prevenção independente do processo observado e reação a ações de criptografia, renomeação em massa ou alteração destrutiva de arquivos. A campanha Reynolds torna essa validação concreta: a pergunta operacional é se o ambiente continua protegendo dados quando o agente visível é atacado por BYOVD.
A resposta a um alerta relacionado ao Reynolds deve incluir isolamento dos hosts afetados, preservação de evidências, coleta de eventos de driver, revisão da linha do tempo e varredura retroativa por carregadores side-loaded. Como GotoHTTP foi observado após a implantação do ransomware, a contenção deve incluir busca por ferramentas de acesso remoto, contas usadas para execução, persistência local e movimentação entre hosts. Backups devem ser verificados quanto à integridade e separação lógica, mas a restauração só deve ocorrer depois de confirmar que o driver vulnerável, o payload e os mecanismos de acesso remoto foram removidos ou bloqueados.
Também é necessário tratar o risco como parte de uma tendência recorrente, não como um evento isolado. Outros grupos e famílias de ransomware têm usado drivers vulneráveis para desativar segurança, e versões recentes de ransomware seguem incorporando recursos de evasão, execução em memória, atraso de execução, wiper e suporte a diferentes ambientes. A defesa deve manter um programa contínuo de governança de drivers, atualização de regras de bloqueio, teste de resistência do EDR, revisão de privilégios locais e monitoramento de ferramentas legítimas usadas fora de contexto.
- Atualizar e aplicar listas de bloqueio para drivers vulneráveis, incluindo o NSecKrnl associado à
CVE-2025-68947. - Validar se endpoints impedem a carga do driver vulnerável mesmo quando o atacante já possui execução local.
- Investigar eventos anteriores de side-loading e eventos posteriores de GotoHTTP nos hosts relacionados.
- Testar a proteção contra ransomware quando processos de segurança em modo usuário são encerrados ou ficam indisponíveis.
- Isolar hosts afetados, preservar evidências de driver e revisar contas administrativas usadas durante a janela da intrusão.
0 Comentários