Por - Ney López Se você trabalha com segurança em nuvem, tenho uma boa e uma má notícia sobre a ameaça quântica. A boa: parte da sua migração pós-quântica já aconteceu, e você provavelmente nem percebeu. Os grandes provedores e navegadores já ligaram troca de chaves híbrida por padrão. Seu tráfego até a borda da nuvem, em muitos casos, já está protegido contra "harvest now, decrypt later". De graça. Sem você abrir um chamado. A má notícia é exatamente essa. Porque isso cria a ilusão mais perigosa que existe em segurança: a sensação de que o problema foi resolvido por outra pessoa. O que o provedor resolveu foi o trecho mais visível, e o mais fácil. O que ele não resolveu continua com o seu nome: → Comunicação interna entre serviços. mTLS entre microsserviços, service mesh, filas, bancos. Tudo isso é criptografia que VOCÊ configurou. → Dados em repouso com validade longa. Backup, data lake, prontuário, contrato. Se precisa continuar secreto em 2040, o relógio já está correndo. → Sua PKI e assinatura de código. Certificados internos, pipelines de CI/CD, imagens assinadas. Migração de assinatura é mais lenta e mais dolorida que a de cifra. → Sua cadeia de fornecedores. Aquele SaaS que processa seu dado sensível, ele tem plano de migração? Alguém já perguntou? E aqui está a pergunta que eu levaria para a próxima reunião de arquitetura, no lugar de "qual algoritmo vamos usar": Quais dos meus dados têm prazo de validade maior do que o relógio quântico, e onde exatamente eles são cifrados hoje? Quem não consegue responder isso não tem um problema de criptografia. Tem um problema de inventário. E inventário não se resolve em 2029, às pressas. A nuvem te deu uma vantagem de largada. Ela não te deu o mapa. Se eu pedisse hoje o inventário criptográfico da sua organização, em quanto tempo ele chegaria? Comenta aí, desconfio que a resposta honesta assusta mais que computador quântico.

Pesquisadores da Bitsight identificaram uma operação que utiliza TV Boxes Android de baixo custo para fraudar publicidade online e transformar a conexão de internet dos proprietários em nós de uma rede de proxies. Os dispositivos alteram sua identidade para se passarem por smartphones de fabricantes como Samsung, Huawei, Xiaomi e Vivo. A campanha foi batizada de Fuyao e é atribuída pela Bitsight à empresa chinesa Zhejiang Fengwo IoT Technology Co., Ltd., fundada em 2019. A atribuição se baseia em evidências como certificados TLS compartilhados, endereços de e-mail reutilizados, infraestrutura comum, registros de receita e patentes relacionadas. Até o momento, não há confirmação independente dessa atribuição. A investigação começou após os pesquisadores registrarem um domínio expirado utilizado como backdoor de fábrica e coletor de telemetria dos dispositivos. A maioria dos equipamentos identificados reportava o modelo H96_MAX_V11, embora a Bitsight ressalte que a amostra analisada estava concentrada em modelos mais antigos de uma única marca e não representa uma lista completa dos aparelhos afetados. Em apenas um dia de monitoramento, o sinkhole criado pelos pesquisadores recebeu 65.957 comunicações provenientes de aproximadamente 38 mil endereços MAC únicos contendo os aplicativos associados à operação. Como os dispositivos alteram seus identificadores durante o funcionamento, esse número não representa necessariamente a quantidade real de equipamentos comprometidos. Segundo a análise, os aplicativos embarcados executam duas funções principais. A primeira consiste em modificar diversas características do hardware para que a TV Box seja reconhecida por servidores como um smartphone Android legítimo. O servidor de comando e controle envia perfis completos de telefones para cada equipamento, ocultando informações que revelariam o uso de plataformas Rockchip, Amlogic ou Allwinner, comuns em TV Boxes de baixo custo. Disfarçados como celulares, os dispositivos recebem tarefas para visitar páginas controladas pelos próprios operadores e clicar automaticamente em anúncios publicitários, gerando receita fraudulenta. Quando detectam que estão conectados a uma televisão por meio da porta HDMI, normalmente deixam de executar fraudes publicitárias e passam a atuar como servidores SOCKS5, encaminhando tráfego de terceiros pela conexão residencial do proprietário. Quando a TV é desligada, retornam ao modo de fraude de anúncios. Para localizar automaticamente banners e áreas clicáveis, a operação utiliza um modelo de visão computacional baseado no YOLOv8s, combinado com recursos de acessibilidade do Android e reconhecimento óptico de caracteres (OCR) do Google ML Kit. Segundo Pedro Falé, pesquisador da Bitsight, a campanha combina diferentes mecanismos de visão computacional e interpretação da interface para automatizar os cliques nos anúncios. A lógica de cada campanha é criada em uma plataforma própria baseada no Blockly, framework de programação visual do Google. Os fluxos são exportados em JavaScript, armazenados na Amazon S3 e enviados remotamente para execução nos dispositivos comprometidos. Nos testes realizados em quatro TV Boxes, os pesquisadores observaram cerca de 40 tarefas de fraude, distribuídas em 21 campanhas diferentes e compostas por 166 módulos distintos. Um comentário recuperado do código indica que o sistema de modelos permitia que poucos engenheiros experientes desenvolvessem campanhas utilizadas por operadores menos especializados. A Bitsight também mapeou a infraestrutura financeira da operação, identificando 144 domínios distribuídos em sete grupos responsáveis pela monetização. Pelo menos 84 deles carregavam scripts da plataforma Taboola em suas páginas iniciais. Com base nos dados públicos do arquivo sellers.json da Taboola, os pesquisadores associaram esses domínios a entidades responsáveis pela arrecadação de receitas localizadas em Hong Kong e Singapura. A empresa estima que cada dispositivo ativo possa gerar cerca de US$ 1,25 por dia, o que representaria aproximadamente US$ 47,5 mil diários considerando uma base de 38 mil dispositivos ativos. Em outro cenário, utilizando números divulgados pela própria Fengwo sobre uma frota superior a 120 mil dispositivos, a Bitsight estima um faturamento anual de até US$ 40 milhões. A empresa destaca que esses valores são projeções e não receitas efetivamente comprovadas. Os pesquisadores ressaltam que ainda não foi possível determinar quem instalou os aplicativos maliciosos nem em qual etapa da cadeia de fabricação ou distribuição eles passaram a fazer parte dos dispositivos. Até o momento da divulgação do relatório, também não havia uma lista completa dos pacotes afetados, versões de firmware vulneráveis ou indicadores de comprometimento específicos, dificultando a identificação dos equipamentos comprometidos. Em resposta ao caso, o Google afirmou que os dispositivos analisados não eram equipamentos Android TV certificados pelo programa Play Protect. Segundo a empresa, aparelhos certificados passam por testes de segurança e compatibilidade antes de serem comercializados. O Google recomenda que consumidores consultem a lista oficial de parceiros Android TV e verifiquem nas configurações do equipamento se ele possui certificação Play Protect. O caso reforça um alerta emitido pelo FBI em junho de 2025, que orienta consumidores a avaliar cuidadosamente dispositivos conectados à rede doméstica, manter o firmware atualizado e desconfiar de TV Boxes genéricas vendidas com promessas de acesso gratuito a conteúdo pago.

O Google corrigiu 1.442 vulnerabilidades nas três versões mais recentes do Chrome, um volume superior ao total de falhas corrigidas nas 23 versões anteriores do navegador. Segundo a empresa, o aumento reflete o crescimento acelerado na descoberta de vulnerabilidades, impulsionado pelo uso de modelos de inteligência artificial. As versões Chrome 149 e 150, lançadas em julho, corrigiram 1.072 falhas de segurança. Já a atualização Chrome 151, disponibilizada na quarta-feira, solucionou outras 370 vulnerabilidades, sendo 349 identificadas internamente pelo Google. Sete delas foram classificadas como críticas. De acordo com a empresa, ferramentas baseadas em grandes modelos de linguagem (LLMs) estão acelerando significativamente a identificação de falhas, fazendo com que novas vulnerabilidades sejam descobertas em um ritmo maior do que o tempo necessário para corrigi-las. Os números acompanham uma tendência observada em todo o setor. Dados do National Vulnerability Database (NVD) dos Estados Unidos mostram que 46.872 vulnerabilidades já foram registradas em 2026, aproximando-se das 49.920 catalogadas durante todo o ano de 2025. Um dos casos destacados pelo Google é a CVE-2026-3545, uma vulnerabilidade crítica (CVSS 9,6) no componente de navegação do Chrome que permitia escapar da sandbox do navegador e acessar arquivos locais do sistema. A falha foi corrigida em março. Segundo o Google, o problema permaneceu oculto no código-fonte por mais de 13 anos e foi descoberto por um sistema automatizado de análise baseado em modelos Gemini. Para reduzir o tempo entre a descoberta e a distribuição das correções, a empresa está alterando seu ciclo de desenvolvimento. O Chrome passa a adotar grandes lançamentos a cada duas semanas, atualizações semanais de segurança e um projeto piloto para publicar duas atualizações de segurança por semana, em resposta ao aumento de ataques impulsionados por inteligência artificial. O Google também informou que está automatizando a geração de notas de lançamento e descrições de CVEs diretamente a partir das correções implementadas, reduzindo etapas manuais e acelerando a divulgação pública das vulnerabilidades. Outra iniciativa em desenvolvimento é a aplicação dinâmica de correções, permitindo atualizar partes do navegador sem exigir o reinício completo da aplicação. A tecnologia utiliza a arquitetura multiprocessos do Chrome para substituir dinamicamente processos em segundo plano, como os responsáveis pela renderização das páginas e pelo processamento gráfico, carregando versões atualizadas enquanto o navegador continua em execução. No macOS, por exemplo, o Chrome 150 já passou a reiniciar automaticamente quando detecta uma atualização pendente enquanto permanece aberto em segundo plano, mesmo sem janelas visíveis. Além de acelerar a distribuição de patches, o Google também trabalha para eliminar categorias inteiras de vulnerabilidades. Entre as iniciativas estão o fortalecimento das proteções contra erros clássicos de memória, como use-after-free e acessos fora dos limites da memória, a adoção crescente da linguagem Rust, conhecida por seus mecanismos de segurança de memória, e a migração da interface principal do navegador para tecnologias web como HTML, CSS e TypeScript, reduzindo a dependência de componentes escritos em C++. A empresa também está automatizando as atualizações de todas as dependências de terceiros utilizadas pelo Chrome, diminuindo o risco de exposição causado por bibliotecas desatualizadas. Segundo a equipe de segurança do Chrome, corrigir vulnerabilidades continua sendo fundamental, mas a velocidade com que as atualizações chegam aos usuários tornou-se igualmente importante para impedir que invasores explorem falhas antes da instalação dos patches.

Pesquisadores da Microsoft identificaram uma campanha que compromete redes Wi-Fi de hotéis para distribuir falsas atualizações de navegador e sistema operacional, utilizadas para instalar o malware CornFlake. O código malicioso é capaz de capturar imagens da webcam, gravar áudio do microfone, registrar teclas digitadas e roubar credenciais. A operação foi batizada de CaptiveCrunch e é atribuída pela Microsoft ao grupo Storm-2945, considerado um subgrupo operacional do Midnight Blizzard, também conhecido como APT29 ou Cozy Bear. Os governos dos Estados Unidos e do Reino Unido atribuem o APT29 ao Serviço de Inteligência Estrangeira da Rússia (SVR). A ligação entre o CaptiveCrunch e o Storm-2945, no entanto, é uma avaliação da Microsoft e ainda não foi corroborada de forma independente. Segundo a investigação, os invasores obtiveram controle do gateway responsável pelo portal cativo de redes Wi-Fi em hotéis. Nos ambientes analisados pela ReliaQuest, esse equipamento também funcionava como servidor DNS dos dispositivos conectados. Com acesso administrativo ao gateway, os criminosos conseguiam falsificar respostas DNS e redirecionar verificações automáticas de conectividade realizadas pelos sistemas operacionais para páginas falsas que simulavam atualizações de navegadores ou do próprio sistema. Em alguns casos, as páginas utilizavam a técnica conhecida como ClickFix, na qual a vítima é instruída a abrir o Prompt de Comando, PowerShell ou outro utilitário do Windows e executar comandos fornecidos pelos invasores. A infecção não ocorre automaticamente: o usuário ainda precisa baixar ou executar o conteúdo malicioso. A Microsoft afirma observar esse tipo de manipulação de tráfego desde o início de maio em redes de hospitalidade localizadas em diversos países, mas não revelou quais hotéis, fornecedores de portais cativos ou estabelecimentos foram afetados. Desde 16 de julho, parte da campanha passou a redirecionar usuários para o fluxo legítimo de autenticação por código de dispositivo da Microsoft. Ao inserir um código fornecido pelos invasores na página oficial de login, a vítima pode conceder acesso à sessão controlada pelos criminosos, inclusive com autenticação multifator (MFA) já validada. A Microsoft recomenda bloquear esse método de autenticação por meio das políticas de Acesso Condicional sempre que ele não for necessário. Após a instalação, o CornFlake copia a si próprio para o diretório %APPDATA%\svchost32\svchost32.exe, registra um serviço chamado Cloud Sync Service e exibe uma falsa janela de progresso para distrair a vítima durante a infecção. Segundo a análise da Microsoft, o malware pode capturar capturas de tela quando o computador está ocioso, registrar o conteúdo da área de transferência juntamente com o título da janela ativa, roubar cookies e senhas salvas em navegadores — incluindo cookies protegidos pelo Chrome App-Bound Encryption —, analisar dispositivos removíveis e abrir um shell remoto para controle do sistema. O malware também cria mecanismos de persistência por meio de uma chave Run no Registro do Windows e de uma tarefa agendada. Um componente adicional monitora esses mecanismos e os recria automaticamente caso sejam removidos por ferramentas de segurança. Os pesquisadores também identificaram outro malware utilizado na campanha, chamado ChocoShell, um ladrão de credenciais baseado em PowerShell executado apenas em memória. Ele coleta tokens de acesso e atualização do Microsoft 365 e do Azure Active Directory, além de tokens do Windows Web Account Manager (WAM), armazenados no cache do Token Broker. Esses tokens podem permitir o reaproveitamento de sessões autenticadas sem depender dos cookies do navegador, ampliando o potencial de comprometimento das contas corporativas. Embora os relatórios confirmem o redirecionamento de tráfego e a distribuição de malware, não há informações públicas sobre quantos usuários foram efetivamente comprometidos. Também não foram divulgados números de dispositivos infectados, aprovações do fluxo de código de dispositivo ou contas comprometidas. A Microsoft observou que diferentes redes afetadas utilizavam equipamentos e sistemas de gerenciamento semelhantes, o que pode indicar comprometimento de serviços compartilhados no ecossistema de portais cativos, em vez de incidentes isolados em hotéis específicos. A ReliaQuest havia documentado infraestrutura semelhante oito dias antes da divulgação da Microsoft e apontou semelhanças nas técnicas empregadas com o grupo APT28 (Fancy Bear/Forest Blizzard). No entanto, a empresa evitou atribuir a campanha ao grupo russo por considerar que as evidências disponíveis se baseiam apenas na sobreposição de táticas, técnicas e procedimentos. O vetor inicial utilizado para comprometer os equipamentos continua sob investigação. A ReliaQuest avalia, com baixa a média confiança, que interfaces administrativas expostas na internet e credenciais fracas ou reutilizadas podem ter permitido o acesso inicial aos dispositivos. Para reduzir os riscos, pesquisadores recomendam que viajantes utilizem conexões privadas sempre que possível e mantenham uma VPN configurada para encaminhar todo o tráfego, incluindo consultas DNS, por servidores confiáveis. Também orientam a recusar atualizações de software, certificados, ferramentas de diagnóstico ou utilitários de segurança oferecidos por portais de autenticação de redes Wi-Fi públicas.

A Adobe lançou atualizações de segurança para corrigir uma vulnerabilidade de gravidade máxima no Adobe Campaign Classic, plataforma corporativa de automação de marketing. A falha pode permitir a execução de código arbitrário sem qualquer interação do usuário. Identificada como CVE-2026-48449, a vulnerabilidade recebeu pontuação 10,0 no sistema CVSS, o nível máximo da escala de severidade. O problema foi classificado como uma falha de autorização incorreta. Segundo o alerta da Adobe, a exploração pode permitir que um invasor execute código arbitrário no contexto do usuário atual, sem que a vítima precise abrir arquivos, clicar em links ou realizar outra ação. A atualização também corrige a CVE-2026-48448, vulnerabilidade de alta gravidade com pontuação CVSS 8,6. A falha é causada por uma injeção de SQL e pode permitir a leitura arbitrária de arquivos armazenados no sistema afetado. “Esta atualização corrige vulnerabilidades críticas que podem resultar em execução arbitrária de código e leitura arbitrária do sistema de arquivos”, informou a Adobe em seu comunicado de segurança. Até o momento, a empresa afirma não ter conhecimento de ataques explorando nenhuma das duas vulnerabilidades em ambientes reais. As falhas foram corrigidas no Adobe Campaign Classic v7, versão 7.4.3 build 9398, disponível para sistemas Windows e Linux. Organizações que utilizam versões anteriores devem aplicar a atualização, especialmente em instalações expostas à rede ou integradas a sistemas corporativos. Além das correções no Campaign Classic, a Adobe publicou atualizações para oito vulnerabilidades classificadas como críticas no Adobe Bridge. Os problemas podem resultar em elevação de privilégios ou execução arbitrária de código. A CVE-2026-48395, com pontuação CVSS 8,6, é uma vulnerabilidade de caminho de pesquisa não confiável que pode permitir a execução de código arbitrário. A CVE-2026-48396, também avaliada em 8,6, decorre de autorização incorreta e pode levar à execução de código no sistema. Já a CVE-2026-48390, com pontuação 8,6, é outra falha de autorização incorreta, mas seu impacto está relacionado à elevação de privilégios. A CVE-2026-48391 recebeu pontuação CVSS 8,2 e envolve um caminho de pesquisa não confiável que pode ser utilizado para executar código arbitrário. A CVE-2026-48374, classificada com pontuação 7,8, é uma vulnerabilidade de path traversal que também pode resultar em execução de código. As CVE-2026-48392, CVE-2026-48393 e CVE-2026-48394, todas com pontuação CVSS 7,8, são falhas de gravação fora dos limites da memória. Esse tipo de vulnerabilidade pode provocar corrupção de memória e permitir a execução de código arbitrário. A Adobe creditou o pesquisador de segurança Kieran, conhecido como “kaiksi”, pela descoberta e comunicação das CVE-2026-48390, CVE-2026-48391, CVE-2026-48395, CVE-2026-48396 e CVE-2026-48374. As outras três vulnerabilidades de gravação fora dos limites foram identificadas e relatadas pelo pesquisador conhecido como “yjdfy”. A recomendação é que administradores e usuários instalem as versões mais recentes do Adobe Campaign Classic e do Adobe Bridge para reduzir o risco de exploração das vulnerabilidades.

Uma falha na geração de chaves de carteiras de hardware Coldcard foi associada a uma série de transferências suspeitas que movimentaram 1.367,05 bitcoins, avaliados em cerca de US$ 88,6 milhões, a partir de 4.585 endereços. A vulnerabilidade afetava diferentes modelos do dispositivo, fabricado pela empresa canadense Coinkite. A primeira movimentação identificada ocorreu em 30 de julho, quando 1.196 endereços foram esvaziados em apenas 41 minutos. A operação transferiu 1.082,65 BTC, avaliados em aproximadamente US$ 70,2 milhões naquele momento. Posteriormente, a Galaxy Research identificou outras duas ondas possivelmente relacionadas à falha, elevando o total observado. A empresa afirmou que as duas primeiras ondas podem ter sido realizadas pelo mesmo operador devido às semelhanças nos padrões das transações, mas alertou que a terceira não deve ser automaticamente atribuída ao mesmo invasor. A Galaxy também ressaltou que as conclusões são baseadas em análise da blockchain. Até o momento, não houve confirmação computacional de que todos os endereços identificados tenham sido gerados por dispositivos Coldcard com entropia insuficiente. A origem do problema remonta a um erro de integração de firmware introduzido em março de 2021. Em vez de utilizar o gerador físico de números aleatórios do microcontrolador STM32, responsável por fornecer entropia para a criação das palavras-semente, o sistema encaminhava a operação para um gerador pseudoaleatório determinístico em software. Segundo a análise da Block, um atacante capaz de descobrir ou limitar suficientemente o identificador único do dispositivo, o estado dos temporizadores e o histórico anterior de chamadas ao gerador poderia reproduzir possíveis sequências de números aleatórios sem ter acesso físico à carteira. Os candidatos a seed poderiam então ser testados por meio da derivação dos respectivos endereços e da comparação com dados públicos da blockchain. Esse processo permitiria identificar carteiras reais e, posteriormente, tentar movimentar os fundos armazenados nelas. A falha estava relacionada à configuração de produção da Coldcard. O parâmetro MICROPY_HW_ENABLE_RNG era definido como zero porque a Coinkite utilizava sua própria implementação para acessar o gerador de números aleatórios do hardware. No entanto, a biblioteca libngu verificava apenas se o parâmetro existia, e não se estava ativado. Como consequência, o firmware era vinculado ao gerador alternativo Yasmarang, disponível no MicroPython. Esse mecanismo era inicializado com dados como o identificador exclusivo do chip e registradores de temporização, sem coletar nova entropia após a inicialização. Como os valores utilizados podiam ser parcialmente previsíveis, o espaço de possíveis seeds era consideravelmente menor do que o esperado. A Coinkite estima que a entropia efetiva era de aproximadamente 40 bits nos dispositivos Coldcard Mk3 e de cerca de 72 bits nos modelos Mk4, Mk5 e Q. Uma seed BIP-39 padrão com 12 palavras deveria oferecer até 128 bits de entropia. A Block, porém, não apresentou uma estimativa única sobre o custo prático do ataque. A análise define limites condicionais inferiores a 2^40,7 e 2^73,3 possibilidades, mas ressalta que o segundo número não equivale necessariamente a 73 bits reais de segurança criptográfica. Nenhum benchmark público de força bruta foi divulgado. Nos modelos mais recentes, um processo adicional de reinicialização do gerador aumenta o número de candidatos, mas a viabilidade do ataque depende de informações disponíveis sobre o identificador do dispositivo, o tempo de inicialização, chamadas anteriores ao gerador e o custo de derivação dos endereços. A exposição depende da versão do firmware utilizada no momento em que a seed foi criada, e não apenas da versão atualmente instalada no dispositivo. Nos modelos Mk2 e Mk3, a Coinkite lista as versões 4.0.1 a 4.1.9 do Mk3 como afetadas, com correção na versão 4.2.0. A empresa não menciona especificamente o Mk2, enquanto a Block considera que os modelos Mk2 e Mk3 com versões entre 4.0.0 e 4.1.9 seguiram o caminho vulnerável. Nos dispositivos Mk4 e Mk5, todas as versões anteriores à 5.6.0 são consideradas afetadas. No modelo Q, o problema está presente em versões anteriores à 1.5.0Q. Compilações experimentais ou de borda anteriores à versão 6.6.0X nos modelos Mk4 e Mk5 e anteriores à 6.6.0QX no Coldcard Q também estão incluídas na lista. A Coinkite distribuiu em 31 de julho atualizações emergenciais de firmware para todos os modelos e canais de lançamento afetados. A instalação do novo software, contudo, não corrige uma seed que já tenha sido gerada com entropia insuficiente. A recomendação para proprietários potencialmente expostos é criar uma nova seed em um dispositivo com firmware atualizado e transferir os bitcoins para os novos endereços. Restaurar a seed antiga em outro dispositivo ou em uma versão corrigida do firmware preserva a vulnerabilidade. A empresa afirma que seeds criadas com pelo menos 50 lançamentos de dados justos, independentes e realizados de forma privada não estão expostas exclusivamente por causa dessa falha. Quando não houver certeza sobre a quantidade, aleatoriedade ou privacidade dos lançamentos, a orientação é migrar os fundos. Uma passphrase BIP-39 forte e exclusiva cria uma carteira separada que não pode ser acessada apenas com as palavras da seed. Mesmo nesses casos, a Coinkite recomenda substituir a seed potencialmente vulnerável. Configurações multisig podem reduzir o risco apenas quando o número necessário de assinaturas não depende exclusivamente de dispositivos afetados. Produtos como TAPSIGNER, OPENDIME e SATSCARD utilizam bases de código diferentes e não foram impactados. Nenhum responsável pelas transferências foi identificado. Na primeira onda, a Galaxy observou que os endereços foram movimentados com uma taxa de 30 satoshis por byte virtual e sem endereços de troco, um padrão não encontrado em outras transações de Bitcoin analisadas nos 30 dias anteriores. A empresa advertiu, entretanto, que esse padrão identifica a operação, mas não comprova o furto. Uma transferência realizada pelo proprietário legítimo das moedas poderia apresentar características semelhantes. A atividade continuava em andamento durante a análise. A Galaxy informou ter enviado cerca de 600 endereços suspeitos de serem controlados pelos invasores a investigadores federais, empresas de compliance e especialistas em segurança cibernética. A divulgação ocorre poucas semanas após a pesquisa Ill Bloom, da Coinspect, detalhar outra vulnerabilidade de geração pseudoaleatória em carteiras de software antigas. Essa falha separada foi associada ao desvio de mais de US$ 5 milhões em endereços das redes Bitcoin, Ethereum, Tron, Rootstock e Polygon desde maio.

Apesar de a maioria das organizações já possuir planos de resposta a incidentes, ferramentas de segurança e equipes especializadas, 73% reconhecem que não estariam totalmente preparadas para lidar com um grande ataque cibernético caso ele ocorresse hoje. A conclusão faz parte do relatório The State of Incident Response Readiness 2026, baseado em uma pesquisa realizada com 600 executivos de segurança da informação. O estudo revela uma diferença significativa entre possuir recursos de resposta a incidentes e conseguir utilizá-los de forma coordenada durante uma crise. Além disso, 76% das organizações afirmaram ter sofrido pelo menos um ataque cibernético nos últimos 12 meses, enquanto 32% enfrentaram mais de um incidente no período. Segundo o relatório, a resposta a incidentes deixou de ser apenas uma atividade técnica. Hoje, ela envolve gestão de crise, equipes executivas, departamentos jurídicos, comunicação, investigações forenses, recuperação de ambientes e monitoramento pós-incidente. Mesmo assim, menos de 40% dos entrevistados classificaram como "altamente eficazes" componentes essenciais da resposta, como planos documentados, exercícios de simulação (tabletop), threat hunting, perícia digital e monitoramento contínuo. Falta de coordenação atrasa decisões A pesquisa aponta que o maior desafio não está na ausência de ferramentas, mas na dificuldade de coordenar diferentes áreas durante um incidente. Cerca de 90% das organizações esperam enfrentar dificuldades para alinhar todas as partes envolvidas em um ataque relevante. Além disso, 75% afirmam que atrasos na participação das equipes jurídica e de comunicação comprometem a tomada de decisões. Outro dado preocupante é que 89% dos entrevistados consideram insuficiente o envolvimento da alta direção e dos conselhos administrativos na preparação e nas decisões relacionadas à resposta a incidentes. Na prática, isso faz com que as equipes técnicas iniciem a contenção do ataque enquanto executivos aguardam atualizações antes de aprovar medidas críticas, departamentos jurídicos entram tardiamente na discussão e decisões sobre comunicação com clientes ou divulgação do incidente acabam sendo postergadas. Falta de visibilidade favorece novos ataques O levantamento também mostra que muitas empresas ainda possuem pontos cegos em seus ambientes de TI. Segundo a pesquisa, 78% acreditam que a falta de visibilidade permite que invasores mantenham acesso persistente aos sistemas, aumentando o risco de novos incidentes. Esses pontos cegos podem envolver infraestruturas locais, ambientes em nuvem, dispositivos, plataformas SaaS, sistemas de identidade e até ambientes de tecnologia operacional (OT). Sem essa visibilidade, torna-se mais difícil responder perguntas fundamentais durante uma investigação, como o ponto inicial da invasão, quais sistemas foram comprometidos, se houve movimentação lateral, se contas privilegiadas foram afetadas ou se todos os mecanismos de persistência foram realmente eliminados. Ambientes industriais elevam o risco operacional Outra preocupação crescente envolve ataques que transitam entre ambientes corporativos e sistemas industriais. Segundo o estudo, 84% das organizações demonstram preocupação com a possibilidade de invasores migrarem dos ambientes tradicionais de TI para infraestruturas de tecnologia operacional (OT) e sistemas de controle industrial (ICS). Esse cenário preocupa especialmente setores como indústria, energia, saúde, transporte e infraestrutura crítica, onde um ataque pode interromper operações físicas, comprometer a segurança de processos e ampliar significativamente o tempo de recuperação. Impactos financeiros continuam aumentando Os ataques registrados nos últimos doze meses provocaram consequências diretas para as empresas, incluindo paralisação de operações, perda de dados, danos à reputação, redução da base de clientes, perda de receita e impactos sobre a liderança executiva. O relatório também identificou diferenças entre setores. Empresas de varejo registraram mais interrupções operacionais e perdas financeiras. Organizações industriais e do setor financeiro sofreram mais com perda de dados, enquanto empresas de criptomoedas e finanças descentralizadas apresentaram a maior incidência de ataques. Já instituições privadas de saúde demonstraram maior preocupação com atrasos envolvendo áreas jurídica e de comunicação. Regionalmente, a América do Norte registrou o maior número de ataques. Na região Ásia-Pacífico (APAC), os incidentes geraram mais perdas de dados, danos reputacionais e perda de clientes. Na Europa, embora a frequência tenha sido menor, os ataques apresentaram maior impacto financeiro. Ransomware e ataques à nuvem lideram preocupações Entre as ameaças futuras, o ransomware permanece como a principal preocupação das organizações, seguido pelos ataques contra ambientes em nuvem. O estudo destaca, porém, que o cenário atual é marcado por múltiplos vetores de ataque, incluindo comprometimento de identidades, riscos de terceiros, ataques assistidos por inteligência artificial e campanhas que se movimentam entre ambientes híbridos de TI e OT. IA fortalece a resposta, mas não substitui processos A adoção de inteligência artificial para detecção de ameaças e resposta a incidentes continua crescendo. Quase um terço das organizações afirma utilizar IA de forma ampla nessas atividades, contra 25% no ano anterior. Para 2027, 63% esperam que essas tecnologias estejam presentes na maior parte dos processos de resposta. Segundo o relatório, empresas que utilizam IA de forma mais madura tendem a avaliar suas capacidades de resposta como mais eficazes. Ainda assim, a tecnologia não substitui governança, processos bem definidos, visibilidade dos ambientes e coordenação entre equipes. Empresas reavaliam fornecedores de resposta a incidentes Outro resultado do levantamento mostra que muitas organizações pretendem trocar seus fornecedores de resposta a incidentes e serviços de Managed Detection and Response (MDR) ao término dos contratos atuais. Entre os principais motivos estão a busca por suporte preventivo mais robusto, maior cobertura entre ambientes de TI, OT e nuvem, especialistas mais experientes em incidentes complexos, melhor visibilidade de ambientes híbridos e respostas mais rápidas durante investigações críticas. O relatório também alerta para os riscos de depender exclusivamente de um único ecossistema tecnológico, o que pode limitar a capacidade de investigação quando o incidente envolve múltiplas plataformas. Como recomendações, os pesquisadores destacam a necessidade de definir previamente responsabilidades entre áreas técnicas e executivas, realizar exercícios conjuntos de simulação, validar continuamente a visibilidade dos ambientes críticos, utilizar IA como apoio aos processos de resposta e avaliar regularmente a capacidade das equipes internas e dos parceiros especializados. Segundo o estudo, a principal conclusão é que a maturidade em resposta a incidentes depende menos da quantidade de ferramentas disponíveis e mais da capacidade de executar processos testados, com responsabilidades claras, boa coordenação e visibilidade completa da infraestrutura.

O grupo de cibercrime Silver Fox, ligado à China, foi identificado conduzindo uma nova campanha de phishing contra uma fabricante japonesa. Os invasores utilizam e-mails altamente personalizados com temas relacionados a impostos, reajustes salariais, mudanças de cargo e planos de participação acionária para induzir funcionários a instalar o malware ValleyRAT, ampliando a atuação do grupo contra empresas no Japão. Segundo a análise, a campanha faz parte de uma estratégia que explora períodos de maior movimentação administrativa nas empresas, quando comunicações sobre folha de pagamento, recursos humanos e obrigações fiscais são comuns. Os e-mails são escritos em japonês e simulam comunicações legítimas, aumentando as chances de sucesso da engenharia social. O ataque leva as vítimas a baixar arquivos compactados contendo instaladores maliciosos. Após a execução, é instalado o ValleyRAT (também conhecido como Winos 4.0), um trojan de acesso remoto que concede aos invasores controle sobre o equipamento comprometido. O malware permite coletar informações sensíveis, monitorar a atividade do usuário, estabelecer persistência e executar comandos remotamente. Os pesquisadores destacam que o Silver Fox vem evoluindo rapidamente seu arsenal. Além do ValleyRAT, o grupo passou a utilizar ferramentas como AtlasCross RAT, além de empregar domínios falsos que imitam softwares populares, VPNs, aplicativos de mensagens, plataformas de videoconferência e serviços corporativos para distribuir malware. A campanha observada no Japão reforça uma mudança no foco geográfico do grupo. Inicialmente concentrado em vítimas de língua chinesa, o Silver Fox expandiu suas operações desde o fim de 2025 para diversos países da Ásia, incluindo Japão, Índia, Malásia, Indonésia, Filipinas, Singapura e Tailândia. Pesquisadores apontam que o grupo mantém um modelo de operação híbrido. Paralelamente a campanhas oportunistas de larga escala voltadas ao lucro, os operadores realizam ataques direcionados contra organizações específicas, adaptando os temas das mensagens de phishing ao contexto cultural e ao calendário de cada país para aumentar a taxa de infecção. Embora a campanha atual tenha como alvo uma fabricante japonesa, os especialistas alertam que a metodologia empregada pode ser facilmente adaptada para outros setores. O uso de engenharia social altamente contextualizada, combinado com malware modular e técnicas de persistência, torna o Silver Fox um dos grupos de cibercrime mais ativos na região da Ásia-Pacífico.

Pesquisadores da Proofpoint identificaram uma campanha de espionagem cibernética em que um grupo ligado à Rússia está explorando uma vulnerabilidade no Microsoft Outlook Web Access (OWA) para manter acesso persistente a caixas de e-mail, mesmo após as vítimas alterarem suas credenciais. A atividade foi atribuída ao grupo TA488, também conhecido como Void Blizzard ou Laundry Bear. Segundo a pesquisa, a campanha teve início em 22 de julho de 2026 e tem como alvo organizações governamentais e empresas dos setores de telecomunicações, financeiro, hotelaria e aeroespacial nos Estados Unidos e na Europa. O ataque explora uma vulnerabilidade no OWA que permite a execução de código JavaScript no contexto da sessão do usuário. A falha, identificada anteriormente como CVE-2026-42897, pode ser acionada quando a vítima simplesmente abre um e-mail especialmente preparado no Outlook Web Access, sem necessidade de clicar em links ou abrir anexos. Após a exploração, os invasores implantam um implante conhecido como OWAReaper, projetado para permanecer ativo mesmo após reinicializações do navegador, troca de senhas e até mesmo a reinstalação do computador da vítima. Para isso, o malware combina mecanismos de armazenamento no navegador com abuso de permissões do Exchange, garantindo acesso contínuo à caixa de correio comprometida. Os pesquisadores afirmam que essa técnica representa uma evolução dos chamados ataques "half-click", nos quais basta visualizar a mensagem maliciosa para que a exploração seja iniciada. O grupo já havia utilizado estratégia semelhante em campanhas contra servidores Zimbra, explorando uma vulnerabilidade de dia zero para comprometer organizações governamentais e militares. A Microsoft divulgou a vulnerabilidade CVE-2026-42897 em maio de 2026 e lançou correções definitivas em julho para as versões suportadas do Exchange Server 2016, Exchange Server 2019 e Exchange Server Subscription Edition. O Exchange Online não é afetado pela falha. Além da aplicação das atualizações, especialistas recomendam monitorar permissões delegadas de caixas de correio, investigar atividades suspeitas que persistam após a troca de credenciais e revisar continuamente acessos privilegiados ao ambiente Exchange. O caso evidencia uma mudança na estratégia de grupos de espionagem, que passam a concentrar esforços em aplicações de webmail para obter persistência e acesso contínuo a comunicações corporativas, reduzindo a dependência de malwares tradicionais instalados nos dispositivos das vítimas.

A Amazon afirmou que o sequestro dos populares pacotes debug e chalk, ocorrido em setembro de 2025, foi conduzido por um grupo de hackers ligado à Coreia do Norte. A nova atribuição amplia uma investigação que, até então, era tratada como um ataque voltado ao roubo de criptomoedas, sem identificação pública dos responsáveis. Em relatório publicado em 29 de julho, a equipe de inteligência da Amazon avaliou, com confiança moderada, que o mesmo grupo responsável pelo comprometimento do pacote axios, em março de 2026, também esteve por trás do incidente envolvendo debug e chalk. O ataque original ocorreu após um mantenedor ser vítima de phishing por meio de um domínio falso semelhante ao do npm. Os invasores publicaram versões maliciosas em pelo menos 18 pacotes, que juntos somavam mais de 2 bilhões de downloads semanais. Segundo análises anteriores da Aikido e da Wiz, o código interceptava transações de carteiras de criptomoedas em navegadores, alterando os endereços de destino antes da confirmação pelo usuário. A Amazon também relacionou uma terceira campanha envolvendo o pacote typo-crypto, publicado em março de 2025. De acordo com a empresa, o pacote funcionou como um teste das técnicas que mais tarde seriam empregadas em ataques contra projetos muito mais populares. A análise identifica um padrão comum nas três campanhas: engenharia social contra mantenedores confiáveis seguida da publicação de versões comprometidas. Apesar da nova atribuição, a Amazon não apresentou evidências detalhadas que liguem diretamente cada incidente ao mesmo grupo. O relatório menciona semelhanças em técnicas utilizadas, reutilização de código, indicadores de comando e controle (C2) e pacotes trojanizados, mas não especifica quais evidências sustentam cada associação. O caso do debug e chalk chama atenção porque o mecanismo utilizado difere do observado no ataque ao axios. Enquanto o comprometimento do axios explorava scripts executados durante a instalação do pacote (post-install), o código malicioso presente em debug e chalk atuava diretamente no navegador, interceptando chamadas das APIs fetch, XMLHttpRequest e de carteiras de criptomoedas, sem estabelecer persistência no sistema. A atribuição ao grupo norte-coreano também é reforçada por análises de outras empresas sobre o incidente envolvendo o axios. O Google associou o ataque ao grupo UNC1069, enquanto a Microsoft atribuiu a campanha ao Sapphire Sleet, grupo que também é conhecido por nomes como BlueNoroff, STARDUST CHOLLIMA, CryptoCore, Alluring Pisces e CageyChameleon. A própria Aikido, responsável por detectar o comprometimento de debug e chalk em 2025, afirmou que já associava esses ataques à Coreia do Norte havia algum tempo. Segundo a empresa, a relação entre os casos já havia sido apresentada em publicações técnicas, conferências e podcasts, sendo considerada amplamente conhecida entre pesquisadores especializados em segurança da cadeia de suprimentos. A investigação também revelou inconsistências envolvendo o pacote typo-crypto. Embora a Amazon afirme que todas as campanhas começaram com o comprometimento de mantenedores, os registros do npm mostram que esse pacote possuía apenas uma versão publicada, criada e disponibilizada em um intervalo de apenas 204 milissegundos. Isso indica que o projeto pode ter sido criado diretamente para se passar pelo legítimo crypto-js, e não resultado do comprometimento de um projeto existente. Enquanto a discussão sobre a atribuição continua, o npm vem adotando medidas para reduzir ataques à cadeia de suprimentos. Em julho, a plataforma passou a desabilitar, por padrão, scripts executados durante a instalação de dependências na versão 12 do gerenciador de pacotes e iniciou a análise automática de novos pacotes publicados antes de disponibilizá-los aos usuários. No entanto, especialistas alertam que essas mudanças não impedem ataques baseados no comprometimento de contas de mantenedores.

A equipe do Ruby on Rails corrigiu uma vulnerabilidade crítica no Active Storage que pode permitir que invasores não autenticados leiam arquivos arbitrários do servidor por meio do envio de imagens especialmente manipuladas. A falha, identificada como CVE-2026-66066 (CVSS 9,5), pode expor segredos da aplicação e abrir caminho para execução remota de código (RCE). O problema afeta aplicações que utilizam o libvips para processamento de imagens no Active Storage e aceitam uploads de arquivos enviados por usuários não confiáveis. Segundo os pesquisadores, a vulnerabilidade permite acessar informações sensíveis armazenadas no ambiente da aplicação, incluindo secret_key_base, a Rails Master Key, credenciais de banco de dados, chaves de serviços em nuvem e tokens de APIs. De acordo com a Ethiack e a GMO Flatt Security, são afetadas as versões Rails 7.0.0 até 7.2.3.1, Rails 8.0.0 até 8.0.5 e Rails 8.1.0 até 8.1.3. As versões 6.0.0 até 6.1.7.10 também são vulneráveis quando configuradas para utilizar o libvips, embora esse não fosse o processador padrão nessa geração. Aplicações que utilizam MiniMagick não são afetadas por essa cadeia de ataque. Segundo a equipe de segurança do Rails, ambientes baseados em Debian, Ubuntu e imagens Docker geradas pelo próprio framework costumam incluir as bibliotecas necessárias para exploração da falha por padrão, embora isso possa variar conforme a distribuição utilizada. A vulnerabilidade está na integração entre o Active Storage e o libvips. O componente aceita diferentes formatos e operações suportados por bibliotecas de terceiros, algumas classificadas como inseguras para dados enviados por usuários. Como essas operações não eram bloqueadas pelo Active Storage, um arquivo especialmente elaborado podia ser utilizado para acessar qualquer arquivo que pudesse ser lido pelo processo da aplicação. A exploração não depende da existência de funcionalidades específicas, como geração de miniaturas ou redimensionamento de imagens. Segundo a equipe do Rails, tanto o analisador quanto o transformador de imagens encaminhavam arquivos enviados pelos usuários para operações inseguras do libvips. Embora a vulnerabilidade permita inicialmente apenas a leitura de arquivos, os pesquisadores alertam que a obtenção de credenciais sensíveis pode resultar em comprometimento completo da aplicação, execução remota de código ou movimentação lateral para outros sistemas conectados. Até o momento da divulgação, não havia relatos de exploração ativa nem vítimas conhecidas. No entanto, após a publicação do boletim de segurança, um repositório de terceiros no GitHub disponibilizou uma prova de conceito (PoC) que afirma reproduzir toda a cadeia de ataque — da leitura arbitrária de arquivos até a execução remota de código em um ambiente Docker de testes. A equipe do The Hacker News informou que não validou independentemente o funcionamento desse código. As correções estão disponíveis nas versões Rails 7.2.3.2, 8.0.5.1 e 8.1.3.1. Além da atualização, os mantenedores recomendam atualizar o libvips para a versão 8.13 ou superior, utilizar ruby-vips 2.2.1 ou posterior quando aplicável e realizar a rotação de todos os segredos que possam ter sido acessados pelo processo da aplicação, incluindo secret_key_base, Master Key, credenciais de banco de dados, chaves do Active Storage e tokens de serviços externos. A vulnerabilidade foi reportada independentemente por André Baptista, Bruno Mendes e Rafael Castilho, da Ethiack, e por RyotaK, da GMO Flatt Security. A equipe do Rails informou que divulgará detalhes técnicos adicionais até 28 de agosto de 2026.

A Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) incluiu uma nova vulnerabilidade do Cisco Secure Firewall Management Center (FMC) em seu catálogo de Vulnerabilidades Conhecidamente Exploradas (KEV) após a confirmação de ataques ativos contra a falha. Identificada como CVE-2026-20316 (CVSS 5,3), a vulnerabilidade permite que um invasor remoto e não autenticado utilize credenciais estáticas de uma conta com privilégios reduzidos para acessar dispositivos vulneráveis e visualizar informações sensíveis. Segundo a Cisco, o problema é causado pela existência de credenciais fixas incorporadas ao software. Embora a conta tenha permissões limitadas, a empresa classificou o impacto como High (alto), e não médio, porque a falha pode ser combinada com outras vulnerabilidades do Cisco Secure FMC para obtenção de privilégios mais elevados. A superfície de ataque é significativamente reduzida quando a interface de gerenciamento do FMC não está exposta diretamente à internet. Ainda assim, a fabricante confirmou que a vulnerabilidade já vem sendo explorada em ataques reais, sem divulgar quando a campanha começou, quem são os responsáveis ou quais técnicas estão sendo utilizadas. A falha foi descoberta pelo pesquisador Jimi Sebree, da Horizon3.ai, e já recebeu correções por meio de hotfixes para as versões 7.0, 7.2, 7.4, 7.6, 7.7 e 10.0 do Cisco Secure FMC. Como indicador de comprometimento (IoC), a Cisco orienta administradores a verificarem os logs do sistema em busca da referência /var/tmp/license.tmp, que pode indicar tentativa de exploração da vulnerabilidade. A Cisco também atualizou o boletim referente à CVE-2026-20079 (CVSS 10,0), uma vulnerabilidade crítica de bypass de autenticação no Cisco Secure FMC. Embora a empresa afirme não ter evidências de exploração dessa falha, o compartilhamento do mesmo indicador de comprometimento sugere que invasores podem encadear as duas vulnerabilidades para obter execução de código e acesso privilegiado ao sistema. Após a confirmação da exploração da CVE-2026-20316, a CISA determinou que as agências do Federal Civilian Executive Branch (FCEB) apliquem as correções até 1º de agosto de 2026. A recomendação também se estende a organizações que utilizam o Cisco Secure Firewall Management Center, especialmente aquelas com interfaces de gerenciamento acessíveis pela internet.