Afiliados do grupo Cl0p exploram a falha crítica CVE-2026-12569 em servidores PTC Windchill e FlexPLM expostos na internet para roubar desenhos técnicos, credenciais administrativas e dados de engenharia de produto — sem criptografar um único arquivo. A campanha de extorsão está documentada em advisory unificado publicado pelo Ransom-ISAC em parceria com o eCrime.ch e o DEFUSED, com vítimas confirmadas em manufatura, automotivo, aeroespacial e varejo. Quem opera esses servidores precisa aplicar as correções da PTC agora e caçar indicações de comprometimento retroativamente até o início de junho, quando o grupo suspeita de uso como dia zero.

Como o ataque acontece

O vetor combina duas falhas na mesma plataforma. A primeira é uma divulgação de informação antes da autenticação no endpoint WSDL do FlexPLM. A segunda é um defeito no servlet de login do Windchill. Encadeadas, as duas permitem execução remota de código sem autenticação em qualquer instância sem correção acessível pela rede. O Ransom-ISAC pontua a cadeia do Windchill com 9,8 no CVSS 3.1 e a divulgação do WSDL com 7,5; a PTC, responsável pelo registro no NVD, atribui 9,3 na versão 4.0 da métrica.

Trata-se de uma falha crítica de execução remota de código sem autenticação, rastreada como CVE-2026-12569, que alcança o Windchill PDMLink e o FlexPLM desde lançamentos anteriores à 11.0 M030 até as linhas 13.1. A correção foi divulgada em 17 de junho de 2026 e, oito dias depois, a CISA adicionou o registro ao catálogo KEV — a ficha oficial marca o uso em campanhas de ransomware como confirmado. O desenho lembra o que a Microsoft descreveu ao rastrear o Storm-2570: a cadeia de intrusão vale mais que o nome do payload, porque o afiliado reaproveita ferramentas entre vítimas.

A janela de exploração é longa. A PTC publicou correções em 17 de junho; em 26 de junho, segundo a imprensa especializada, a fabricante avisou clientes sobre atividade de ameaça elevada; e a CISA deu às agências federais norte-americanas prazo até 28 de junho para remediação, sob a diretriz BOD 26-04. O Ransom-ISAC avalia que a falha foi explorada como dia zero desde o início de junho — vítimas podem existir de antes da correção, e a caça precisa cobrir esse período.

Extorsão sem criptografia

A partir de 20 de julho, o Ransom-ISAC registrou e-mails de extorsão com o assunto “Windchill PDMLink module serious data leak”, enviados de contas comprometidas para centenas de funcionários dentro de cada organização atingida, com os contatos atualizados do grupo para negociação. Até 22 de julho, o Cl0p não havia listado vítimas no site de vazamentos nem reivindicado publicamente a campanha — a pressão era feita porta a porta, por e-mail.

O alvo é o dado, não a disponibilidade. Arquivos de CAD, plantas, especificações e bancos de dados de produto valem mais em uma mesa de negociação do que criptografados. No caso do Windchill, um implante personalizado enumerava o cofre de arquivos da aplicação e gravava um índice em flst.txt antes da exfiltração — o inventário encurta a coleta do material mais valioso e reduz o volume de tráfego suspeito.

Por que o Windchill é alvo

Plataformas de gestão do ciclo de vida do produto concentram a propriedade intelectual mais sensível de uma indústria: desenhos de peças, processos de fabricação, fórmulas e projetos em desenvolvimento. Elas também ligam a rede corporativa ao chão de fábrica, o que amplia o impacto de um comprometimento bem-sucedido. Um servidor PLM exposto é cofre de segredo industrial e porta lateral para o ambiente operacional ao mesmo tempo.

O implante descrito no advisory vai além do arquivo: ele usa as próprias classes da aplicação para decriptar o keystore do Windchill e recuperar a senha do gerenciador LDAP, além de credenciais administrativas e de armazenamento. A invasão de um servidor de engenharia pode virar posse de identidades privilegiadas de toda a corporação — cenário parecido com a falha crítica no Cisco ISE que dava root e já era explorada, analisada aqui no portal.

Quem não opera Windchill sai com uma lição transferível: o catálogo KEV é insumo de priorização, e a pergunta certa para qualquer aplicação corporativa voltada para a internet é se ela guarda segredo industrial ou credenciais de serviço. Se a resposta for sim, exposição direta precisa de justificativa forte.

Indicadores para caçar agora

A caça começa nos logs do servidor web e do balanceador, com janela retroativa até a primeira semana de junho. A sonda de reconhecimento tem assinatura precisa: uma requisição GET para /Windchill/rfa/jsp/login/*.jsp?wsdl com resposta de 4.045 bytes. Os webshells JSP com nomes hexadecimais moram sob /Windchill/login/, no padrão de 16 caracteres hexadecimais e na variação curta de seis, às vezes invocada com?cmd=whoami. O cabeçalho HTTP X-windchill-req, com valor iniciado por?x8Fmgow, entrega o canal de comando.

Indicador Padrão Ação
Sonda inicial GET /Windchill/rfa/jsp/login/*.jsp?wsdl com 4.045 bytes de resposta Buscar logs desde o início de junho
Webshell /Windchill/login/[0-9a-f]{16}.jsp e variantes de seis caracteres Comparar com JSP legítimo do diretório
Cabeçalho de comando X-windchill-req com valor iniciado por?x8Fmgow Bloquear e alertar no WAF
Endereço de comando 79.141.160.78 Bloqueio prioritário no perímetro
Arquivo de enumeração flst.txt no servidor de aplicação Preservar como evidência forense

O advisory também traz hash SHA-256 de amostra e uma regra YARA estrutural, que casa o comportamento dos shells em vez do nome do arquivo — os operadores trocam nomes hexadecimais com facilidade, e detecção por nome decai rápido. Valide qualquer indicador de rede contra o seu ambiente antes de bloquear em massa.

Quem decide o quê

A decisão de corrigir é do dono da aplicação, mas a decisão de tirar o servidor da internet pode ser do SOC quando há indicador positivo, e o prazo não admite fila de mudança normal. Jurídico e comunicação entram na primeira hora se o e-mail de extorsão já circulou internamente: a mensagem chegando a centenas de caixas é evento com ônus de notificação, não incidente silencioso.

Prioridades de resposta P1 e P2

P1 — hoje: aplicar as correções da PTC em todas as instâncias, incluindo servidores de arquivo e réplicas; remover da internet o que não precisa de exposição, colocando acesso atrás de VPN ou gateway confiável; rodar a caça retroativa pelos indicadores da tabela; bloquear o endereço de comando observado em incidente ativo. Instância sem correção e exposta é incidente presumido, não risco aceito.

P1 — com sinal positivo: isolar o servidor, preservar memória e discos antes de qualquer reinício e rotacionar credenciais do keystore, senhas de serviço e contas administrativas, porque o implante as recupera em texto claro. Acionar resposta a incidentes externa se a equipe interna não tiver capacidade forense em Java.

P2 — duas semanas: segmentar a camada PLM em rede dedicada com acesso por bastion; alertar sobre respostas grandes comprimidas em GZIP para requisições POST em arquivos JSP; e revisar o inventário de instâncias esquecidas — lançamentos anteriores à 11.0 M030 também são afetados e costumam ficar fora do radar de correção.

Fontes