A Shell e a Philips perderam plantas, não palavras-passe

O que a Clop de facto retirou

As alegações da Clop de meados de agosto citaram a Shell, a Philips, a General Electric e a Fiserv entre quase 50 empresas que, segundo o grupo, foram atingidas através do PTC Windchill e do FlexPLM, o software de gestão do ciclo de vida do produto que muitos fabricantes usam para gerir projetos CAD, listas de materiais e documentação de testes de instalações. A Shell confirmou apenas estar 'consciente de um incidente potencial' e a investigá-lo com equipas de segurança internas e externas, depois de a Clop alegar ter retirado cerca de 89 GB da empresa, descritos como plantas de engenharia, digitalizações de relatórios de testes de instalações, fotografias de instalações e planos de projeto.

A Philips afirmou que a Clop tentou violar um servidor corporativo com dados internos, que a tentativa foi detetada e contida, e que os ambientes de clientes não foram afetados. A Fiserv afirmou que a sua própria investigação não encontrou provas de que dados de clientes, informações bancárias, dados de transação ou informações pessoais tenham sido comprometidos. A Reuters, ao noticiar a campanha mais ampla, afirmou não conseguir verificar de forma independente o alcance ou o volume do que a Clop de facto exfiltrou, uma ressalva que se aplica a todos os números desta história que provêm do próprio grupo extorsionário e não das vítimas ou de uma revisão forense independente.

Uma correção que teve dois meses para funcionar

A CVE-2026-12569 é uma falha crítica de execução remota de código não autenticada que afeta o PTC Windchill e o FlexPLM, com uma pontuação CVSS de 9,3. A PTC começou a lançar correções por volta de meados de junho de 2026. A CISA acrescentou a falha ao seu catálogo de vulnerabilidades exploradas conhecidas por volta de 25 de junho, fixando um prazo de correção para 28 de junho para as agências federais dos EUA e confirmando que a exploração já estava em curso. A própria PTC alertou os clientes para uma atividade de ameaça elevada nos dias seguintes, e investigadores de segurança relataram web shells JSP colocadas em servidores Windchill não corrigidos até ao final de junho.

Os relatos descrevem organizações afetadas a começar a receber mensagens de extorsão da Clop entre meados e finais de julho, cerca de um mês após a correção e a inclusão no catálogo KEV. A divulgação em massa que citou a Shell, a Philips, a GE e a Fiserv só se tornou pública em meados de agosto, quase dois meses depois de a correção da PTC estar disponível e de o próprio prazo da CISA para as agências federais ter passado. O intervalo entre a disponibilidade de uma correção e o momento em que uma exploração em massa se torna de conhecimento público é a forma familiar de uma campanha da Clop, o mesmo grupo por trás das vagas em massa do MOVEit e do GoAnywhere, mas a categoria-alvo aqui é nova: não software de transferência de ficheiros, mas os sistemas que albergam os projetos de produto reais de um fabricante.

O vazio de notificação em que isto cai

Uma violação de registos de clientes aciona um reflexo de conformidade bem conhecido: verificar o prazo de 72 horas do RGPD, avaliar se estavam envolvidos dados pessoais, notificar a autoridade de proteção de dados competente. Uma violação de plantas de engenharia, relatórios de testes de instalações e planos de projeto não aciona nada disso, porque nada disso é dado pessoal segundo a definição do RGPD. É precisamente isso que torna esta classe de incidentes fácil de subvalorizar dentro do próprio mapeamento de conformidade de um fabricante.

A diretiva NIS2 da UE funciona com um gatilho diferente: obriga entidades essenciais e importantes - uma categoria que inclui explicitamente operadores de energia como a Shell e fabricantes do setor da saúde como a Philips - a notificar incidentes significativos independentemente de estarem envolvidos dados pessoais. Uma violação de PLM que nunca toca num único registo de cliente pode ainda assim atingir o limiar do NIS2 para um incidente notificável se afetar a confidencialidade, integridade ou disponibilidade de sistemas de que a entidade depende. Uma equipa de conformidade que tenha construído a sua lógica de notificação de incidentes apenas em torno dos gatilhos do RGPD tem uma hipótese real de ignorar por completo esta obrigação, não porque a regra seja pouco clara, mas porque o incidente não se parece com o tipo de violação para o qual o RGPD treinou toda a gente a estar atenta.

O que os fabricantes deveriam verificar agora

Qualquer organização que utilize o PTC Windchill ou o FlexPLM deve confirmar, independentemente de ter ou não notícias da Clop, que as correções de junho estão aplicadas, e rever os registos da janela entre a divulgação inicial e a correção em busca dos indicadores de web shells JSP publicados por investigadores de segurança. Essa verificação importa independentemente da dimensão da empresa: as campanhas da Clop funcionaram historicamente através de varrimento oportunista de instâncias expostas à internet, não através de seleção direcionada de nomes conhecidos.

A segunda verificação é organizacional, não técnica: o vosso protocolo de resposta a incidentes e notificação regulatória inclui um gatilho para a notificação de incidentes significativos do NIS2 que não dependa do envolvimento de dados pessoais? Se a resposta só cobrir o RGPD, uma violação de PLM exatamente como esta poderia atravessar o vosso próprio processo de conformidade sem nunca acionar um alarme, até que uma contraparte ou um regulador pergunte por que razão não foi notificada.

Leia a seguir: A moratória NIS2 da Alemanha terminou  |  361 Servidores vCenter Atingidos Antes da Lista KEV