Petya incorporou backdoor DoublePulsarV2.0 para movimentação lateral via SMB

A variante analisada instala um manipulador no driver SMB do Windows, usa campos incomuns de pacotes TRANS2 para comunicação e prioriza propagação interna e destruição em vez de recuperação por resgate.

Componente	Petya com backdoor DoublePulsarV2.0, driver SMB srv.sys e código executado em memória de núcleo do Windows.
Vetor	Instalação do implante após exploração relacionada a EternalBlue/MS17-10, seguida de comunicação por pacotes SMB SMB_COM_TRANSACTION2 com subcomando TRANS2_SESSION_SETUP.
Impacto	Movimentação lateral em máquinas do mesmo domínio ou rede interna, instalação de backdoor, envio de carga para novos alvos e operação com finalidade destrutiva, sem recuperação efetiva dos arquivos mesmo após pagamento.
Prioridade	Aplicar e validar correções MS17-10, bloquear exploração SMB conhecida, caçar tráfego TRANS2 anômalo e priorizar contenção de propagação interna.
Artefatos	Uso de ntoskrnl.exe, KPCR, IDT, tabela de exportação do PE, ZwQuerySystemInformation, ExAllocatePool, SrvTransaction2DispatchTable e SrvTransactionNotImplemented.
IoCs	Comandos internos observados 0xf0, 0xf1 e 0xf2, além de respostas 0x11 e 0x21; esses valores aparecem em campos SMB usados pelo backdoor.
Mitigação	Correção de MS17-10, redução de exposição SMB, inspeção de pacotes SMB malformados, bloqueio de exploração CVE-2017-0144 e validação de controles contra variantes de DoublePulsar.

Resumo técnico

A amostra de Petya analisada introduz uma adaptação própria do backdoor DoublePulsar, identificada como DoublePulsarV2.0, para apoiar propagação e execução de comandos sobre SMB em ambientes Windows. A família Petya já havia aparecido em 2016, mas a iteração descrita em 2017 mudou o foco operacional: em vez de maximizar apenas a criptografia de tipos de arquivo, ela reduziu o conjunto de arquivos visados para acelerar a disseminação e passou a enfatizar movimentação lateral dentro do mesmo domínio. O comportamento observado também se distancia de ransomware convencional, porque o fluxo informado indica que o pagamento não resultava em capacidade real de descriptografar os arquivos afetados. O resultado operacional é uma campanha com aparência de extorsão, mas com impacto destrutivo e forte dependência de propagação interna.

O implante incorporado ao Petya mantém semelhança estrutural com o DoublePulsar exposto anteriormente, mas apresenta diferenças relevantes de implementação e comunicação. A instalação ocorre em estágios e busca preparar primitivas em memória de núcleo antes de alterar o caminho de tratamento de pacotes SMB. A versão de Petya contém variantes de 32 e 64 bits e seleciona em tempo de execução a carga compatível com a arquitetura da máquina. Esse detalhe é importante para defesa porque o artefato não deve ser tratado apenas como um binário de usuário ou uma rotina de criptografia: parte crítica da operação depende de navegação em estruturas internas do Windows, enumeração de módulos carregados e desvio de uma tabela de despacho do driver SMB.

A defesa deve priorizar duas frentes simultâneas. A primeira é eliminar a condição que permite instalação e propagação por meio das vulnerabilidades associadas a MS17-10, incluindo a exploração CVE-2017-0144 citada no contexto. A segunda é detectar o comportamento pós-instalação do backdoor, especialmente pacotes SMB TRANSACTION2 com campos reservados ou incomuns usados como canal de comando e resposta. A análise indica que controles focados somente em assinaturas de ferramentas conhecidas para DoublePulsar podem falhar, porque a variante altera campos, códigos e respostas para reduzir compatibilidade com detectores existentes.

Fluxo técnico

A instalação do DoublePulsarV2.0 começa pela obtenção de funções exportadas pelo ntoskrnl.exe, a imagem do núcleo do Windows. Antes de manipular o driver SMB, o código precisa localizar primitivas que permitam alocar memória e consultar informações do sistema. Para isso, ele obtém um ponteiro para a estrutura KPCR, que contém referências úteis em contexto de núcleo, incluindo um campo que aponta para a IDT. Como essa tabela reside dentro da memória da imagem do ntoskrnl.exe, o código percorre páginas de memória em direção ao início da imagem até encontrar a assinatura PE esperada. A partir desse ponto, ele segue a estrutura do executável para alcançar a tabela de exportação e resolver endereços de funções por meio de hashes de nomes.

Depois de resolver as funções necessárias, a próxima etapa é identificar o driver SMB carregado. A função ExAllocatePool é usada para reservar memória em espaço de núcleo, enquanto ZwQuerySystemInformation, com uma classe de consulta de módulos do sistema, retorna a lista de drivers carregados. O código percorre essa lista, aplica o mesmo algoritmo de hash sobre os caminhos completos e compara o resultado com o valor associado ao driver srv.sys. Esse fluxo evita depender de endereços fixos e permite que o backdoor encontre o componente SMB em tempo de execução. Para equipes de engenharia reversa e DFIR, a sequência de resolução de exportações, enumeração de módulos e busca por srv.sys é um encadeamento de comportamento mais robusto do que um único nome de arquivo.

Com o ponteiro para srv.sys, o implante procura a seção .data do driver e localiza a tabela SrvTransaction2DispatchTable. Essa tabela contém ponteiros para funções responsáveis por manipular tipos específicos de pacotes SMB. A função de interesse é SrvTransactionNotImplemented, usada para lidar com pacotes malformados ou com campos inesperados, como Timeout e Reserved. Em vez de remover completamente a função original, o backdoor preserva a referência anterior e substitui a entrada da tabela por um manipulador próprio armazenado em memória alocada. Quando um pacote malformado chega, o novo manipulador interpreta os campos como comandos, executa a lógica necessária e então chama a função original com modificações suficientes para devolver respostas customizadas ao remetente.

O canal de comunicação usa SMB_COM_TRANSACTION2 com o subcomando TRANS2_SESSION_SETUP. A variante descrita difere do DoublePulsar anterior porque transporta mensagens nos campos Timeout e Reserved. O campo Timeout carrega o comando de forma fixa, sem codificação ou operação XOR informada no contexto, enquanto o campo Reserved retorna indicação positiva ou negativa. Foram observados comandos 0xf0, 0xf1 e 0xf2, além de códigos de resposta 0x11 e 0x21. O comando 0xf0 é usado para verificar a presença do backdoor, e 0xf2 é usado para enviar a carga a outra máquina alvo na mesma rede após a instalação. Essa escolha de campos também é relevante para detecção, pois campos reservados deveriam seguir valores esperados pelo protocolo, e desvios podem indicar abuso.

Superfície afetada

A superfície de risco se concentra em sistemas Windows com SMB exposto internamente e vulneráveis ao conjunto de correções tratado por MS17-10. O texto recebido não define versões específicas de Windows, quantidade de vítimas, país atingido ou vetor inicial confirmado, portanto esses pontos não devem ser extrapolados. O que está ancorado na análise é que, depois de obter execução e instalar o backdoor, a amostra busca infectar computadores na mesma rede interna e dentro do mesmo domínio. Isso muda a prioridade defensiva: a contenção não deve se limitar ao perímetro, porque a atividade relevante ocorre entre estáções e servidores que já compartilham conectividade SMB.

A presença de duas variantes, uma de 32 bits e outra de 64 bits, aumenta a abrangência operacional do implante dentro de ambientes mistos. A seleção em tempo de execução indica que a carga avalia a arquitetura antes de prosseguir. Como o backdoor altera uma tabela de despacho no driver srv.sys, a exposição não depende apenas de processos de usuário facilmente encerrados. A análise deve considerar artefatos em memória, anomalias no tratamento de pacotes SMB e alterações no fluxo esperado do driver. Em ambientes que ainda dependem de SMB para compartilhamentos, controladores de domínio, servidores de arquivos ou estáções legadas, a visibilidade de tráfego leste-oeste é decisiva para identificar propagação.

• Sistemas Windows sem correção efetiva para MS17-10 e com SMB acessível a partir de outros hosts internos.
• Máquinas em redes ou domínios onde o Petya consegue alcançar novos alvos por conectividade SMB lateral.
• Ambientes com baixa inspeção de tráfego leste-oeste, especialmente onde pacotes SMB malformados não são registrados ou bloqueados.
• Hosts nos quais o driver srv.sys pode ser alvo de alteração em tabela de despacho após exploração bem-sucedida.

Hunting e telemetria

A caça deve começar por eventos que combinem exploração SMB, tentativa de propagação e comportamento anômalo de TRANSACTION2. O contexto descreve que o backdoor usa SMB_COM_TRANSACTION2 com TRANS2_SESSION_SETUP, além de campos Timeout e Reserved para comando e resposta. Como o campo Reserved deveria permanecer em valor reservado pelo protocolo, valores inesperados podem ser sinal de atividade. A detecção não deve depender somente de identificadores da versão anterior de DoublePulsar, porque a variante de Petya modifica comandos e respostas. Procure por sequências de verificação de presença do backdoor, respostas positivas após tentativa de instalação e tráfego subsequente enviando carga para outro host interno.

No endpoint, a telemetria ideal inclui eventos de falha ou sucesso relacionados ao serviço SMB, travamentos de driver, alterações incomuns em memória de núcleo e conexões SMB entre hosts que normalmente não se comunicam. Em redes corporativas, a movimentação lateral pode aparecer como aumento súbito de sessões SMB originadas de uma estáção comprometida para múltiplos destinos no mesmo domínio. Como o vetor inicial não foi esclarecido no contexto, a investigação não deve presumir phishing, download ou credenciais roubadas como entrada. A linha de investigação mais forte é a correlação entre vulnerabilidade SMB, instalação de backdoor e propagação interna.

Para DFIR, é útil separar três momentos: pré-instalação, instalação e uso do backdoor. Antes da instalação, o comando de verificação pode receber resposta negativa, indicando ausência do implante. Depois da exploração, a mesma verificação retorna reconhecimento de instalação. Em seguida, o comando usado para envio de carga pode aparecer em direção a novos alvos internos. Essa sequência fornece uma lógica de detecção baseada em estado, mesmo quando o conteúdo exato dos pacotes não é armazenado. Onde houver captura de rede, revisar metadados e anomalias de campos SMB pode ser mais viável e seguro do que tentar reproduzir comandos ou publicar payloads.

• Pacotes SMB TRANSACTION2 com TRANS2_SESSION_SETUP e uso incomum dos campos Timeout e Reserved.
• Valores de comando 0xf0, 0xf1 ou 0xf2 associados a respostas 0x11 ou 0x21 em comunicação SMB suspeita.
• Conexões SMB laterais de uma máquina para múltiplos hosts no mesmo domínio após sinais de exploração MS17-10.
• Eventos ou alertas de exploração relacionados a CVE-2017-0144, DoublePulsar, SMB Touch ou falhas cobertas por MS17-10.
• Anomalias de estabilidade ou comportamento do driver srv.sys, especialmente quando acompanhadas por tráfego SMB malformado.

Mitigação

A correção de MS17-10 é a ação central porque remove a principal condição técnica associada à exploração citada. A validação deve ir além de confirmar a existência de um pacote instalado: equipes devem verificar inventário de ativos, estado real de atualização, hosts fora de domínio, máquinas legadas e segmentos onde SMB continua exposto. Em paralelo, controles de rede devem reduzir a possibilidade de propagação leste-oeste. Isso inclui restringir SMB entre estáções, limitar acesso a servidores que realmente precisam receber conexões e monitorar tentativas de comunicação entre pares que não fazem parte de fluxos operacionais normais.

A contenção de um ambiente suspeito deve tratar a ocorrência como atividade de propagação interna com potencial destrutivo. A prioridade é isolar hosts que iniciam varredura ou sessões SMB anômalas, preservar evidências de rede e endpoint, e impedir que novas máquinas vulneráveis recebam a carga. Como a amostra descrita pode se apresentar como ransomware sem oferecer recuperação funcional, a resposta não deve se apoiar em pagamento ou expectativa de descriptografia. Backups offline, restauração validada e segmentação são controles mais adequados ao impacto observado.

Controles de detecção devem ser atualizados para reconhecer diferenças entre DoublePulsar anterior e DoublePulsarV2.0. A variante muda códigos de comando, respostas e campos usados no protocolo, o que pode reduzir a eficácia de regras construídas para ferramentas abertas de detecção da versão anterior. Portanto, a estratégia defensiva deve combinar assinatura de exploração, inspeção semântica de SMB, comportamento lateral e telemetria de endpoint. Depois da contenção, a validação deve incluir busca por hosts ainda vulneráveis, revisão de logs de SMB, confirmação de bloqueio para EternalBlue e testes controlados de cobertura defensiva sem executar payloads ofensivos.

• Aplicar, comprovar e auditar a correção MS17-10 em todos os ativos Windows alcançáveis por SMB.
• Bloquear ou restringir SMB entre estáções e permitir o protocolo apenas nos fluxos de negócio necessários.
• Investigar hosts com tráfego SMB malformado, aumento súbito de conexões laterais ou alertas relacionados a CVE-2017-0144.
• Atualizar inspeções para cobrir campos Timeout e Reserved usados como canal de comando e resposta.
• Isolar máquinas suspeitas, preservar evidências e priorizar restauração por backups confiáveis em vez de qualquer expectativa de recuperação por resgate.