O governo dos Estados Unidos anunciou a apreensão de centenas de domínios usados para transmitir ilegalmente partidas da Copa do Mundo, em uma operação realizada pouco antes do início da fase eliminatória do torneio. Segundo o Departamento de Justiça dos EUA, quase 400 sites foram retirados do ar. A ação teve como foco plataformas que distribuíam transmissões não autorizadas dos jogos, violando leis de direitos autorais e movimentando ecossistemas de pirataria digital frequentemente associados a outros riscos para os usuários. Autoridades norte-americanas alertaram que o problema vai além da infração de propriedade intelectual. De acordo com Eric Weindorf, agente especial responsável pelo escritório de Washington da Homeland Security Investigations, os serviços ilegais de streaming também podem expor espectadores a ameaças como malware, conexões inseguras e comprometimento de dados pessoais e financeiros. A operação contou com apoio da FIFA, entidade organizadora da Copa do Mundo, que ajudou a identificar os domínios suspeitos. O Departamento de Justiça também citou a colaboração da NBC Universal, emissora detentora de direitos de transmissão nos Estados Unidos, além de outras organizações envolvidas na identificação e interrupção das plataformas. A coordenação da ação ficou a cargo da Homeland Security Investigations, divisão vinculada ao Departamento de Segurança Interna dos EUA, em conjunto com a International Computer Hacking and Intellectual Property Network, rede formada por promotores norte-americanos especializados em crimes cibernéticos, propriedade intelectual e cooperação internacional. De acordo com o Departamento de Justiça, servidores e domínios relacionados ao streaming ilegal de partidas da Copa do Mundo foram alvo de medidas no Peru e na Bulgária, países citados pelas autoridades como centros conhecidos de atividade de pirataria online. Outras ações apoiadas pela rede ICHIP também ocorreram na Croácia, Romênia, Polônia e Colômbia. A iniciativa amplia uma estratégia já usada em competições anteriores. Durante a Copa do Mundo de 2022, a HSI liderou uma operação semelhante que resultou na apreensão de mais de 70 sites usados para transmissões ilegais. As transmissões esportivas piratas costumam circular por meio de serviços de IPTV, tecnologia que permite a entrega de conteúdo televisivo pela internet. Embora o IPTV também seja usado por serviços legítimos, ele se tornou um dos principais canais para distribuição ilegal de eventos esportivos, filmes, séries e canais pagos. Nos últimos anos, autoridades de diferentes países intensificaram ações contra grandes operações ilícitas de streaming, incluindo plataformas como Streameast e 247TVStream. Investigações anteriores indicaram que esses serviços podem gerar milhões de dólares em receita, muitas vezes por meio de assinaturas clandestinas, publicidade irregular e redes de revenda. Além do impacto financeiro sobre detentores de direitos de transmissão, clubes, ligas e empresas de mídia, os sites de streaming ilegal criam uma superfície de risco para os usuários. Em muitos casos, essas páginas usam anúncios agressivos, redirecionamentos suspeitos, players falsos e downloads enganosos, que podem ser explorados para instalar malware ou coletar dados sensíveis. A operação foi anunciada no momento em que a fase eliminatória da Copa do Mundo começava. No domingo, o Canadá venceu a África do Sul com um gol nos minutos finais e avançou na competição, marcando o início da etapa decisiva do torneio.

Grandes empresas japonesas divulgaram incidentes cibernéticos nas últimas duas semanas, envolvendo exposição de dados de clientes, interrupção de sistemas internos e investigações ainda em andamento. Os casos atingem setores distintos da economia, incluindo seguros, telecomunicações, fabricação de componentes eletrônicos e bebidas. As companhias afetadas incluem a Aflac Life Insurance Japan, subsidiária japonesa da seguradora norte-americana Aflac; a Sapporo Holdings, por meio de subsidiárias no exterior; a fabricante industrial Nidec, em uma unidade de Taiwan; e a operadora de telecomunicações KDDI Corporation. Até o momento, não há evidências públicas de que os ataques estejam conectados ou tenham sido conduzidos pelo mesmo grupo hacker. O maior incidente divulgado envolve a Aflac Life Insurance Japan, que informou ter identificado o comprometimento de seu portal de clientes e de outros sistemas. Segundo a empresa, a invasão expôs informações pessoais de aproximadamente 4,38 milhões de segurados. Os dados afetados incluem nomes, endereços e números de telefone de clientes. Além disso, cerca de 230 mil pessoas tiveram informações relacionadas a contas usadas para pagamento de prêmios de seguro comprometidas. Após detectar a intrusão, a Aflac afirmou ter suspendido partes de seus sistemas como medida de contenção. Ainda assim, a empresa continuou processando solicitações de seguro e atendendo clientes por meio de call centers e outros canais. A companhia informou que o incidente ficou limitado às operações japonesas e não afetou seus negócios nos Estados Unidos. A seguradora notificou a polícia japonesa e autoridades de cibersegurança sobre o caso, mas ainda não identificou os responsáveis pelo ataque. A Aflac também apresentou um comunicado 8-K à Securities and Exchange Commission, órgão regulador do mercado financeiro dos Estados Unidos, informando o incidente. Outro caso foi divulgado pela Sapporo Holdings, gigante japonesa do setor de bebidas. A empresa informou ter identificado suspeita de acesso não autorizado envolvendo duas subsidiárias no exterior: a Pokka, companhia de alimentos e bebidas sediada em Singapura, e a Sleeman Breweries, cervejaria canadense. Segundo a Sapporo, atividades suspeitas na rede indicaram a possibilidade de um ataque cibernético. Como resposta, a companhia desligou os sistemas afetados enquanto investiga se houve roubo de dados. Desde a divulgação inicial, a empresa não apresentou novos detalhes públicos sobre o caso e informou não ter encontrado impacto sobre suas operações domésticas no Japão. O incidente ocorre após outros episódios de interrupção cibernética no setor cervejeiro japonês. No ano passado, a rival Asahi informou que um ataque de ransomware expôs informações pessoais de aproximadamente 1,5 milhão de clientes e afetou produção, lançamentos de produtos, processamento de pedidos e remessas em todo o Japão. A fabricante industrial Nidec também comunicou uma violação envolvendo parte da rede de sua subsidiária taiwanesa, a Nidec Chaun Choung Technology. A empresa atribuiu o incidente a operadores de ransomware e reconheceu a possibilidade de vazamento de informações, embora tenha afirmado não ter confirmado a publicação online de dados pessoais ou confidenciais. Posteriormente, o grupo de ransomware BlackField reivindicou a autoria do ataque e exigiu um resgate de US$ 2 milhões. O grupo afirmou ter roubado mais de dois terabytes de dados corporativos, incluindo registros de funcionários, informações financeiras, documentos de compras, dados de manufatura, arquivos jurídicos e registros de TI. As alegações dos invasores não foram verificadas de forma independente, e a Nidec não informou se mantém contato com os responsáveis pelo ataque. De acordo com a Nidec, a subsidiária afetada opera em uma rede independente, o que teria limitado o impacto do incidente sobre o restante da corporação. A empresa já havia sido alvo de ransomware em 2024, quando uma invasão contra sua divisão de manufatura de precisão no Vietnã foi reivindicada pelos grupos 8Base e Everest. Em um incidente separado, a KDDI Corporation informou que invasores obtiveram acesso não autorizado a um sistema de e-mail operado pela companhia para cinco provedores japoneses de internet: STNet, JCOM, Chubu Telecommunications, NIFTY e BIGLOBE. Segundo a KDDI, os hackers exploraram uma vulnerabilidade em software de terceiros para acessar o ambiente. A empresa afirmou ter bloqueado a intrusão imediatamente após a detecção, identificado o provável ponto de entrada e implementado medidas adicionais de segurança. A operadora alertou que os invasores podem ter obtido endereços de e-mail e senhas de clientes. O caso evidencia o risco associado a sistemas compartilhados e softwares de terceiros em ambientes de telecomunicações, especialmente quando uma única plataforma atende múltiplos provedores e pode ampliar o impacto potencial de uma falha explorada. Embora os incidentes não tenham sido vinculados entre si, a sequência de divulgações mostra como empresas japonesas de setores críticos e altamente conectados continuam expostas a diferentes formas de ataque. Os casos incluem desde comprometimento de portais de clientes e abuso de vulnerabilidades em software de terceiros até operações de ransomware com possível roubo de grandes volumes de dados corporativos.

Um homem de 19 anos, com dupla cidadania dos Estados Unidos e da Estônia, foi extraditado da Finlândia para Chicago nesta semana para responder a acusações criminais relacionadas à participação em ataques atribuídos ao grupo de cibercrime Scattered Spider. Peter Stokes compareceu inicialmente na terça-feira a um tribunal federal do Distrito Norte de Illinois, segundo o Departamento de Justiça dos Estados Unidos. A queixa criminal do FBI o acusa de conspiração, intrusão cibernética e fraude. O principal caso descrito na denúncia envolve a violação de dados de uma empresa não identificada do setor de joias de luxo, citada no documento como “Company F”. Segundo o FBI, por volta de 12 de maio de 2025, Stokes e possivelmente outros integrantes do Scattered Spider teriam roubado dados da companhia e exigido um resgate de US$ 8 milhões em criptomoedas. De acordo com a queixa, os invasores se passaram por usuários funcionários da empresa e solicitaram a redefinição de credenciais de autenticação, incluindo senha e dispositivo móvel usado para autenticação multifator. A técnica permitiu o comprometimento de três contas de usuários da empresa em um intervalo aproximado de duas a três horas. Entre elas estavam duas contas pertencentes a administradores de TI com acesso a contas de alto privilégio. A cadeia de ataque descrita pelo FBI se baseou principalmente em engenharia social contra o help desk de TI. Os suspeitos teriam usado números do Google Voice para ligar para o suporte interno, solicitar redefinições de senha e, a partir disso, acessar contas com níveis mais elevados de permissão. Esse tipo de abordagem é uma marca recorrente em campanhas associadas ao Scattered Spider, grupo conhecido por explorar processos de suporte, identidade digital e autenticação em vez de depender apenas de exploração técnica de vulnerabilidades. A denúncia também aponta que, após o acesso inicial, os responsáveis pela operação usaram o ngrok, uma ferramenta legítima usada por desenvolvedores para gerenciar tráfego de internet, para manter acesso não autorizado persistente ao data center da empresa. No contexto descrito pelo FBI, o uso da ferramenta teria funcionado como um meio de continuidade de acesso ao ambiente comprometido. A empresa de joias não pagou o resgate de US$ 8 milhões, segundo o FBI. Ainda assim, os prejuízos relacionados à interrupção de negócios, investigação e mitigação chegaram a aproximadamente US$ 2 milhões, com expectativa de perdas adicionais. O caso mostra como ataques baseados em engenharia social podem gerar impacto financeiro relevante mesmo quando a vítima não realiza o pagamento exigido pelos criminosos. A queixa revelada nesta semana também acusa Stokes de obter acesso não autorizado, em março de 2023, à rede de uma plataforma de comunicação online identificada no documento como “Company H”. Stokes, que segundo as autoridades usava os aliases “Bouquet”, “Spencer” e “Jordan”, foi preso por autoridades finlandesas em abril, após a emissão de um alerta vermelho da Interpol. O jornal Chicago Tribune havia noticiado a prisão no início da primavera no hemisfério norte. Após a audiência de terça-feira, ele permaneceu sob custódia das autoridades. O Scattered Spider é descrito como um grupo pouco estruturado, de língua inglesa, associado a diferentes operações de fraude e invasão. Integrantes ou supostos membros do grupo já foram acusados ou condenados por golpes com phishing via SMS, violações contra cassinos nos Estados Unidos, ataque a um sistema judicial federal e uma grande interrupção de rede na agência de transporte de Londres. O governo dos Estados Unidos estima que o Scattered Spider tenha participado de mais de 100 intrusões em redes e arrecadado mais de US$ 100 milhões em pagamentos de resgate. As acusações contra Stokes acrescentam mais um caso à série de investigações envolvendo o grupo, cuja atuação tem chamado atenção pelo uso agressivo de engenharia social, abuso de processos internos de autenticação e extorsão baseada em roubo de dados.

A OpenAI está trabalhando para corrigir uma falha no Codex que tem causado um volume excessivo de gravações em SSDs de usuários. O problema está ligado a uma implementação de logs locais baseada em SQLite, que passou a armazenar dados de diagnóstico em uma intensidade muito maior do que o previsto, gerando preocupação sobre desgaste prematuro de unidades de armazenamento. SSDs possuem vida útil limitada, normalmente medida em TBW, sigla para terabytes written, ou terabytes gravados. Esse indicador estima quanto uma unidade pode receber de dados ao longo de sua operação antes de apresentar maior risco de degradação, queda de desempenho ou falhas. O valor varia conforme modelo, capacidade e fabricante, mas gravações constantes e desnecessárias podem consumir rapidamente parte dessa margem. O alerta ganhou força após a abertura de um relatório de bug no repositório do agente de programação Codex. O título do issue já indicava a gravidade do comportamento observado: os logs de feedback em SQLite poderiam escrever cerca de 640 TB por ano e consumir rapidamente a resistência de SSDs. O desenvolvedor Rui Fan, integrante do comitê de gerenciamento do projeto Apache Flink, relatou que, após cerca de 21 dias de uptime, o SSD principal de sua máquina havia registrado aproximadamente 37 TB de dados gravados. Verificações em nível de processo e arquivo indicaram que os logs SQLite do Codex eram o principal responsável pela escrita contínua. Ao projetar esse ritmo para um ano, o volume chegaria a cerca de 640 TB. Em um SSD de 1 TB, isso representaria aproximadamente 640 gravações completas da unidade em 12 meses. Como alguns SSDs de consumo possuem garantia de resistência em torno de 600 TBW, esse comportamento poderia consumir praticamente toda a endurance coberta pela garantia em menos de um ano. O problema não significa necessariamente que todos os usuários sofrerão o mesmo impacto. A escala do desgaste depende de fatores como frequência de uso do Codex, modelo do SSD, capacidade da unidade, configuração do ambiente, tempo de atividade e volume real de logs gerados. Ainda assim, o caso expõe um risco operacional relevante em ferramentas de IA executadas localmente em máquinas de desenvolvimento. Outro desenvolvedor que participou da discussão afirmou que o próprio Codex analisou o uso de disco e estimou que o bug teria consumido US$ 38,64 em valor proporcional da vida útil de um SSD Samsung 990 NVMe de 2 TB. O mesmo usuário citou uma estimativa gerada pelo Codex segundo a qual a regressão poderia ter causado um consumo de endurance equivalente a alguns milhões de dólares entre usuários durante o período de março a junho. Essa estimativa parte de uma conta econômica simples: o custo por terabyte gravado é calculado com base no preço do SSD dividido pela resistência nominal em TBW. Assim, quanto mais dados são escritos sem necessidade, maior é a parcela proporcional da vida útil consumida. Em um exemplo citado no texto original, um SSD de 1 TB avaliado em US$ 200 e com resistência de 600 TBW teria custo estimado de US$ 0,333 por terabyte gravado. Nesse cenário, os 37 TB registrados por Rui Fan representariam cerca de US$ 12,33 em desgaste proporcional. Unidades maiores e mais caras, com ratings de TBW superiores, podem apresentar custo menor por terabyte escrito. Um SSD de 2 TB com resistência de 1.200 TBW, por exemplo, dilui melhor o impacto de cada gravação. Mesmo assim, o ponto central permanece: uma ferramenta de software não deveria gerar escrita contínua desnecessária a ponto de afetar a durabilidade de hardware dos usuários. A falha está relacionada a logs diagnósticos locais, não diretamente à telemetria enviada à OpenAI. Em dezembro de 2025, desenvolvedores do Codex anunciaram planos para adicionar telemetria por padrão ao Codex CLI, exceto onde a prática fosse proibida por lei. O caso atual, porém, envolve registros armazenados no próprio dispositivo do usuário, criados para auxiliar engenheiros da empresa na investigação de problemas. Esses logs permanecem localmente, a menos que sejam incluídos pelo usuário em um relatório de feedback. Ainda assim, por serem gerados em grande volume, acabaram produzindo atividade intensa de disco. Segundo a OpenAI, os registros tinham finalidade diagnóstica, mas dados de alto volume foram armazenados de uma forma que criou muito mais I/O do que o antecipado. Um porta-voz da empresa confirmou que os engenheiros estão cientes do problema e trabalham em correções. Pull requests recentes no projeto indicam esforços para ajustar o comportamento dos logs e reduzir o volume de gravações. Apesar disso, usuários continuaram registrando problemas, o que sugere que a mitigação ainda exige validação adicional em diferentes ambientes. A origem do comportamento parece estar associada a mudanças feitas em fevereiro para gravar logs SQLite do app-server no nível TRACE. Esse nível é muito mais detalhado do que níveis como ERROR, que registram apenas falhas mais graves. Em ferramentas distribuídas amplamente, manter logs em nível muito verboso pode causar impactos em desempenho, armazenamento, privacidade e durabilidade de dispositivos. O caso também chama atenção porque a própria série de commits relacionada teria sido revisada pelo Codex, possivelmente executando GPT-5.3. Isso torna o episódio particularmente simbólico: uma ferramenta de IA usada para apoiar revisão de código não teria identificado adequadamente uma decisão de engenharia capaz de gerar desgaste significativo em hardware. Para desenvolvedores, o incidente reforça a necessidade de monitorar o comportamento operacional de ferramentas de IA instaladas localmente. Agentes de programação podem executar processos persistentes, indexar projetos, observar arquivos, analisar código, manter estados locais e registrar diagnósticos continuamente. Mesmo sem intenção maliciosa, decisões inadequadas de logging podem gerar custos reais. Em ambientes corporativos, o problema também tem implicações práticas. Máquinas de desenvolvimento e runners de CI já lidam com cargas intensas de I/O, builds, testes, containers, cache de dependências e ferramentas de análise. Um agente que grava dados continuamente pode afetar a confiabilidade desses endpoints, aumentar custos de suporte e reduzir a vida útil de equipamentos. A recomendação para usuários do Codex é aplicar atualizações assim que correções forem disponibilizadas, monitorar o volume de escrita em disco e revisar diretórios de logs associados à ferramenta. Também é prudente observar processos com atividade contínua de I/O e avaliar configurações de logging até que o problema seja resolvido de forma definitiva. O episódio mostra que ferramentas de IA para desenvolvimento precisam ser avaliadas não apenas pela produtividade que entregam, mas também pelo impacto sobre o sistema do usuário. Consumo de CPU, memória, rede, armazenamento e operações de escrita em disco passam a fazer parte da análise de segurança, governança e confiabilidade desses agentes.

Usuários do Claude Code, ferramenta de programação da Anthropic, vêm relatando a exclusão inesperada de históricos de conversa dentro do aplicativo. Segundo reclamações abertas no repositório do projeto no GitHub, transcrições de chats estão desaparecendo sem aviso claro, especialmente quando ultrapassam 30 dias de idade. O problema estaria relacionado à opção de configuração cleanupPeriodDays, que vem definida por padrão para 30 dias. Na prática, sempre que o Claude Code é iniciado, o mecanismo de limpeza verifica arquivos de transcrição no formato .jsonl e remove aqueles considerados antigos demais. Para usuários que dependem dessas conversas como registro de decisões técnicas, raciocínios de depuração, análises e contexto de projeto, a exclusão pode representar perda relevante de informação. A Anthropic afirmou que a política de apagamento em 30 dias existe desde o lançamento do Claude Code como uma medida de segurança e está documentada. Segundo a empresa, manter transcrições em texto claro de sessões de programação no disco por tempo indefinido cria riscos reais de segurança e privacidade, já que esses registros podem conter código-fonte, credenciais e outros dados sensíveis. A companhia argumenta que o padrão de 30 dias busca equilibrar a capacidade de retomar trabalhos recentes com a necessidade de não armazenar dados locais por mais tempo do que o necessário. Do ponto de vista de segurança, a decisão tem lógica: históricos de interação com assistentes de código podem conter trechos de sistemas internos, tokens, chaves de API, caminhos de infraestrutura, erros de configuração e outras informações que não deveriam permanecer indefinidamente no dispositivo. A crítica dos usuários, porém, está menos na existência de uma política de retenção e mais na forma como ela é aplicada. De acordo com relatos no GitHub, o Claude Code não informa claramente durante a instalação, na primeira execução ou antes da limpeza que conversas com mais de 30 dias serão apagadas automaticamente. Também não haveria um aviso visível sobre a existência dessa configuração. Um dos usuários afirmou que a limpeza é executada “out of the box”, sem divulgação no momento da instalação nem diálogo inicial, levando pessoas a acreditarem que o histórico de conversas é mais durável do que realmente é. Para quem usa o Claude Code como parte de um fluxo contínuo de trabalho, essa diferença entre expectativa e comportamento real pode gerar impacto direto na produtividade. Outro relato destacou que, após a limpeza, o código do projeto e o histórico do Git continuaram disponíveis, mas o “rastro de raciocínio” foi perdido. Isso inclui discussões de design, contexto de debugging e análises feitas ao longo do processo. Para trabalhos de pesquisa, desenvolvimento exploratório ou investigação de problemas complexos, esse contexto pode ser tão importante quanto o próprio código final. O recurso de limpeza também parece não oferecer mecanismos de recuperação. Usuários apontam ausência de exclusão reversível, período de carência, opção de restauração ou registro detalhado do que foi removido. Isso significa que, depois da exclusão, pode não haver forma simples de confirmar quais conversas foram apagadas ou recuperar o conteúdo perdido. Outro ponto levantado na discussão é que aumentar o período de retenção nem sempre resolveria o problema. Alguns usuários relataram que configurar valores maiores não funciona como esperado. Uma análise de causa raiz feita por um participante sugere que a exclusão se baseia no mtime, ou horário de modificação do arquivo, em vez de usar o horário real da última atividade da conversa. Esse detalhe técnico pode gerar resultados inesperados porque o mtime é mutável por fatores externos. Um processo de restauração, uma ferramenta de sincronização, um script ou um backup que altere a data de modificação dos arquivos pode fazer uma sessão ainda relevante parecer antiga para o mecanismo de limpeza. Na próxima execução do Claude Code, o transcript pode ser removido silenciosamente. Até o momento, a principal solução sugerida pelos próprios usuários é manter backups das transcrições do Claude Code. Diferentes abordagens foram propostas na discussão, incluindo cópias periódicas dos arquivos de conversa antes da inicialização da ferramenta. Ainda assim, parte da comunidade considera essa recomendação insuficiente. Para esses usuários, backup é uma boa prática, mas não substitui uma política clara de produto para uma operação destrutiva. A expectativa é que o Claude Code informe melhor a existência da retenção automática, registre o que foi apagado, ofereça opções de recuperação ou permita configurar o comportamento de forma mais transparente. O caso expõe uma tensão recorrente em ferramentas locais de IA para desenvolvimento. Por um lado, armazenar conversas indefinidamente em texto claro pode ampliar riscos de vazamento, especialmente quando o conteúdo envolve código proprietário, credenciais, dados sensíveis ou detalhes de infraestrutura. Por outro, apagar automaticamente esse histórico sem aviso explícito pode comprometer fluxos de trabalho, auditoria técnica e continuidade de projetos. Em ambientes corporativos, a questão é ainda mais relevante. Assistentes de código vêm sendo usados para depuração, revisão, arquitetura, documentação e tomada de decisão técnica. Quando a conversa com a IA passa a conter justificativas, hipóteses, decisões de design e contexto de incidentes, o histórico deixa de ser apenas um chat e passa a funcionar como um artefato de trabalho. A controvérsia também reforça a necessidade de políticas internas para uso de agentes de IA. Empresas que utilizam ferramentas como Claude Code, GitHub Copilot, Codex ou outros assistentes de desenvolvimento devem definir onde conversas podem ser armazenadas, por quanto tempo, com que nível de criptografia, quem pode acessá-las e como backups ou retenção devem ser tratados. Para usuários individuais, a recomendação prática é revisar a documentação e as configurações de retenção do Claude Code, especialmente a opção cleanupPeriodDays. Quem depende dos históricos para pesquisa, desenvolvimento ou documentação deve considerar backups externos e verificar se ferramentas de sincronização ou restauração podem alterar metadados dos arquivos. A Anthropic defende que o comportamento foi desenhado como medida de segurança. Ainda assim, os relatos indicam que a experiência de uso não deixou essa política clara o suficiente para parte da base de usuários. Em ferramentas que lidam com código e dados potencialmente sensíveis, a transparência sobre retenção, exclusão e recuperação é tão importante quanto o próprio mecanismo de proteção.

Ferramentas de pentest totalmente automatizadas vêm perdendo espaço entre profissionais de segurança da informação. Segundo o relatório 2026 State of Pentesting, da Cobalt, a parcela de profissionais abertos à adoção de pentests totalmente autônomos caiu de 29% no ano passado para apenas 9% neste ano. O recuo ocorre em meio à frustração de equipes de segurança com ferramentas que prometem encontrar falhas de forma automatizada, mas ainda deixam passar vulnerabilidades críticas. De acordo com a Cobalt, 78% dos entrevistados no levantamento relataram ter enfrentado “falsos negativos críticos” em ferramentas automatizadas de varredura. Na prática, falsos negativos críticos ocorrem quando uma solução deixa de identificar uma vulnerabilidade grave existente no ambiente. Esse tipo de falha é especialmente preocupante porque pode criar uma sensação indevida de segurança. A organização acredita que determinado sistema foi validado, quando, na realidade, uma brecha relevante permanece explorável. A Cobalt afirma que scanners automatizados funcionam bem para identificar vulnerabilidades conhecidas e baseadas em assinaturas, mas apresentam desempenho muito inferior em cenários envolvendo segurança de inteligência artificial. O problema está no tipo de falha que ambientes baseados em IA e LLMs tendem a introduzir. Explorações de prompt injection, falhas de agência excessiva e vulnerabilidades lógicas em modelos de linguagem normalmente exigem interação criativa, múltiplas etapas, adaptação ao contexto e compreensão adversarial do comportamento do sistema. Esses elementos são difíceis de capturar por ferramentas que executam consultas automatizadas simples, de uma única tentativa. Prompt injection, por exemplo, ocorre quando um usuário ou atacante manipula entradas para fazer um sistema de IA ignorar instruções, vazar informações, executar ações indevidas ou alterar seu comportamento esperado. Já falhas de agência excessiva aparecem quando um agente de IA recebe autonomia demais para interagir com ferramentas, sistemas, APIs ou dados sensíveis sem controles adequados. Essas vulnerabilidades não se parecem com falhas tradicionais facilmente detectáveis por assinatura, como versões desatualizadas de software, configurações inseguras conhecidas ou endpoints expostos. Muitas dependem de lógica de negócio, fluxo de conversação, permissões, contexto operacional e combinações específicas de ações. Esse descompasso ajuda a explicar a queda na confiança em pentests totalmente automatizados. Após um ano de uso e avaliação dessas ferramentas, muitas organizações parecem ter concluído que cobertura automatizada não equivale necessariamente a garantia real de segurança. A própria Cobalt interpreta a redução de interesse como um sinal positivo de maturidade. Para a empresa, os profissionais estão enxergando além do discurso de fornecedores e exigindo validações mais concretas, em vez de aceitar apenas relatórios extensos de cobertura automatizada. O levantamento da Cobalt ouviu 450 profissionais, uma amostra relativamente pequena. Ainda assim, os dados indicam uma mudança relevante na percepção do mercado, especialmente porque a queda foi expressiva: de quase um terço dos respondentes abertos à ideia de pentest totalmente autônomo para menos de um décimo. A preocupação se torna maior diante do aumento de vulnerabilidades em ambientes que utilizam IA. Segundo dados de pentest citados pela Cobalt, cerca de 12% das vulnerabilidades detectadas em ambientes tradicionais são classificadas como de severidade alta ou crítica. Em ambientes com IA e LLMs, esse índice sobe para 32%. Esse percentual de 32% teria se mantido nos últimos dois anos, indicando que sistemas baseados em IA continuam introduzindo uma proporção maior de falhas relevantes. Quando esse cenário é combinado a ferramentas automatizadas que não conseguem detectar bem esse tipo de vulnerabilidade, o risco operacional aumenta. O desafio não está apenas na adoção de IA pelas equipes de segurança, mas também no uso de IA por áreas de desenvolvimento, atendimento, automação, análise de dados e operações. À medida que empresas incorporam modelos de linguagem e agentes em processos internos, novas superfícies de ataque surgem em integrações com APIs, bases de dados, ferramentas corporativas e fluxos de decisão automatizados. A Cobalt defende uma abordagem híbrida. Nesse modelo, sistemas de menor criticidade podem passar por varreduras automatizadas, enquanto ambientes críticos, aplicações sensíveis e sistemas baseados em IA exigem avaliação humana especializada. A proposta é combinar velocidade e escala das ferramentas com análise contextual de profissionais experientes. A recomendação tem interesse comercial, já que a própria Cobalt vende soluções nessa linha. Ainda assim, a conclusão não está isolada no mercado. A Veracode, empresa de segurança de aplicações, também alertou anteriormente que o desenvolvimento assistido por IA vem criando mais vulnerabilidades do que as equipes conseguem corrigir. Segundo a Veracode, 82% das empresas deixam vulnerabilidades conhecidas sem correção por mais de um ano, enquanto a participação de falhas de alto risco no total de vulnerabilidades descobertas também vem crescendo. Esse dado reforça a pressão sobre equipes de AppSec, DevSecOps e segurança ofensiva, que precisam lidar com mais código, mais automação e mais sistemas gerados ou modificados com apoio de IA. Nem todos, porém, adotam uma visão tão cética sobre pentest automatizado. CJ Moses, chefe de segurança da Amazon, afirmou que ferramentas de pentest baseadas em IA tornaram as equipes de segurança da companhia 40% mais eficientes, embora a métrica exata usada para esse cálculo não tenha sido detalhada. Mesmo assim, Moses também defendeu a presença de humanos no processo. Em entrevista durante a RSA Conference, ele afirmou que a IA é muito boa para executar tarefas, especialmente quando há grandes volumes de dados e necessidade de visão ampla. Porém, do ponto de vista de tomada de decisão, ainda não é uma tecnologia na qual a empresa esteja pronta para confiar integralmente. Essa visão reflete uma tendência mais equilibrada no setor. A automação pode acelerar tarefas repetitivas, ampliar cobertura, priorizar achados, correlacionar dados e apoiar analistas. Mas a identificação de falhas complexas, especialmente em sistemas de IA, ainda depende de raciocínio adversarial, conhecimento de contexto, criatividade e validação manual. O caso também reforça uma diferença importante entre “scanner” e “pentest”. Uma varredura automatizada pode identificar problemas conhecidos, mas um teste de invasão efetivo busca entender como falhas podem ser encadeadas, exploradas e transformadas em impacto real para o negócio. Em ambientes com IA, essa diferença fica ainda mais evidente. Para empresas, a principal lição é evitar tanto a rejeição total da automação quanto a confiança excessiva nela. Ferramentas automatizadas podem ser úteis, mas não devem substituir avaliações humanas em sistemas críticos, ambientes com dados sensíveis, aplicações expostas à internet, integrações com IA e fluxos que envolvem tomada de decisão ou acesso privilegiado. À medida que a IA passa a gerar código, operar agentes, interagir com APIs e apoiar processos corporativos, a segurança ofensiva também precisa evoluir. O pentest do futuro tende a ser menos uma disputa entre humanos e máquinas e mais uma combinação entre automação, análise especializada e validação contínua de riscos reais.

Líderes de agências de inteligência dos países Five Eyes — Austrália, Canadá, Nova Zelândia, Estados Unidos e Reino Unido — emitiram um alerta conjunto para que organizações tratem a segurança cibernética como prioridade executiva diante da aceleração dos riscos impulsionados por inteligência artificial. A orientação afirma que o avanço rápido da IA de fronteira pode tornar premissas de risco cibernético obsoletas em questão de meses, não de anos. Para as agências, embora a IA também possa fortalecer a defesa ao longo do tempo, ela já amplia a velocidade, a escala e a sofisticação das ameaças digitais. O comunicado aponta que modelos avançados de IA devem superar expectativas atuais da indústria e transformar tanto capacidades ofensivas quanto defensivas no ambiente cibernético. A mensagem central é direta: a janela de adaptação para empresas, governos e organizações críticas ficou mais curta. Segundo os líderes de inteligência, a resiliência cibernética deve ser vista como parte essencial da continuidade de negócios, da confiança do mercado e da geração de valor de longo prazo. O alerta busca tirar a segurança da informação do campo puramente técnico e colocá-la no centro da gestão de risco corporativo. As recomendações dos Five Eyes se concentram em quatro frentes: entender e avaliar risco, prontidão e responsabilidade; priorizar práticas e controles fundamentais de segurança; dar autoridade e recursos aos líderes de cibersegurança; e manter envolvimento ativo conforme ameaças e orientações evoluem. O documento reforça que o risco cibernético não pode mais ser tratado como uma questão exclusiva de TI. Para as agências, ele é um risco central de negócio e uma responsabilidade da liderança, porque violações vão ocorrer. A diferença estará na capacidade de conter rapidamente os incidentes e impedir que eles escalem para crises operacionais e financeiras de grande impacto. Esse ponto ganha peso em um contexto no qual ataques digitais podem interromper serviços, comprometer cadeias de suprimentos, gerar perdas financeiras, expor dados sensíveis e afetar reputação. Com IA acelerando reconhecimento, exploração e automação de ataques, o tempo entre a descoberta de uma falha e sua exploração tende a ficar ainda menor. Os chefes de inteligência também defendem que organizações testem sua resiliência cibernética de forma prática. Segundo o comunicado, não basta possuir controles implementados; líderes precisam ter confiança de que esses controles funcionarão durante um incidente real. Essa orientação envolve reavaliar escolhas antigas, testar planos de resposta, simular cenários adversos e usar IA de maneira deliberada para fortalecer a defesa. O objetivo não deve ser apenas melhorar eficiência, mas aumentar a capacidade de detectar, conter e recuperar operações em caso de ataque. O alerta também reconhece o lado defensivo da IA. Organizações que integram ferramentas de inteligência artificial em suas operações de segurança podem detectar vulnerabilidades mais cedo, melhorar a qualidade do software, monitorar comportamentos incomuns e responder a incidentes com mais rapidez. Essas capacidades podem reduzir tanto o custo quanto o impacto dos ataques. Ainda assim, o documento deixa claro que a mesma tecnologia também amplia o potencial ofensivo dos invasores. IA generativa e agentes autônomos podem ajudar na criação de phishing mais convincente, automação de reconhecimento, priorização de alvos, exploração de vulnerabilidades, geração de código malicioso e adaptação de ataques em larga escala. O interesse por esse risco aumentou após a divulgação de modelos avançados voltados à descoberta de falhas, como o Mythos, da Anthropic. A preocupação é que capacidades criadas para apoiar defensores também possam ser usadas por criminosos para encontrar brechas em softwares importantes com maior velocidade. Embora o alerta tenha tom forte, as ações recomendadas pelos Five Eyes não são novas. O próprio documento reconhece que são medidas conhecidas, mas agora urgentes para reduzir não apenas riscos técnicos, mas também exposição operacional, financeira e reputacional. A primeira ação prática é reduzir a superfície de ataque. Isso significa limitar acessos desnecessários a sistemas, revisar conectividade externa, questionar se determinados ambientes realmente precisam estar expostos e isolar sistemas que não deveriam estar acessíveis a redes amplas ou à internet. A segunda recomendação é acelerar processos de correção. As agências afirmam que a IA está encurtando o intervalo entre a descoberta de uma vulnerabilidade e sua exploração. Atrasos em patches aumentam o risco, especialmente em sistemas operacionais, ambientes críticos e plataformas com ciclos longos de atualização. A terceira orientação é enfrentar sistemas legados. Ambientes sem suporte não devem ser vistos apenas como dívida técnica, mas como passivos estratégicos. Sistemas antigos, desatualizados ou difíceis de corrigir continuam sendo alvos fáceis, principalmente quando permanecem conectados a operações relevantes. A quarta medida é revisar e fortalecer controles de identidade e acesso. As organizações devem limitar quem pode acessar sistemas críticos, aplicar autenticação forte e revisar permissões regularmente. Contas privilegiadas, acessos antigos, credenciais compartilhadas e permissões excessivas seguem entre os caminhos mais explorados por invasores. A quinta recomendação é preparar-se para incidentes antes que eles aconteçam. Isso inclui testar planos de resposta, treinar equipes, simular ataques e assumir que violações ocorrerão. O foco deve ser contenção rápida, recuperação eficiente e redução do impacto sobre operações, finanças e reputação. O alerta dos Five Eyes também reforça a importância de dar autoridade e recursos reais aos líderes de segurança. Sem apoio executivo, equipes de cibersegurança podem ter dificuldade para corrigir riscos estruturais, substituir sistemas legados, impor controles de acesso, reduzir exposição e acelerar atualizações críticas. A mensagem é especialmente relevante para organizações de grande porte, setores regulados, infraestrutura crítica e empresas com cadeias de suprimentos complexas. Nessas estruturas, um incidente cibernético pode se espalhar rapidamente e gerar efeitos além do ambiente técnico, afetando clientes, parceiros, fornecedores e operações essenciais. A conclusão das agências é que a IA muda o ritmo do risco cibernético. Empresas que ainda dependem de controles frágeis, processos lentos de patching, sistemas legados e baixa governança de identidade tendem a ficar mais expostas. A resposta precisa ser liderada no nível executivo, com foco em resiliência, continuidade e capacidade de reação.

A Anthropic voltou a disponibilizar mundialmente o Claude Fable 5 após o Departamento de Comércio dos Estados Unidos suspender, em 30 de junho, os controles de exportação impostos ao modelo e ao Mythos 5 cerca de duas semanas e meia antes. O Fable 5 retorna aos usuários em 1º de julho, com acesso pelo Claude.ai, Claude Platform, Claude Code e Claude Cowork. A medida encerra, ao menos por enquanto, uma disputa envolvendo segurança de modelos avançados de IA, risco de uso dual, competição internacional e a ausência de um processo regulatório claro para respostas rápidas do governo americano diante de possíveis capacidades perigosas em sistemas de fronteira. Os controles de exportação restringem quem pode receber ou usar determinada tecnologia. A ordem de 12 de junho determinava que a Anthropic interrompesse o acesso aos modelos Fable 5 e Mythos 5 para qualquer cidadão estrangeiro, dentro ou fora dos Estados Unidos, incluindo funcionários não cidadãos da própria empresa. Como a regra entrou em vigor imediatamente e a Anthropic não tinha uma forma confiável de verificar em tempo real a nacionalidade de todos os usuários, a companhia decidiu retirar ambos os modelos do ar para todos. Na prática, uma restrição voltada a usuários estrangeiros levou à suspensão global temporária do acesso. O gatilho para a decisão foi um jailbreak identificado por pesquisadores da Amazon no Fable 5. Jailbreaks são prompts ou técnicas criadas para fazer um modelo contornar suas regras de segurança. Segundo a Anthropic, o prompt fazia o modelo sinalizar algumas falhas de software e, em um caso, escrever código demonstrando como uma vulnerabilidade poderia ser abusada. A Anthropic minimizou a gravidade da descoberta. A empresa afirmou que solicitações semelhantes funcionam em vários modelos considerados menos avançados, incluindo seu próprio Claude Opus 4.8, o GPT-5.5 da OpenAI e o Kimi K2.7, da China. Para a companhia, o comportamento apontado estava mais próximo de atividades rotineiras de segurança defensiva do que de uma capacidade oculta e extraordinária. O governo americano e o parceiro que relatou o jailbreak, no entanto, trataram o caso como suficientemente sério para justificar controles emergenciais. A preocupação central era que um modelo capaz de ajudar defensores a encontrar e corrigir falhas também pudesse ser usado por agentes maliciosos para acelerar a descoberta e exploração de vulnerabilidades. Para responder à preocupação, a Anthropic treinou um novo filtro de segurança, chamado de classificador, voltado a identificar a técnica exata descrita no relatório. Segundo a empresa, o mecanismo passou a bloquear mais de 99% das tentativas relacionadas a esse método, conforme publicação de 30 de junho. Quando uma solicitação é bloqueada, ela passa a ser encaminhada ao modelo mais fraco Claude Opus 4.8, e o usuário é informado. A empresa reconhece, porém, que essa abordagem tem um custo: aumento de falsos positivos em tarefas legítimas de programação, depuração e análise de código. O Mythos 5, descrito como o mesmo modelo subjacente, mas com menos barreiras de segurança, permanece sob controle mais rígido. O acesso foi restabelecido em 26 de junho para cerca de 100 empresas americanas e agências federais envolvidas na defesa de infraestrutura crítica. A Anthropic afirma que ainda trabalha com o governo para ampliar o acesso. O secretário de Comércio dos EUA, Howard Lutnick, responsável pela reversão, afirmou que o departamento passou duas semanas revisando os modelos junto com a Anthropic. Em uma carta, a empresa concordou em buscar problemas de segurança por conta própria, coordenar lançamentos futuros e reportar usos maliciosos que venha a identificar. As negociações teriam sido conduzidas pelo cofundador Tom Brown, e não pelo CEO Dario Amodei, que vinha enfrentando atritos com a administração americana ao longo do ano. A disputa também foi marcada por ruído político e competitivo desde o início. Relatos de veículos como The Wall Street Journal indicaram que a pesquisa da Amazon e preocupações do CEO Andy Jassy ajudaram a impulsionar a ordem original. O ex-czar de IA David Sacks acusou a Anthropic de ter priorizado a continuidade da oferta do modelo de consumo em detrimento da segurança. Outros analistas interpretaram a resposta do governo como um exagero. Francesco Bailo, pesquisador de governança de IA da Universidade de Sydney, disse à Al Jazeera que a reversão parecia indicar que o governo havia reconhecido ter ido longe demais. Um grupo de líderes de segurança também assinou uma carta aberta pedindo a suspensão dos controles. A disputa ocorreu em meio à crescente competição internacional em IA. A pausa no acesso aos modelos americanos veio em um momento no qual modelos chineses open source, mais baratos e cada vez mais capazes, vinham ganhando espaço. Executivos do setor alertaram que congelar modelos dos Estados Unidos poderia dar tempo adicional para concorrentes estrangeiros avançarem. Além de restaurar o Fable 5, a Anthropic está propondo algo que ainda falta à indústria: uma forma compartilhada de classificar a gravidade de jailbreaks. Em colaboração com Amazon, Microsoft, Google e outros parceiros, a empresa quer avaliar cada técnica com base em quatro critérios principais. O primeiro é o ganho de capacidade, ou seja, até que ponto o jailbreak leva o usuário além das ferramentas e capacidades que ele já teria. O segundo é a amplitude, medindo quantos tipos diferentes de ataque uma mesma técnica desbloqueia. O terceiro é a facilidade de weaponization, isto é, quanto conhecimento e esforço são necessários para transformar a técnica em um ataque real. O quarto é a descobribilidade, que avalia quão fácil é encontrar, copiar ou reproduzir o método. Para os casos mais graves, como jailbreaks capazes de permitir ataques contra redes elétricas, bancos ou outras infraestruturas críticas, a Anthropic afirma que começará a implementar correções assim que a severidade for confirmada. A empresa também está criando uma equipe para acompanhar relatos de jailbreaks de forma contínua. A companhia abriu ainda um programa no HackerOne para que pesquisadores reportem novos jailbreaks no Fable 5. Como parte dos compromissos assumidos, a Anthropic também prometeu ao governo dos Estados Unidos acesso antecipado para testar futuros modelos de fronteira antes do lançamento. A Anthropic não é a única empresa pressionada por esse dilema. Dias antes, a OpenAI apresentou o GPT-5.6 a um grupo pequeno e aprovado pelo governo, em vez de abrir o acesso ao público, citando a mesma preocupação de uso dual. O problema é estrutural: um modelo bom o suficiente para ajudar defensores a corrigir vulnerabilidades também pode ser útil para atacantes encontrarem e explorarem falhas. O risco não é apenas teórico. No início do ano, a Anthropic testou uma versão anterior do Mythos que encontrou e explorou vulnerabilidades zero-day sob comando em grandes sistemas operacionais e navegadores, incluindo uma falha de 27 anos no OpenBSD. A equipe de red team da empresa também conseguiu transformar falhas recém-divulgadas em exploits funcionais em menos de um dia. A crise imediata envolvendo o Fable 5 foi resolvida com a suspensão dos controles emergenciais, mas a questão regulatória permanece aberta. Uma ordem executiva de 2 de junho criou um caminho voluntário para que empresas submetam modelos de fronteira a revisão antes do lançamento. Também estabeleceu um benchmark classificado para definir quais modelos seriam considerados “cobertos”, mas descartou a exigência de licença obrigatória para disponibilizar um modelo. O Fable 5 não passou por esse caminho. Em vez disso, o governo recorreu a controles de exportação, uma ferramenta tradicionalmente usada para restringir acesso a tecnologias sensíveis. O episódio mostra que, quando Washington precisa agir rapidamente sobre um modelo de fronteira, ainda não há um processo obrigatório e bem definido, apenas respostas improvisadas.

O Notepad, conhecido no Brasil como Bloco de Notas, sempre foi um dos símbolos da simplicidade no Windows. Mas, para Dave Plummer, ex-engenheiro da Microsoft e autor do Gerenciador de Tarefas, a versão atual do editor de texto reflete um problema maior: a tendência de adicionar recursos demais a ferramentas que nasceram para executar tarefas básicas. Plummer afirma que, em sua época na Microsoft, havia uma divisão clara de papéis. O Notepad era voltado exclusivamente para texto puro, enquanto o WordPad ficava responsável por documentos em RTF, fontes mais elaboradas e funções adicionais. Essa separação, segundo ele, ajudava a manter o editor leve, direto e previsível para o usuário. Décadas depois, o cenário mudou. O WordPad foi descontinuado, e o Notepad passou a receber novas funções, incluindo recursos alimentados por Copilot para sugerir ajustes em textos. Para Plummer, essa evolução representa uma perda de foco. Em resposta, ele decidiu reconstruir o editor do zero, criando uma versão extremamente enxuta, sem telemetria e sem recursos considerados desnecessários. O resultado é o TinyRetroPad, um fork do Dave’s Tiny Editor, conhecido como DTE, criado por Matt Power. O projeto foi escrito em assembly e utiliza o componente RICHEDIT50W da WinAPI, aproveitando elementos já presentes no próprio Windows em vez de recriar funcionalidades do sistema. Essa abordagem permitiu reduzir drasticamente o tamanho do executável. Segundo Plummer, o TinyRetroPad tem apenas 2.686 bytes. Em testes mencionados pelo The Register, a compilação chegou a 2.794 bytes, ocupando 4.096 bytes em disco por causa do tamanho mínimo de cluster do sistema de arquivos. Ainda assim, trata-se de um tamanho muito inferior ao do Notepad.exe atual, descrito como mais de 100 vezes maior que o executável criado pelo ex-engenheiro. Apesar do tamanho reduzido, o TinyRetroPad não é apenas uma janela vazia para digitação. O aplicativo conta com diálogos de abertura e salvamento de arquivos, seleção de fonte e até suporte a impressão. A diferença é que essas funções dependem fortemente de componentes nativos do Windows, o que reduz o volume de código próprio necessário para entregar a experiência. Plummer brincou que o sistema de impressão do Windows é “meio assustador”, comparando-o a abrir uma escotilha no chão e descobrir um segundo sistema operacional por baixo. A observação reforça a complexidade acumulada em certas partes do Windows, mesmo quando a aplicação em si tenta permanecer mínima. Visualmente, o TinyRetroPad foi criado para lembrar o Notepad da época do Windows XP. A proposta não é competir com editores modernos cheios de recursos, mas demonstrar que uma ferramenta simples de texto ainda pode ser construída de forma extremamente leve quando se apoia em componentes já disponíveis no sistema operacional. A crítica de Plummer vai além do Bloco de Notas. Para ele, o Notepad funciona como um exemplo simbólico de como softwares simples podem se tornar inflados ao longo do tempo. A inclusão de novas funções, integrações e camadas adicionais pode aumentar o tamanho do código e a complexidade de manutenção sem necessariamente entregar uma melhoria proporcional para todos os usuários. O caso também reacende uma discussão antiga no desenvolvimento de software: até que ponto adicionar funcionalidades torna um produto melhor? No caso de ferramentas básicas, como editores de texto, calculadoras ou utilitários de sistema, muitos usuários valorizam previsibilidade, velocidade e baixo consumo de recursos mais do que integrações avançadas. Embora existam diversas alternativas ao Notepad, poucas seguem uma abordagem tão radicalmente minimalista quanto o TinyRetroPad. O projeto mostra que, em determinadas situações, manter o código enxuto ainda pode ser uma escolha técnica relevante, especialmente em um contexto no qual sistemas operacionais e aplicativos acumulam dependências, recursos e camadas de abstração. Mesmo que a versão atual do Notepad ofereça funções úteis para parte dos usuários, o experimento de Plummer aponta para uma tensão recorrente na indústria de software: a busca por inovação pode transformar ferramentas simples em produtos mais pesados do que deveriam ser. O TinyRetroPad, com seus poucos kilobytes, funciona como uma provocação técnica e nostálgica sobre o valor da simplicidade no Windows.

A implantação de autenticação multifator em ambientes corporativos costuma ser tratada como uma das medidas básicas para reduzir o risco de comprometimento de contas. Ainda assim, um caso relatado à coluna On Call, do The Register, mostra como decisões internas e pressão operacional podem levar empresas a recuar justamente em controles de segurança considerados essenciais. O relato foi enviado por um leitor identificado pelo pseudônimo “Colin”, que trabalhava em um projeto para um cliente interessado em melhorar a segurança de sua implementação do Microsoft 365. O objetivo era elevar o Secure Score, métrica usada pela Microsoft para avaliar a postura de segurança e resiliência de ambientes Microsoft 365. Segundo Colin, a equipe passou um período considerável alinhando com o cliente um plano de implantação para habilitar MFA em toda a organização, seguindo uma linha de base de segurança previamente acordada. A autenticação multifator adiciona uma etapa extra de verificação além da senha, como aplicativo autenticador, token, biometria ou confirmação em dispositivo confiável, reduzindo o impacto de credenciais roubadas ou reutilizadas. A implementação começou de forma tranquila. A equipe técnica ativou as melhorias planejadas, e o processo parecia seguir sem incidentes relevantes. O problema surgiu na manhã seguinte, quando uma diretora sênior da empresa entrou em contato com o service desk em tom de forte reclamação. De acordo com o relato, a executiva, descrita como suposta COO de uma empresa de cibersegurança, acusou a equipe de ter paralisado a organização ao exigir o registro dos usuários no MFA. A reclamação indicava que o processo teria afetado um sistema de faturamento e poderia gerar impacto grave nos negócios em um curto período. Após a equipe conseguir entender o problema em meio às acusações, ficou claro que a falha afetava apenas três ou quatro telefones. A investigação apontou que o problema não estava na implantação do Microsoft 365 nem no MFA em si, mas no software de faturamento usado pela empresa. O sistema prometia suporte à autenticação multifator, mas dependia de uma implementação defeituosa para operar corretamente. Em outras palavras, o controle de segurança planejado funcionava no ambiente Microsoft, enquanto a interrupção estava associada à baixa qualidade ou instabilidade do software de terceiros integrado ao processo. Mesmo com essa explicação, a diretora não aceitou aguardar uma solução alternativa. A ordem foi realizar um rollback imediato, removendo a exigência de MFA. Segundo o relato, essa reversão continuava em vigor, deixando a empresa com uma postura de segurança inferior à planejada originalmente. Para Colin, o aspecto mais surpreendente foi a resistência de uma liderança supostamente ligada ao setor de segurança em manter uma medida básica de proteção. Na prática, a decisão priorizou a eliminação imediata do atrito operacional, mesmo que isso significasse deixar contas corporativas menos protegidas. O caso ilustra um dilema comum em projetos de segurança: controles técnicos podem ser bem planejados e executados, mas ainda assim enfrentar resistência quando sistemas legados, aplicações de terceiros ou processos internos não acompanham o mesmo nível de maturidade. Quando a pressão por continuidade operacional é tratada sem análise adequada, o resultado pode ser a remoção de mecanismos importantes de proteção. A autenticação multifator é especialmente relevante em ambientes Microsoft 365 porque credenciais de e-mail e colaboração corporativa continuam sendo alvos frequentes de phishing, ataques de força bruta, credential stuffing e campanhas de roubo de sessão. Sem MFA, uma senha comprometida pode ser suficiente para dar acesso a e-mails, arquivos, calendários, chats e aplicações integradas. Ao mesmo tempo, a implantação de MFA exige planejamento operacional. Organizações precisam mapear sistemas dependentes, fluxos de autenticação, dispositivos móveis, usuários privilegiados, contas de serviço, aplicativos legados e exceções temporárias. Quando aplicações críticas afirmam oferecer suporte a MFA, esse suporte deve ser validado antes da ativação ampla, preferencialmente em piloto controlado. O relato também mostra a importância de comunicação executiva em projetos de segurança. A implantação de controles como MFA deve ser acompanhada de mensagens claras sobre impacto esperado, benefícios, etapas de suporte, exceções documentadas e critérios para rollback. Sem esse alinhamento, incidentes pontuais podem ser interpretados como falha generalizada do projeto. Segundo Colin, o mesmo cliente já havia feito outras solicitações consideradas sem sentido, incluindo exigir que um engenheiro que não dirigia fosse imediatamente a um local remoto para corrigir uma impressora. Em outra ocasião, a mesma pessoa teria atribuído a um trabalho feito no Microsoft 365 a causa de uma queda de energia. Embora o caso tenha sido apresentado em tom leve pela coluna do The Register, ele aponta para um problema real em muitas organizações: a segurança pode ser enfraquecida não por falta de tecnologia, mas por decisões apressadas, baixa maturidade de governança e dificuldade de lidar com exceções operacionais. A principal lição é que MFA não deve ser tratado como um recurso opcional a ser removido ao primeiro atrito. Quando uma aplicação falha ao lidar com autenticação multifator, a resposta adequada é identificar a causa, aplicar contornos temporários bem documentados e corrigir a integração, não abandonar o controle em toda a organização. Em ambientes corporativos, especialmente aqueles que dependem de Microsoft 365, o equilíbrio entre segurança e operação exige processos de mudança bem definidos. A ausência de MFA pode parecer uma solução rápida para um problema imediato, mas aumenta a exposição a ataques de conta, comprometimento de e-mail corporativo e acesso indevido a dados sensíveis.

O desenvolvedor Python Roman Imankulov quase caiu em uma armadilha disfarçada de oportunidade de trabalho. O ataque, conduzido por uma pessoa que se apresentou como recrutadora de uma pequena startup de criptomoedas, usava um repositório aparentemente problemático como pretexto para induzir a execução de código malicioso durante uma avaliação técnica. O contato ocorreu pelo LinkedIn. A suposta recrutadora afirmou que a empresa precisava de um lead engineer e pediu ajuda para analisar um código de prova de conceito que não funcionava. Segundo ela, o problema estaria relacionado a um módulo Node depreciado. A abordagem parecia plausível, mas algo no pedido chamou a atenção de Imankulov. Em entrevista por telefone, o desenvolvedor afirmou que já havia ouvido falar desse tipo de ataque e, por experiência anterior, levantou a hipótese de que ele próprio poderia ser o alvo. Em vez de clonar e executar o projeto diretamente em sua máquina, ele adotou uma postura mais cautelosa: criou uma VPS na Hetzner, clonou o repositório nesse ambiente isolado e usou seu agente de codificação Pi, executando Codex, para realizar uma análise somente leitura do código. A expectativa inicial era que a ferramenta apenas apontasse baixa qualidade no código e autorizasse uma revisão convencional. O resultado foi diferente. Segundo Imankulov, o agente respondeu quase imediatamente com um alerta para não executar o projeto, indicando que havia uma armadilha no repositório. A análise com IA apontou o arquivo app/test/index.js como suspeito. O conteúdo escondia uma backdoor por meio de uma URL de servidor fragmentada para parecer parte de uma configuração de suíte de testes. O script incluía uma requisição de rede capaz de executar qualquer código enviado pelo servidor em resposta. Imankulov afirmou que havia aberto o arquivo manualmente e, ao passar os olhos pelo conteúdo, interpretou o código como apenas mal escrito. Para ele, parecia um arquivo típico de um desenvolvedor descuidado, não uma ameaça evidente. O agente de IA, no entanto, identificou no mesmo arquivo a vulnerabilidade que ele havia deixado passar. O ataque não exigia que a vítima executasse manualmente um binário suspeito. Bastaria instalar o projeto usando npm. O arquivo package.json do repositório continha um hook “prepare”, executado após a instalação, projetado para rodar o script malicioso durante o processo de instalação das dependências. Esse detalhe torna o ataque especialmente perigoso para desenvolvedores. O comando npm install faz parte da rotina de trabalho em projetos JavaScript e Node.js, e muitos profissionais o executam automaticamente ao avaliar um repositório. Ao esconder a execução dentro de um hook de ciclo de vida do npm, os invasores transformam um fluxo legítimo de desenvolvimento em vetor de comprometimento. A arquiteta independente de open source e segurança Devashri Datta explicou ao The Register que a abordagem é insidiosa justamente por sequestrar workflows comuns de desenvolvimento. O adversário não depende de um arquivo executável claramente suspeito. Ele se apoia em um comando rotineiro e confiável, executado durante a resolução de dependências. Segundo Datta, a fragmentação da string usada para montar a URL maliciosa também foi deliberada. Em vez de deixar um domínio suspeito escrito de forma direta no código, os operadores dividiram a informação em pequenas constantes, dificultando a detecção por ferramentas de análise estática que procuram indicadores de comprometimento hardcoded. O repositório malicioso original não está mais acessível, provavelmente removido pelo GitHub após a denúncia de Imankulov, embora uma cópia ainda tenha sido encontrada. A investigação também mostrou outro elemento comum em ataques de engenharia social contra desenvolvedores: a aparência de legitimidade. Os commits no repositório pareciam ter sido feitos por um desenvolvedor com presença pública estabelecida e histórico real de trabalho. Quando Imankulov entrou em contato com o suposto autor, ele afirmou que já havia sido impersonado no GitHub mais de uma vez e que não havia escrito aquele código. A identidade da recrutadora também levantou sinais de falsificação. O perfil no LinkedIn fazia referência a uma jornalista de artes real, mas Imankulov acredita que a conta associada era falsa. As interações com a suposta recrutadora indicavam um nível de conhecimento técnico que não aparecia no histórico profissional exibido no perfil. O caso ocorre em um cenário no qual contas falsas em plataformas profissionais continuam sendo usadas para golpes. Embora o LinkedIn afirme remover dezenas de milhões de contas falsas antes que elas interajam com usuários, centenas de milhares ainda conseguem ser criadas e entrar em contato com pessoas antes de serem detectadas. Entre janeiro e junho de 2025, a plataforma restringiu 386 mil contas após denúncias de usuários, acima das 266 mil no semestre anterior e das 86 mil registradas no primeiro semestre de 2021. Ataques de engenharia social contra a cadeia de suprimentos de software se tornaram cada vez mais comuns. Campanhas recentes associadas à Coreia do Norte, por exemplo, têm usado entrevistas falsas e ofertas de emprego para comprometer contas de desenvolvedores, roubar credenciais e obter acesso a ambientes internos. Outros desenvolvedores também relataram quase ter caído em golpes semelhantes, em alguns casos igualmente salvos por agentes de IA usados para revisar o código antes da execução. Para Datta, a resposta de Imankulov aponta uma mudança importante na higiene de revisão de código entre profissionais mais atentos à segurança. Historicamente, a recomendação era revisar manualmente código não confiável ou executá-lo em sandbox. Neste caso, o desenvolvedor usou um agente local de IA em um ambiente restrito e somente leitura para analisar a base de código antes de executar qualquer comando. A IA, nesse contexto, atuou como uma camada defensiva no endpoint do desenvolvedor, capaz de identificar rapidamente comportamentos anômalos, como uma suíte de testes fazendo conexão externa para buscar código não verificado. O incidente também mostra por que a segurança da cadeia de suprimentos de software precisa considerar o ambiente local dos engenheiros. Uma estação de trabalho de desenvolvedor pode conter chaves SSH ativas, tokens de provedores cloud, sessões autenticadas e acesso a repositórios internos. Se esse dispositivo for comprometido durante uma falsa entrevista técnica, o impacto pode ir além do usuário individual e atingir a organização. Uma mudança relevante pode reduzir esse vetor no ecossistema npm. O GitHub, mantenedor do npm, prepara o lançamento do npm 12, que altera o comportamento do comando npm install. A configuração allowScripts passará a vir desativada por padrão, impedindo que scripts preinstall, install ou postinstall de dependências sejam executados automaticamente, a menos que sejam explicitamente autorizados no projeto. Segundo Leo Balter, gerente de produto do GitHub, scripts de ciclo de vida executados durante a instalação representam a maior superfície de execução de código no ecossistema npm. Como cada npm install pode rodar scripts de dependências transitivas, um único pacote comprometido em qualquer ponto da árvore de dependências pode executar código arbitrário em uma máquina de desenvolvimento ou runner de CI. Para Imankulov, a mudança é bem-vinda, mas ele já adotou uma medida prática por segurança pessoal: passou a usar pnpm para garantir que scripts desse tipo não sejam executados por padrão. A decisão reflete uma postura crescente entre desenvolvedores que lidam com código de terceiros ou projetos recebidos em contextos de baixa confiança. Datta defende que empresas devem ir além de orientações genéricas e aplicar barreiras técnicas. Entre as medidas estão o uso de contêineres isolados para desenvolvimento, workstations seguras em nuvem e ambientes descartáveis para avaliar código externo ou não confiável. Essas práticas reduzem o risco de que uma avaliação técnica, uma prova de conceito ou um processo seletivo se transforme em ponto de entrada para credenciais corporativas. O caso reforça uma mudança no alvo dos ataques à cadeia de suprimentos. Em vez de esperar que um pacote malicioso chegue a um repositório corporativo, invasores estão tentando comprometer desenvolvedores antes mesmo que uma linha de código entre no pipeline da empresa. A ameaça começa no endpoint individual, no momento em que o profissional clona um repositório, instala dependências e confia em fluxos automatizados do próprio ecossistema de desenvolvimento.

Durante o período, maior pressão sobre a segurança a riscos digitais impulsiona ações de monitoramento e reforço operacional por parte das organizações O megaevento global passou a representar um período de maior atenção para a segurança digital, diante de movimentações maliciosas que exploram momentos de distração e grande volume de acessos. Em meio a transmissões online, apostas esportivas, pagamentos instantâneos e milhões de usuários conectados simultaneamente, organizações de diversos setores ampliam monitoramento, revisam planos de resposta e reforçam operações para reduzir riscos durante o campeonato. De acordo com a Delfia, curadoria de jornadas digitais, eventos de grande audiência funcionam como uma espécie de “cortina de fumaça” para ataques digitais. Enquanto empresas concentram esforços em garantir disponibilidade, performance e estabilidade de seus ambientes durante as partidas, criminosos aproveitam o aumento do tráfego, da distração e da pressão operacional para executar fraudes, golpes e movimentações maliciosas que podem passar despercebidas. “O ambiente fica mais barulhento. Há mais acessos, mais consumo digital, mais alertas e mais pressão sobre os times. E é justamente nesse cenário que muitos ataques conseguem operar abaixo do radar”, afirma Leonardo Santos, CTO da Delfia. Em um momento no qual a economia digital ligada ao futebol cresce, plataformas de apostas, aplicativos financeiros, transmissões via streaming, carteiras digitais e transações de Pix devem registrar picos de acesso durante o campeonato, ampliando o risco operacional e a superfície de ataque das empresas. Golpes personalizados por IA Além do aumento da exposição digital, a inteligência artificial sofisticou o nível dos ataques associados a grandes eventos. Golpes utilizando promoções falsas, transmissões piratas, QR Codes fraudulentos, páginas clonadas, apostas esportivas e uso indevido de marcas de patrocinadores tendem a crescer durante o período da Copa, agora impulsionados por IA para personalização em escala. “A IA aumenta velocidade e capacidade de automação dos ataques. Hoje é possível criar campanhas de phishing muito mais convincentes, páginas falsas mais realistas e abordagens extremamente contextualizadas ao comportamento do usuário”, explica Leonardo Santos, da Delfia. Para ele, o problema não está apenas na tecnologia utilizada pelos criminosos, mas no comportamento das pessoas nesse período. “Durante a Copa, o usuário está mais emocional, mais distraído e mais propenso a clicar sem verificar. O risco aumenta porque existe uma combinação de empolgação, urgência e excesso de informação circulando ao mesmo tempo”, destaca. Esse cenário também impacta as operações corporativas. “Em momentos de muita atenção por exemplo, durante um gol ou uma jogada decisiva, um alerta importante pode deixar de ser analisado imediatamente. Às vezes, alguns minutos fazem diferença entre conter uma ameaça rapidamente ou permitir que ela avance dentro do ambiente”, salienta Leonardo Santos da Delfia. Empresas criam operações especiais Para reduzir riscos durante o campeonato, organizações de setores mais expostos vêm reforçando operações de monitoramento e resposta rápida a incidentes. Leonardo explica que é comum a criação de operações preventivas de “war rooms” em empresas com maior maturidade digital, que são as estruturas que integram times de segurança, infraestrutura, redes, aplicações, fornecedores, integradores, fabricantes e parceiros estratégicos para reduzir tempo de resposta em caso de incidentes ou de algum comportamento estranho. “Não é apenas uma questão de tecnologia e o principal ganho é que a atuação deixa de ser apenas reativa. Esses ambientes funcionam para garantir coordenação rápida entre diferentes áreas caso ocorra qualquer comportamento suspeito ou instabilidade operacional”, ressalta o CTO da Delfia. Leonardo também destaca que empresas de apostas esportivas, bancos, fintechs, meios de pagamento, call centers, patrocinadores e plataformas de transmissão estão entre os segmentos mais expostos durante o período da Copa. “As BETs, por exemplo, devem sofrer enorme pressão durante os jogos, principalmente em pagamentos, autenticação e volume de acessos. Já empresas de transmissão lidam com risco reputacional imediato caso exista qualquer indisponibilidade durante partidas importantes”, acrescenta. “Patrocinadores também ficam expostos porque a marca pode ser usada como isca em golpe, promoção falsa, página fraudulenta e em campanhas maliciosas contextualizadas. Às vezes, o risco não está só na infraestrutura da empresa, mas no uso indevido da marca contra o consumidor”. O erro mais comum: olhar apenas para disponibilidade De acordo com a Delfia, um dos principais erros das empresas em períodos de alta exposição é concentrar toda a atenção apenas em estabilidade e performance, sem observar movimentações que "voam" por baixo do radar, como fraude, abuso de credenciais ou exploração de vulnerabilidades. “Muitas organizações entram nesses eventos olhando apenas para indisponibilidade e DDoS. Mas, enquanto isso, outros ataques podem acontecer de forma mais discreta, aproveitando exatamente o momento de distração operacional”, reforça Santos. Ainda, uma questão levantada pelo CTO da Delfia é montar uma operação de “war room” focada em algo específico e deixar de ver o todo. “No fim, o erro não é só técnico. É operacional. Não basta ter ferramenta ou sala de guerra. Precisa ter escala, cobertura e visão ampla para tomar boas decisões”. Outro desafio é a própria exaustão das equipes de tecnologia e segurança em operações que exigem monitoramento contínuo durante jogos e horários críticos. “A segurança depende também de processo, coordenação, cobertura e capacidade de resposta rápida. Grandes eventos amplificam riscos que muitas vezes já existem no ambiente”, avalia Santos. Mais vulnerável X mais consciência dos riscos Na avaliação da Delfia, apesar do aumento da conscientização sobre segurança digital nos últimos anos, empresas e usuários ainda ficam mais vulneráveis durante grandes eventos como a Copa do Mundo. Para reduzir riscos durante esses períodos, a recomendação do especialista é reforçar monitoramento, revisar planos de resposta e validar previamente a capacidade dos ambientes digitais. Segundo o executivo, empresas mais preparadas costumam ajustar limiares de monitoramento, revisar fluxos críticos, validar fornecedores e acompanhar movimentações de ameaças observadas em outros países e setores, utilizando essas informações como alerta antecipado. Além disso, a Delfia reforça que a preparação precisa considerar múltiplas camadas de proteção, envolvendo mitigação global e local, firewalls, WAF, SOC, proteção de identidade, endpoints e resposta coordenada entre equipes e parceiros. “Grandes eventos não criam riscos do zero, mas ampliam vulnerabilidades que muitas vezes já existem. Nesse contexto, segurança não significa apenas bloquear ataques, mas garantir continuidade operacional, experiência do usuário, reputação e capacidade de resposta rápida”, conclui Leonardo Santos, da Delfia.