IDC Frontier liga ransomware a falha em código aberto do portal
A subsidiária da SoftBank disse que o ataque que atingiu 495 clientes no Japão entrou por software aberto no login do portal. Até 71 contas tiveram dados consultados; a empresa não pagou resgate.

A IDC Frontier, subsidiária de nuvem da SoftBank, divulgou na terça-feira (27) o sétimo relatório sobre o ataque de ransomware que derrubou parte da IDCF Cloud em 7 de outubro e atingiu 495 empresas e governos locais no Japão. Segundo o documento, a porta de entrada foi uma vulnerabilidade em um software de código aberto usado pelo sistema de autenticação do portal de clientes, a IDCF Cloud Portal. A empresa não divulgou o nome do componente nem um identificador CVE.
A sequência descrita pela provedora, segundo a cobertura da ITmedia, da Business+IT e da agência Jiji, foi a seguinte: o invasor entrou pelo sistema de autenticação, chegou ao console de gerenciamento, obteve privilégios de administrador da plataforma de virtualização e, a partir dali, desligou e criptografou máquinas virtuais de clientes. O ataque começou por volta das 3h40 da madrugada, horário de Tóquio.
O que foi exposto e o que não foi
A IDC Frontier afirma não ter encontrado indício de que dados dentro dos servidores virtuais dos clientes tenham sido copiados para fora. O registro de clientes no portal, porém, foi consultado de forma indevida em até 71 contas, ante 48 no levantamento anterior, de 14 de outubro. Em até 31 delas havia nomes ou endereços de e-mail. Senhas de login foram alteradas pelo invasor em até quatro casos, e esses clientes foram contatados individualmente.
A provedora declarou que não pagou resgate nem negociou com os atacantes. No relatório de 14 de outubro, havia informado que cópias de snapshot podiam ser recuperadas para 194 dos 495 clientes afetados, os que haviam contratado essa função.
Entre as medidas anunciadas estão a criação de uma unidade independente dedicada à segurança, a inclusão de software de código aberto no escopo dos testes de vulnerabilidade, a adoção de inventário de componentes de software (SBOM) e a migração da autenticação para um provedor de identidade externo.
O efeito em cadeia
O alcance do incidente vai além da lista de clientes diretos. A JR East e sua operadora de cartões View Card informaram que cerca de 6,09 milhões de registros de contas, em sua maioria endereços de e-mail, podem ter sido expostos em serviços hospedados na plataforma. Sites do governo da província de Ibaraki e da polícia provincial ficaram fora do ar, segundo a SoftBank, em relato da agência Kyodo.
O caso se soma ao da GMO Internet, que suspendeu em 21 de outubro o serviço Onamae.com Desktop Cloud depois de identificar um programa malicioso em servidores de clientes, com até 26.739 servidores potencialmente afetados, segundo a empresa. A sequência levou a primeira-ministra Sanae Takaichi a determinar, em 26 de outubro, que o gabinete preparasse em cerca de uma semana um pacote emergencial de cibersegurança.
Por que a falha do portal importa fora do Japão
O ponto técnico do relatório é menos exótico do que o tamanho do estrago. O invasor não quebrou o hipervisor. Entrou por uma biblioteca de autenticação de código aberto no portal de autoatendimento, a camada que quase todo provedor regional de nuvem constrói sobre componentes públicos. A inclusão do código aberto no escopo dos testes de vulnerabilidade, listada entre as correções, mostra que ele estava fora desse escopo até o ataque.
Há quem leia o episódio como argumento contra provedores regionais e a favor das três grandes nuvens americanas. O argumento tem limite: AWS, Microsoft e Google também dependem de componentes abertos, e a Microsoft teve em 2023 uma chave de assinatura roubada pelo grupo Storm-0558, que a usou para acessar e-mails de clientes. A distinção relevante é outra: o tamanho da equipe que inventaria e testa essas dependências, e se o console de gerenciamento fica separado da autenticação do cliente.
Na União Europeia, a diretiva NIS2 já obriga provedores de nuvem a gerir riscos da cadeia de fornecimento de software e a enviar alerta inicial às autoridades em até 24 horas após tomar conhecimento de um incidente significativo. Um caso como o da IDCF Cloud cairia nesse regime desde o primeiro dia.
No Brasil, a Resolução CD/ANPD nº 15, de 2024, dá aos controladores três dias úteis para comunicar incidentes com dados pessoais. A obrigação recai sobre cada cliente, não sobre o provedor de nuvem. Um ataque com centenas de clientes afetados, como o da IDCF Cloud, colocaria centenas de empresas para notificar a ANPD ao mesmo tempo, todas dependendo de informações que só o fornecedor tem.
O relatório da IDC Frontier levou três semanas para nomear a causa e ainda não nomeia o componente. Para quem contrata nuvem regional, a pergunta a fazer ao fornecedor deixou de ser se ele tem backup. Passou a ser quem testa o código aberto do portal de login e com que frequência.
Fontes
- idcf.jphttps://www.idcf.jp/news/topics/20261027001
- itmedia.co.jphttps://www.itmedia.co.jp/news/article/2610/28/2000002655/
- news.mynavi.jphttps://news.mynavi.jp/techplus/article/20261028-5208848/
- sbbit.jphttps://www.sbbit.jp/article/cont1/187833
- news.infoseek.co.jphttps://news.infoseek.co.jp/article/jiji_2026102701080/
- bernama.comhttps://www.bernama.com/en/world/news.php?id=2625983