O sistema público de saúde da Inglaterra confirmou uma mudança de política que permitirá que funcionários da Palantir Technologies tenham acesso direto a dados identificáveis de pacientes do NHS, ampliando as permissões anteriormente concedidas dentro do controverso projeto Federated Data Platform (FDP). A plataforma é operada pela NHS England e utiliza tecnologia fornecida pela Palantir por meio de um contrato avaliado em £330 milhões, equivalente a aproximadamente US$ 446 milhões. O objetivo do FDP é centralizar e compartilhar dados entre diferentes unidades do sistema público de saúde britânico para otimizar operações, reduzir filas acumuladas após a pandemia e monitorar o desempenho do NHS. Até então, funcionários da Palantir envolvidos no projeto só podiam acessar conjuntos específicos de dados mediante autorização pontual e limitada dentro do National Data Integration Tenant (NDIT), repositório que armazena informações de pacientes antes da transferência para ambientes analíticos pseudonimizados. Com a mudança, alguns profissionais da empresa poderão receber um novo perfil administrativo com acesso ampliado ao NDIT, incluindo informações identificáveis de pacientes. Outros consultores externos que trabalham no FDP também terão permissões semelhantes. Documentos internos confirmados pelo NHS e obtidos inicialmente pelo Financial Times apontam que a própria organização reconheceu o risco de perda de confiança pública relacionado à decisão. O material afirma que ampliar o acesso de funcionários da Palantir aos dados poderia comprometer as garantias anteriormente apresentadas sobre proteção, governança e uso apropriado das informações médicas. Segundo o NHS England, o acesso será restrito a um pequeno grupo de profissionais envolvidos na implementação da plataforma central de coleta e monitoramento de desempenho do sistema de saúde. A organização afirmou ainda que qualquer pessoa externa que necessite acessar os dados deverá possuir autorização de segurança do governo britânico e aprovação formal de diretores do NHS. O caso reacende críticas históricas envolvendo a participação da Palantir em projetos governamentais e de vigilância. A empresa, fundada com apoio de investimentos ligados à comunidade de inteligência dos Estados Unidos, mantém contratos com órgãos militares, agências de segurança e governos ao redor do mundo, o que frequentemente gera debates sobre privacidade e uso ético de dados sensíveis. Sam Smith, coordenador do grupo de privacidade medConfidential, afirmou que funcionários da Palantir já possuíam algum nível de acesso a dados pseudonimizados em outras áreas do FDP. Para ele, o principal problema foi a falta de transparência do NHS sobre o real alcance dessas permissões. De acordo com Smith, a divulgação do tema ocorreu por meio de vazamentos internos, e não de uma comunicação pública clara sobre o funcionamento do acesso aos dados médicos. A crítica reforça preocupações recorrentes sobre governança, consentimento e prestação de contas em projetos de centralização de informações de saúde. O debate ocorre em um momento delicado para o NHS. Em março, a publicação Health Service Journal informou que quase um terço das unidades do sistema conectadas ao FDP em 2025 não atendiam integralmente aos padrões de segurança de dados exigidos. Mesmo diante das críticas, autoridades britânicas insistem que o NHS continua sendo o controlador exclusivo das informações. O ministro responsável pelo projeto, Zubir Ahmed, declarou recentemente ao Parlamento que a Palantir não possui propriedade sobre os dados, produtos ou propriedade intelectual da plataforma, e que todas as permissões são rigidamente controladas pelo governo britânico. Segundo Ahmed, a empresa opera sob um contrato regulado no Reino Unido e só pode utilizar informações para finalidades previamente aprovadas que tragam benefícios aos pacientes. A controvérsia envolvendo o FDP também chama atenção para uma tendência crescente em governos e sistemas de saúde: a adoção de plataformas centralizadas de análise de dados em larga escala. Embora essas iniciativas prometam ganhos operacionais, eficiência e inteligência analítica, elas também ampliam a superfície de risco relacionada à privacidade, vazamento de dados sensíveis e abuso de acesso privilegiado.

Uma instituição financeira dos Estados Unidos reportou a si própria à SEC, órgão regulador do mercado financeiro norte-americano, após identificar que dados confidenciais de clientes foram inseridos em uma aplicação de inteligência artificial não autorizada pela organização. O caso envolve o Community Bank, banco regional com operações nos estados da Pensilvânia, Ohio e Virgínia Ocidental. A empresa informou que iniciou uma investigação interna sobre o incidente e decidiu formalizar a ocorrência por meio de um documento 8-K enviado à Securities and Exchange Commission (SEC), devido ao “volume e à natureza sensível das informações não públicas” envolvidas. Segundo o comunicado, os dados expostos incluem nomes de clientes, datas de nascimento e números de Social Security Number (SSN), equivalente ao CPF nos Estados Unidos. O banco não revelou quantas pessoas foram afetadas nem forneceu detalhes técnicos adicionais sobre o vazamento. A instituição também não especificou qual era a “aplicação de software baseada em IA não autorizada” utilizada internamente. Ainda assim, a descrição do incidente levanta a possibilidade de que funcionários tenham inserido informações sigilosas em ferramentas de IA generativa fora do ambiente corporativo aprovado pela instituição. Caso esse cenário seja confirmado, especialistas apontam que os dados podem ter sido transmitidos para plataformas terceirizadas de inteligência artificial, o que abre discussões sobre retenção, processamento e possível reutilização dessas informações pelos provedores dos serviços. Nos Estados Unidos, números de Social Security são considerados dados extremamente sensíveis e estão protegidos por diversas legislações estaduais e federais. Vazamentos desse tipo podem aumentar significativamente o risco de fraude financeira, roubo de identidade e golpes direcionados contra clientes. O episódio também reforça uma preocupação crescente no setor financeiro: o uso não controlado de ferramentas de IA generativa dentro de ambientes corporativos. Nos últimos meses, empresas de diversos segmentos passaram a restringir ou monitorar o uso de plataformas de IA por colaboradores após casos envolvendo exposição involuntária de código-fonte, documentos internos, dados financeiros e informações pessoais. Apesar do incidente, o Community Bank afirmou que não houve impacto operacional. Segundo a instituição, os clientes continuaram tendo acesso normal às contas e aos serviços de pagamento durante toda a investigação. O banco informou ainda que está avaliando quais dados foram efetivamente afetados e conduzindo as notificações obrigatórias conforme exigências regulatórias e leis federais e estaduais aplicáveis. A organização também confirmou que segue em contato com reguladores bancários e financeiros dos Estados Unidos enquanto implementa medidas corretivas para evitar novos incidentes. O caso evidencia um desafio crescente para instituições financeiras e empresas altamente reguladas: equilibrar o uso de inteligência artificial com políticas rígidas de governança, classificação da informação e prevenção contra vazamento de dados sensíveis. Sem controles claros, ferramentas de IA podem acabar se tornando um novo vetor de exposição involuntária de informações críticas.

O Google está preparando uma nova linha de laptops baseados em Android, em vez do ChromeOS, em uma tentativa de reposicionar sua presença no mercado de computadores portáteis e avançar para um segmento mais premium. Os novos dispositivos, chamados informalmente de Googlebooks no material original, devem combinar elementos do ChromeOS e do Android, mas com uma diferença central: a inteligência artificial Gemini estará profundamente integrada à experiência do sistema. A proposta marca uma mudança importante na estratégia da empresa. Por anos, os Chromebooks foram associados principalmente a dispositivos mais simples, acessíveis e populares em ambientes educacionais. Com os novos laptops Android, o Google parece buscar um espaço mais próximo dos notebooks premium com Windows e macOS, usando o ecossistema Android como diferencial competitivo. A movimentação também reforça uma tendência cada vez mais evidente entre grandes empresas de tecnologia: integrar assistentes de IA diretamente ao sistema operacional e aos fluxos de trabalho do usuário. No caso dos Googlebooks, a presença do Gemini parece ir além de um aplicativo ou painel lateral. Segundo a demonstração apresentada pela empresa, a IA será acionada de forma contextual em diferentes partes da interface, inclusive a partir do movimento do cursor sobre elementos na tela. Um dos recursos destacados é o Magic Pointer. A função é ativada quando o usuário movimenta o cursor de determinada forma e passa a exibir sugestões baseadas no conteúdo sobre o qual o ponteiro está posicionado. Em um exemplo demonstrado por Alexander Kuscher, diretor sênior de laptops e tablets do Google, ao passar o cursor sobre uma data em um e-mail, o sistema apresentou opções para consultar a agenda, criar uma resposta confirmando presença na cidade em 19 de maio e até usar o Google Maps para sugerir locais de encontro. Na prática, o recurso transforma ações comuns, como ler um e-mail ou selecionar uma informação, em pontos de entrada para tarefas automatizadas com IA. A ideia é reduzir etapas que normalmente exigiriam abrir um chatbot, copiar informações, formular um prompt e aguardar uma resposta. Ao mesmo tempo, a abordagem pode gerar incômodo para usuários que preferem sistemas menos intervencionistas ou que não desejam sugestões de IA surgindo em tarefas rotineiras. Outro exemplo apresentado envolve manipulação de imagens por arrastar e soltar. Durante a demonstração, Kuscher arrastou a foto de um quarto infantil sobre imagens de um papel de parede e de um berço. O sistema então gerou uma nova imagem combinando os elementos, criando uma visualização do ambiente com o berço e o papel de parede aplicados. Segundo o executivo, uma tarefa desse tipo normalmente exigiria acessar um chatbot, enviar os arquivos e escrever instruções; no Googlebook, o processo seria integrado diretamente à interface. O texto original observa que não foi esclarecido se o sistema poderia usar fotos dos usuários como dados de treinamento. Esse ponto é relevante porque a expansão de recursos generativos em sistemas operacionais aumenta a necessidade de transparência sobre privacidade, processamento local ou em nuvem, retenção de dados e uso de conteúdo pessoal para melhoria de modelos. Os Googlebooks também devem executar aplicativos Android, o que aproxima os notebooks do ecossistema móvel do Google. A demonstração mostrou o Duolingo rodando em uma janela vertical, semelhante à experiência em um smartphone. Os usuários também poderão iniciar aplicativos a partir do telefone, em uma abordagem comparável ao espelhamento de iPhone no ecossistema da Apple. O Google informou que os novos laptops serão produzidos com materiais e acabamento premium por parceiros como Acer, ASUS, Dell, HP e Lenovo. Os dispositivos também devem trazer uma barra luminosa com as cores do Google na tampa, um elemento visual voltado à identificação da linha. A chegada dos Googlebooks, no entanto, ocorre em um momento desafiador para o mercado de PCs. O texto menciona a escassez de memória RAM e a previsão da IDC de queda de 11,3% nas remessas de PCs em 2026. Ainda não há preços oficiais, mas a expectativa é que os novos modelos sejam significativamente mais caros que os Chromebooks, tradicionalmente vendidos nos Estados Unidos em uma faixa aproximada de US$ 200 a US$ 500. Esse posicionamento pode colocar os Googlebooks em concorrência direta com notebooks premium de consumo baseados em Windows e macOS. O desafio é que esse mercado enfrenta pressão por queda de demanda, enquanto consumidores tendem a manter dispositivos antigos por mais tempo. O texto também aponta que não há sinais claros de que o Google esteja mirando empresas, e que departamentos de TI podem não se interessar pelas funcionalidades priorizadas na apresentação. Além dos laptops Android, o Google anunciou a expansão do Gemini Intelligence para dispositivos Android de alto desempenho, incluindo modelos Samsung Galaxy e Google Pixel. A proposta é permitir que o telefone lide com tarefas consideradas repetitivas ou pouco produtivas, como preencher formulários online, resumir páginas da web e reescrever mensagens transcritas por voz para remover pausas e marcas naturais da fala. Durante a mesma apresentação, o Google também mostrou recursos previstos para o Android 17. Um deles é o Pause Point, uma função que permite marcar determinados aplicativos como distrativos. Quando o usuário tenta abrir esses apps, o sistema exibe uma solicitação para respirar fundo e reconsiderar a ação. A proposta segue uma linha semelhante a recursos de bem-estar digital já explorados por outras plataformas, mas com uma intervenção mais direta no momento de uso. Outra novidade é o Screen Reactions, recurso que permitirá capturar a tela do dispositivo junto com a imagem do próprio usuário em um canto inferior, facilitando a criação de vídeos de reação diretamente no Android. A funcionalidade aproxima o sistema operacional de formatos populares em redes sociais, especialmente vídeos em que criadores comentam conteúdos exibidos na tela. Ainda não está claro o que acontecerá com a linha Chromebook após a chegada dos Googlebooks. O texto informa que o Google foi questionado sobre o futuro dos dispositivos mais acessíveis, mas não respondeu. A expectativa apresentada é que os Chromebooks continuem atendendo o mercado educacional por algum tempo, enquanto os novos laptops Android tentam disputar uma faixa mais alta do mercado. A aposta do Google mostra como a inteligência artificial está deixando de ser apenas um recurso adicional para se tornar parte estrutural dos sistemas operacionais. Nos Googlebooks, o Gemini aparece como uma camada permanente de assistência, automação e criação. A questão é se os usuários verão isso como produtividade ampliada ou como mais uma tentativa de tornar a IA impossível de ignorar.

A Microsoft está alterando a forma como o Copilot aparece e pode ser acionado dentro dos aplicativos do Microsoft 365, em uma tentativa de tornar o assistente de inteligência artificial mais acessível para usuários de Word, Excel e PowerPoint. A mudança, descrita pela empresa como uma forma de “simplificar” o acesso ao recurso, também reacendeu críticas de usuários que consideram a presença do Copilot invasiva ou difícil de ignorar. Segundo a Microsoft, muitos usuários relataram não saber exatamente como começar a interagir com o Copilot nos aplicativos de produtividade. A empresa não detalhou de onde vieram esses comentários, mas a justificativa foi usada para explicar a decisão de reduzir e reorganizar os pontos de entrada do assistente dentro da interface do Office. A medida chega em um momento em que parte da base de usuários pede justamente mais controle sobre a presença da ferramenta. No fórum de feedback do Microsoft 365 Copilot, uma das solicitações mais votadas era por controles mais granulares de disponibilidade dos agentes. Entre os pedidos populares também estava a opção de desativar o botão flutuante do Copilot nos aplicativos do Office, descrito por alguns usuários como um recurso altamente disruptivo. Um dos comentários citados no pedido afirmava que impedir a remoção da “bolha” flutuante era uma decisão “além de desagradável”. A reação ilustra um ponto sensível na estratégia da Microsoft: ao mesmo tempo em que a empresa tenta acelerar a adoção da inteligência artificial nos aplicativos corporativos, parte dos usuários vê a integração como excessivamente presente na rotina de trabalho. Apesar das críticas, a Microsoft seguirá com a reformulação da interface. A principal mudança será a redução do número de formas de acesso ao Copilot. A partir da atualização, os usuários terão um ícone do Copilot no canto inferior direito da tela. Ao passar o cursor sobre o botão, o sistema poderá exibir sugestões de uso. Também haverá um ponto de entrada contextual quando o usuário interagir com algum conteúdo, como no caso de selecionar um trecho de texto. Na prática, a empresa tenta tornar o Copilot mais previsível dentro da experiência do Office. Em vez de múltiplos caminhos espalhados pela interface, a proposta é concentrar o acesso em locais específicos e vinculados ao contexto de uso. Isso pode facilitar a descoberta de recursos por quem ainda não incorporou o assistente à rotina, mas também mantém a ferramenta visível para usuários que prefeririam uma interface menos orientada por IA. A Microsoft também atualizou os atalhos de teclado relacionados ao Copilot. No Windows, pressionar F6 passará a mover o foco para o botão do Copilot dentro da área de trabalho do aplicativo. A tecla de seta para cima permitirá navegar entre prompts, enquanto o atalho Alt+C poderá mover o foco para o painel do Copilot Chat quando ele já estiver aberto. No Mac, os usuários deverão pressionar Cmd + Control + I para direcionar o foco ao botão do Copilot. Essas alterações indicam que a Microsoft está tentando transformar o Copilot em um elemento mais integrado ao fluxo natural de edição, análise e criação de documentos. A própria empresa afirmou que, em breve, o Copilot poderá editar conteúdo diretamente a partir da conversa, reforçando a visão de que o assistente deve atuar não apenas como uma ferramenta auxiliar, mas como parte ativa da experiência de produtividade. A recepção, no entanto, permanece dividida. O primeiro comentário na publicação da Microsoft sobre a novidade questionava como impedir totalmente a exibição do ícone, afirmando que até mesmo a versão fixada do botão era incômoda. A crítica resume o desconforto de usuários que não rejeitam necessariamente recursos de IA, mas querem maior capacidade de decidir quando e como eles aparecem na interface. As mudanças devem chegar à disponibilidade geral no Word, Excel e PowerPoint para Windows e Mac até o início de junho. Para empresas, a atualização pode exigir atenção adicional das equipes de TI e governança digital, especialmente em ambientes que adotam políticas mais rígidas sobre experiência do usuário, uso de IA generativa, produtividade assistida e controle de recursos habilitados nos aplicativos corporativos.

Um veterano arquiteto de redes chamado James Thain apresentou uma proposta para o “Internet Protocol Version 8”, ou IPv8, com a promessa de ampliar a capacidade do IPv4, preservar compatibilidade com a infraestrutura existente e evitar uma migração forçada para o IPv6. A ideia foi publicada como um Internet-Draft da Internet Engineering Task Force (IETF) em 16 de abril, mas, como todo documento desse tipo, ainda não possui status oficial nem representa uma decisão formal da entidade. A proposta tem chamado atenção no setor de redes porque não tenta simplesmente substituir o IPv6 ou criar uma nova arquitetura completamente incompatível. O objetivo declarado de Thain é evoluir o IPv4, adicionando uma espécie de “código de área” baseado em Autonomous System Numbers, conhecidos como ASNs. Esses números são identificadores únicos atribuídos por registros regionais da internet a operadores de rede e são usados para orientar decisões de roteamento entre redes autônomas. No site dedicado ao IPv8, Thain descreve o protocolo como uma suíte de rede gerenciada capaz de resolver o esgotamento do IPv4, unificar a administração de redes e manter 100% de compatibilidade retroativa. Segundo ele, não haveria necessidade de uma “flag day”, expressão usada para indicar uma migração coordenada e obrigatória em larga escala, nem de substituição imediata de dispositivos, aplicações ou redes existentes. O rascunho técnico afirma que o IPv4 seria um subconjunto adequado do IPv8. Na prática, isso significa que um endereço IPv8 com o campo de prefixo de roteamento definido como zero corresponderia a um endereço IPv4 tradicional. A proposta tenta preservar a lógica já conhecida da pilha IPv4, adicionando uma camada de identificação que permitiria ampliar drasticamente o espaço de endereçamento disponível. Em entrevista ao The Register, Thain afirmou que criou o rascunho porque os protocolos atuais foram desenvolvidos para resolver problemas de rede de outra época. Para ele, a realidade operacional da internet mudou, mas a evolução dos protocolos não acompanhou plenamente essa transformação. O arquiteto também argumenta que, fora grandes provedores de nuvem, hyperscalers e operadores de rede, muitas organizações não enxergam retorno claro sobre o investimento em uma migração para IPv6. Thain reconhece que o esgotamento dos endereços IPv4 pressiona empresas e operadoras a considerar o IPv6. Ainda assim, ele defende que a melhor abordagem seria melhorar o IPv4 para entregar um protocolo mais eficiente sem exigir uma atualização ampla da infraestrutura. Essa visão é justamente um dos pontos mais polêmicos da proposta, já que o IPv6 foi desenvolvido para resolver, entre outros desafios, a limitação estrutural do IPv4. O principal mecanismo sugerido pelo IPv8 é um novo formato de endereço no modelo r.r.r.r.n.n.n.n. Nesse esquema, o bloco “r” representa o ASN codificado como um inteiro de 32 bits, enquanto o bloco “n” corresponde a um endereço IPv4 convencional. A lógica é semelhante ao uso de um código de área em sistemas telefônicos: o identificador da rede amplia o contexto no qual o endereço IPv4 é interpretado. Com esse modelo, cada detentor de ASN receberia 2³² endereços de host, o equivalente a 4.294.967.296 endereços por organização ou operador de rede. Thain considera esse volume suficiente para quase todas as entidades conectadas à internet. Organizações que precisassem de mais capacidade provavelmente já operariam múltiplos ASNs, o que, segundo a proposta, permitiria expandir ainda mais o uso do modelo. A estimativa apresentada é que o IPv8 ampliaria o espaço de endereçamento IPv4 para cerca de 30 trilhões de endereços únicos. Esse número é muito inferior aos aproximadamente 340 undecilhões de endereços disponíveis no IPv6, mas, na avaliação de Thain, ainda seria suficiente para atender às necessidades práticas de grande parte do mercado, com a vantagem de manter uma continuidade operacional maior com o IPv4. Thain também argumenta que a adoção do IPv8 não exigiria mudanças profundas em protocolos de roteamento consolidados. Segundo ele, o Border Gateway Protocol, ou BGP, já sabe lidar com múltiplos protocolos, e o mesmo vale para MPLS. Na visão do arquiteto, o IPv8 seria uma evolução incremental do IPv4, exigindo servidores capazes de traduzir os chamados “códigos de área”, enquanto o restante da pilha permaneceria amplamente conhecido pelos profissionais de rede. Além do novo modelo de endereçamento, a proposta inclui um componente chamado “Zone server”. De acordo com o rascunho, esse servidor concentraria serviços necessários a um segmento de rede, incluindo atribuição de endereços por DHCP8, resolução de nomes por DNS8, sincronização de tempo por NTP8, coleta de telemetria por NetLog8, cache de autenticação por OAuth8, validação de rotas por um resolvedor WHOIS8, aplicação de controle de acesso por ACL8 e tradução entre IPv4 e IPv8 por XLATE8. Essa abordagem mostra que o IPv8, na visão de Thain, não seria apenas uma expansão de endereçamento. A proposta tenta combinar roteamento, gerenciamento, autenticação, telemetria e controle operacional em uma suíte de rede integrada. Esse ponto recebeu alguma recepção positiva de especialistas, mesmo entre aqueles que não estão convencidos da viabilidade do protocolo. Silvan Gephart, do provedor Openfactory, comentou que aprecia o fato de a proposta tratar tabela de roteamento, endereçamento, gestão, autenticação e complexidade operacional como partes de um problema maior. A observação sugere que, embora o IPv8 enfrente resistência, parte da comunidade reconhece que a administração da internet moderna envolve desafios que vão além da simples quantidade de endereços disponíveis. As críticas, porém, têm sido duras. Um leitor do The Register classificou o IPv8 como “uma distração e perda de tempo”. Outros questionamentos miram a própria maturidade técnica da proposta, sua viabilidade de adoção e a possibilidade de ela fragmentar ainda mais o debate sobre o futuro do endereçamento IP. Parte das críticas também aponta suspeitas de uso de inteligência artificial na elaboração do documento. Thain não negou ter usado chatbots para trabalhar no rascunho e afirmou considerar esse tipo de apoio uma prática contemporânea. Para ele, a validade da proposta deve ser medida por sua capacidade técnica de funcionar em um ambiente de testes, não apenas pela forma como o documento foi produzido. Para responder aos críticos, o arquiteto iniciou uma campanha de financiamento coletivo com meta de US$ 100 mil. O objetivo é criar um ambiente de testes para o IPv8, desenvolver software de código aberto, financiar pesquisa, montar infraestrutura de validação, produzir demonstrações e publicar documentação técnica. A expectativa de Thain é que um testbed funcional ajude a demonstrar se o protocolo pode cumprir o que promete. Por enquanto, o IPv8 permanece como uma proposta experimental, sem adoção formal pela IETF e sem garantia de aceitação pela comunidade técnica. Ainda assim, o debate em torno do projeto revela uma tensão persistente na internet: enquanto o IPv6 oferece um espaço de endereçamento praticamente inesgotável, a base instalada do IPv4 segue enorme, familiar e economicamente difícil de abandonar para muitas organizações.

Um novo trojan bancário brasileiro, identificado como TCLBANKER, foi descoberto por pesquisadores da Elastic Security Labs em uma campanha capaz de atingir 59 plataformas financeiras, incluindo bancos, fintechs e serviços de criptomoedas. A atividade está sendo rastreada sob o nome REF3076 e, segundo a análise, representa uma grande atualização da família Maverick, conhecida por utilizar o worm SORVEPOTEL para se espalhar pelo WhatsApp Web entre contatos das vítimas. A campanha anterior associada ao Maverick já havia sido atribuída pela Trend Micro ao grupo Water Saci. A nova operação chama atenção por combinar um trojan bancário completo com mecanismos de propagação automatizada via WhatsApp e Microsoft Outlook. Na prática, os invasores abusam de contas legítimas das próprias vítimas para enviar mensagens e e-mails maliciosos a contatos conhecidos, aumentando a chance de confiança e dificultando a detecção por filtros tradicionais de reputação e gateways de e-mail. De acordo com os pesquisadores Jia Yu Chan, Daniel Stepanic, Seth Goodwin e Terrance DeJesus, a cadeia de infecção observada começa com um arquivo ZIP contendo um instalador MSI malicioso. Esse instalador abusa de um programa legítimo e assinado da Logitech, chamado Logi AI Prompt Builder, para executar a ameaça por meio de uma técnica conhecida como DLL side-loading. Essa abordagem permite que um arquivo malicioso seja carregado por um software confiável, reduzindo suspeitas durante a execução. O componente malicioso, identificado como “screen_retriever_plugin.dll”, atua como loader e possui recursos avançados contra análise. Ele verifica continuamente a presença de ferramentas de depuração, sandboxes, disassemblers, soluções antivírus, ferramentas de instrumentação e outros mecanismos usados por pesquisadores e produtos de segurança. O objetivo é impedir que o malware seja estudado ou executado em ambientes controlados. A DLL só continua sua execução se for carregada pelo “logiaipromptbuilder.exe”, o programa legítimo da Logitech, ou pelo “tclloader.exe”, que parece ser um executável usado em testes. O malware também remove hooks em modo de usuário inseridos por soluções de segurança na biblioteca “ntdll.dll” e desativa a telemetria do Event Tracing for Windows, conhecido como ETW, reduzindo a visibilidade das ferramentas de monitoramento. Outro ponto relevante é o uso de três impressões digitais do ambiente infectado. O TCLBANKER realiza checagens anti-debugging e anti-virtualização, coleta informações do disco do sistema e verifica o idioma configurado no dispositivo. Esses dados são usados para gerar um hash do ambiente, necessário para descriptografar o payload embutido. Caso um depurador esteja presente, por exemplo, o hash gerado será incorreto, impedindo a descriptografia correta do malware e interrompendo sua execução. A verificação de idioma também restringe a operação a sistemas configurados em português do Brasil, indicando foco claro no mercado brasileiro. Após passar por essas validações, o componente principal do trojan bancário confirma novamente se está sendo executado em um ambiente brasileiro e cria persistência por meio de uma tarefa agendada no Windows. Em seguida, ele se comunica com um servidor externo via requisição HTTP POST, enviando informações básicas do sistema comprometido. O TCLBANKER possui ainda um mecanismo de autoatualização e um monitor de URLs capaz de extrair o endereço acessado no navegador em primeiro plano usando UI Automation. A técnica permite acompanhar a navegação da vítima em navegadores populares, como Google Chrome, Mozilla Firefox, Microsoft Edge, Brave, Opera e Vivaldi. Quando a URL acessada corresponde a uma instituição financeira presente em uma lista codificada no malware, o trojan estabelece uma conexão WebSocket com um servidor remoto e entra em um ciclo de recebimento de comandos. A partir daí, os operadores podem executar comandos no sistema, capturar telas, iniciar ou interromper streaming da tela, manipular a área de transferência, ativar keylogger, controlar mouse e teclado remotamente, gerenciar arquivos e processos, enumerar processos em execução, listar janelas visíveis e exibir sobreposições falsas para roubo de credenciais. Para conduzir o roubo de dados, o TCLBANKER usa uma estrutura de sobreposição em tela cheia baseada em Windows Presentation Foundation, tecnologia conhecida como WPF. Essas telas falsas são usadas em ações de engenharia social, incluindo prompts para coleta de credenciais, telas de espera associadas a vishing, barras de progresso falsas e falsas atualizações do Windows. O malware também tenta ocultar essas sobreposições de ferramentas de captura de tela, dificultando a análise e a resposta ao incidente. Além do roubo direto de credenciais e do controle remoto, a campanha inclui um módulo de propagação em larga escala. O loader aciona um componente de worm que explora duas frentes: um worm para WhatsApp Web, capaz de sequestrar sessões autenticadas no navegador, e um bot de e-mail que abusa do Microsoft Outlook instalado no computador da vítima para enviar mensagens de phishing a partir da conta legítima comprometida. No caso do WhatsApp, a abordagem lembra a usada pelo SORVEPOTEL. O worm obtém um modelo de mensagem a partir do servidor dos invasores e usa o projeto open source WPPConnect para automatizar o envio de mensagens. O componente também filtra grupos, listas de transmissão e números que não sejam brasileiros, reforçando o foco geográfico da campanha. Já o agente de Outlook funciona como um spambot. Ele utiliza o próprio aplicativo Microsoft Outlook instalado no dispositivo para enviar e-mails falsos a partir do endereço da vítima. Essa técnica aumenta a credibilidade da mensagem, já que o conteúdo chega a partir de uma conta conhecida, e pode contornar defesas baseadas em reputação de remetente ou infraestrutura. Segundo um porta-voz da Elastic ouvido pelo The Hacker News, o TCLBANKER pode sequestrar sessões do WhatsApp e contas do Outlook para enviar o instalador trojanizado a até 3 mil contatos. A distribuição ocorre por contas legítimas, contatos reais e infraestrutura confiável, o que reduz a eficácia de defesas tradicionais baseadas apenas em reputação. A análise também indica que a operação REF3076 ainda pode estar em estágio inicial. Os pesquisadores encontraram caminhos de debug, nomes de processos usados em testes e um site de phishing incompleto no código. Esses sinais sugerem que a campanha ainda está em desenvolvimento e pode ganhar novos recursos ou ajustes operacionais com o tempo. Para a Elastic, o TCLBANKER reflete um amadurecimento mais amplo no ecossistema brasileiro de trojans bancários. Técnicas antes associadas a invasores mais sofisticados, como descriptografia condicionada ao ambiente, geração direta de syscalls, orquestração de engenharia social em tempo real via WebSocket e abuso de canais legítimos de comunicação, estão sendo incorporadas a ferramentas de cibercrime mais acessíveis. O caso também mostra uma mudança relevante no modelo de distribuição de malware bancário. Em vez de depender apenas de domínios suspeitos, campanhas massivas de spam ou anexos enviados por remetentes desconhecidos, os operadores do TCLBANKER exploram a confiança já existente entre vítima e contatos. Isso torna o ataque mais difícil de identificar, especialmente em ambientes onde WhatsApp e Outlook são usados diariamente para comunicação pessoal e profissional.

Ramon Risuenho, consultor de cibersegurança especializado em Cloud Security, Security Operations e Google Cloud Platform, anunciou nesta semana a criação de um projeto educacional voltado a pessoas que desejam aprender comandos Linux, mas não possuem todos os recursos necessários para montar um ambiente virtualizado de estudos em casa. A iniciativa foi desenvolvida com apoio de inteligência artificial e tem como objetivo facilitar o acesso ao aprendizado prático do terminal Linux, uma habilidade considerada essencial para quem atua ou deseja ingressar em áreas como segurança da informação, infraestrutura, cloud, DevOps, SOC e resposta a incidentes. Segundo Ramon, o projeto foi pensado para ensinar os 30 comandos mais utilizados em ambientes Linux. A proposta inclui desde comandos básicos, usados para navegação no sistema de arquivos, cópia e manipulação de arquivos, até atividades um pouco mais avançadas, como leitura de arquivos de log e identificação de processos ocultos. A principal diferença da iniciativa está no fato de o ambiente funcionar diretamente pelo navegador. Isso reduz a barreira de entrada para estudantes que não têm computador com boa capacidade de processamento, não conseguem configurar máquinas virtuais ou ainda não estão familiarizados com ferramentas como VirtualBox, VMware, WSL ou laboratórios em nuvem. Em treinamentos de cibersegurança, o uso de ambientes Linux costuma ser uma etapa importante, mas também pode se tornar um obstáculo inicial. Muitos estudantes precisam instalar uma distribuição Linux, configurar uma máquina virtual, reservar memória e armazenamento, lidar com erros de rede ou permissões e, só depois disso, começar a praticar os comandos básicos. O projeto busca simplificar esse caminho ao oferecer uma experiência acessível diretamente no browser. Além do aprendizado guiado, Ramon também implementou um pequeno CTF, sigla para Capture The Flag, um formato de desafio muito usado na comunidade de segurança cibernética. Nesse tipo de exercício, os participantes resolvem tarefas técnicas e encontram “flags”, que funcionam como provas de que determinada etapa foi concluída corretamente. No contexto do projeto, o CTF serve como forma de incentivar a prática e transformar o estudo em uma experiência mais interativa. A abordagem pode beneficiar tanto iniciantes que ainda estão aprendendo a usar o terminal quanto profissionais que já conhecem Linux, mas estão há algum tempo sem praticar e querem recuperar familiaridade com os comandos. Entre as funcionalidades destacadas estão a interface responsiva, o aprendizado guiado, o sistema de pontuação e a possibilidade de executar os exercícios diretamente pelo navegador. Esses elementos aproximam o projeto de uma experiência de laboratório educacional, com foco em simplicidade, prática e acessibilidade. A interface responsiva permite que o conteúdo se adapte a diferentes tamanhos de tela, facilitando o acesso por computadores, notebooks e, dependendo da experiência oferecida, até dispositivos móveis. Já o sistema de pontuação adiciona um elemento de gamificação, ajudando o usuário a acompanhar sua evolução conforme avança pelos desafios. A iniciativa também acompanha uma tendência maior no ensino de tecnologia: a criação de laboratórios práticos mais leves, acessíveis e orientados por desafios. Em cibersegurança, esse modelo é especialmente relevante, pois muitos conceitos só se tornam claros quando o aluno interage com comandos, arquivos, logs, permissões, processos e cenários próximos da prática real. O domínio de comandos Linux é uma habilidade recorrente em diversas funções técnicas. Analistas de SOC usam o terminal para investigar logs e eventos. Profissionais de cloud interagem com servidores, containers e ferramentas de automação. Equipes de resposta a incidentes analisam processos, arquivos suspeitos e rastros de execução. Já estudantes de segurança ofensiva e defensiva dependem do Linux para trabalhar com ferramentas, scripts e ambientes de teste. Embora o projeto tenha sido descrito como simples, ele atende a uma necessidade comum entre iniciantes: começar a praticar sem depender de infraestrutura complexa. Para quem está dando os primeiros passos, conseguir executar comandos básicos, entender a estrutura de diretórios, listar arquivos, ler conteúdos e observar processos já representa uma base importante para estudos mais avançados. Ramon também abriu espaço para que usuários deixem feedbacks nos comentários, indicando que o projeto pode evoluir a partir da experiência da comunidade. Esse tipo de retorno pode ajudar a expandir os desafios, ajustar a dificuldade, incluir novos comandos e tornar o laboratório mais útil para diferentes níveis de conhecimento. O projeto está disponível no link divulgado pelo próprio autor e foi apresentado como uma contribuição para democratizar o acesso ao aprendizado prático em Linux. Em um mercado que exige cada vez mais conhecimento técnico, iniciativas desse tipo ajudam a reduzir barreiras e aproximar novos profissionais de habilidades fundamentais para a área de tecnologia e cibersegurança.

Um site falso que imita a página do Claude AI está sendo usado para distribuir um instalador malicioso chamado Claude-Pro Relay, que instala uma backdoor para Windows até então não documentada, batizada de Beagle por pesquisadores da Sophos. A campanha tenta se aproveitar da popularidade do Claude, modelo de linguagem e assistente de inteligência artificial da Anthropic, para enganar desenvolvedores e usuários interessados em ferramentas relacionadas ao Claude-Code. No site fraudulento, os hackers promovem o suposto Claude-Pro como um “serviço de relay de alta performance desenvolvido especificamente para desenvolvedores Claude-Code”. A página falsa, hospedada em claude-pro[.]com, tenta reproduzir visualmente o site legítimo, usando cores e fontes semelhantes. Ainda assim, a imitação é relativamente simples. De acordo com a Sophos, os links do site não levam a páginas funcionais e apenas redirecionam o visitante para a página inicial, deixando praticamente uma única ação disponível: clicar em um grande botão de download. Esse botão baixa um arquivo de 505 MB chamado Claude-Pro-windows-x64.zip, que contém um instalador MSI supostamente relacionado ao produto Claude-Pro Relay. Para usuários que não percebem os sinais de fraude, o arquivo pode parecer uma ferramenta legítima, especialmente por usar a marca Claude e se apresentar como uma solução voltada a desenvolvedores. Ao executar o binário, o instalador adiciona três arquivos à pasta de inicialização do Windows: NOVupdate.exe, NOVupdate.exe.dat e avk.dll. Essa localização é relevante porque itens colocados na pasta Startup podem ser executados automaticamente quando o usuário inicia a sessão no sistema, funcionando como um mecanismo simples de persistência. A campanha foi inicialmente identificada pela Malwarebytes. Segundo os pesquisadores da empresa, o instalador “Pro” é uma cópia trojanizada do Claude: a aplicação funciona como esperado, mas executa uma cadeia de malware PlugX em segundo plano, permitindo que os invasores obtenham acesso remoto ao sistema comprometido. Em uma análise mais aprofundada, a Sophos identificou que o primeiro estágio da infecção envolve o DonutLoader, um injetor em memória de código aberto. Ele é usado para carregar uma backdoor relativamente simples, chamada pelos pesquisadores de Beagle. O malware possui um conjunto limitado de comandos, incluindo desinstalar o agente, executar comandos, enviar e baixar arquivos, criar diretórios, renomear arquivos, listar conteúdo de pastas e remover arquivos. A Sophos destaca que essa backdoor Beagle não deve ser confundida com o worm Beagle, também conhecido como Bagle, escrito em Delphi e documentado em 2004. Apesar do nome semelhante, trata-se de uma ameaça distinta. A cadeia de ataque observada explora uma técnica conhecida como DLL sideloading. Nesse caso, o arquivo NOVupdate.exe é um atualizador assinado de soluções de segurança da G Data. Os hackers abusam desse executável legítimo para carregar a DLL maliciosa avk.dll e o arquivo criptografado NOVupdate.exe.dat. O uso de um executável assinado por um fornecedor legítimo ajuda a dar aparência de confiabilidade à execução e pode dificultar a detecção por algumas soluções de segurança. Segundo a Sophos, o sideloading da DLL AVK junto com um arquivo criptografado por meio de um executável assinado da G Data já foi associado anteriormente a atividades envolvendo PlugX. Na prática, a função da DLL maliciosa é descriptografar e executar em memória o conteúdo armazenado em NOVupdate.exe.dat. Esse conteúdo é o DonutLoader, que por sua vez carrega a carga final: a backdoor Beagle. A execução em memória é uma técnica comum para reduzir rastros no disco e tentar escapar de mecanismos tradicionais de detecção. A Sophos afirma já ter observado o DonutLoader em ataques de 2024 contra organizações governamentais no Sudeste Asiático. Nesta campanha, o carregador é usado para implantar o Beagle diretamente na memória do sistema, reforçando a tentativa dos operadores de reduzir a visibilidade da infecção. Após a instalação, a backdoor se comunica com o servidor de comando e controle, conhecido como C2, em license[.]claude-pro[.]com. A comunicação ocorre por TCP na porta 443 e/ou por UDP na porta 8080. As trocas de dados são protegidas por uma chave AES embutida no malware. A infraestrutura de C2 foi associada ao endereço IP 8.217.190[.]58. Segundo a Malwarebytes, esse IP pertence a uma faixa relacionada ao serviço Alibaba Cloud. A presença de infraestrutura em provedores de nuvem não é incomum em campanhas maliciosas, já que esses ambientes podem ser usados para hospedar rapidamente servidores de controle, páginas falsas e recursos de distribuição. A investigação da Sophos também encontrou amostras adicionais relacionadas ao Beagle enviadas ao VirusTotal entre fevereiro e abril deste ano. Essas amostras usavam a mesma chave XOR para descriptografia, sugerindo algum grau de reutilização de componentes ou de infraestrutura pelos responsáveis. Apesar da relação técnica com Beagle, essas outras amostras chegaram às máquinas por cadeias de ataque diferentes. Entre os elementos observados estavam binários do Microsoft Defender, shellcode do AdaptixC2, um PDF usado como isca e páginas falsas que imitavam sites de atualização de fornecedores de segurança, incluindo CrowdStrike, SentinelOne e Trellix. Embora a Sophos não tenha atribuído a campanha com confiança a um grupo específico, os pesquisadores levantam a possibilidade de que os mesmos operadores associados ao PlugX estejam experimentando uma nova carga maliciosa. PlugX é uma família de malware historicamente usada em campanhas de acesso remoto e espionagem, frequentemente associada a operações direcionadas. A recomendação para reduzir o risco é baixar o Claude apenas pelo portal oficial e evitar resultados patrocinados em mecanismos de busca, especialmente quando promovem instaladores, ferramentas auxiliares ou versões “Pro” não verificadas. A Sophos também aponta que a presença de arquivos com o nome NOVupdate em um sistema pode ser um forte indicativo de comprometimento. Para equipes de segurança, a campanha reforça a necessidade de monitorar execuções suspeitas na pasta Startup, uso anômalo de executáveis assinados, carregamento incomum de DLLs, conexões para domínios recém-criados e comunicação com infraestrutura externa nas portas 443 e 8080. Em ambientes corporativos, controles de allowlist, verificação de origem de instaladores e bloqueio de sites falsos podem ajudar a reduzir a exposição a esse tipo de ameaça.

Uma vulnerabilidade crítica na biblioteca vm2, usada para executar código JavaScript não confiável em ambientes isolados no Node.js, permite que invasores escapem do sandbox e executem comandos arbitrários no sistema host. A falha foi registrada como CVE-2026-26956 e teve código de prova de conceito, conhecido como PoC, publicado publicamente. O problema foi confirmado na versão 3.10.4 do vm2, embora versões anteriores também possam estar vulneráveis. Segundo o aviso de segurança divulgado pelo mantenedor, a vulnerabilidade afeta ambientes com Node.js 25, com confirmação no Node.js 25.6.1, quando estão habilitados os recursos WebAssembly exception handling e JSTag support. O vm2 é uma biblioteca open source bastante utilizada no ecossistema Node.js para executar scripts JavaScript fornecidos por usuários dentro de um ambiente restrito. Esse tipo de recurso é comum em plataformas de programação online, ferramentas de automação, aplicações SaaS e serviços que permitem a execução controlada de código enviado por terceiros. A proposta do vm2 é isolar o código executado no sandbox e impedir que ele acesse APIs sensíveis do Node.js, como o objeto process e o sistema de arquivos. Na prática, isso significa bloquear a interação direta entre o código não confiável e recursos internos do servidor, reduzindo o risco de execução indevida de comandos, leitura de arquivos ou manipulação do ambiente de hospedagem. A biblioteca tem ampla adoção, com mais de 1,3 milhão de downloads semanais no npm, o gerenciador de pacotes padrão do Node.js. Esse volume de uso aumenta a relevância da falha, especialmente para empresas que dependem de sandboxes JavaScript em produtos expostos à internet ou em fluxos automatizados de execução de código. A CVE-2026-26956 está relacionada ao tratamento incorreto de exceções que atravessam a fronteira entre o ambiente isolado e o sistema host. De acordo com o aviso de segurança, o vm2 normalmente depende de proteções implementadas no nível do JavaScript para impedir que erros originados no host sejam expostos ao sandbox sem controle. A biblioteca também utiliza proxies de ponte, conhecidos como bridge Proxies, para encapsular objetos que cruzam diferentes contextos de execução. O ponto crítico está no comportamento do WebAssembly exception handling. Esse recurso consegue interceptar erros JavaScript em uma camada mais baixa dentro do motor V8, usado pelo Node.js e pelo Google Chrome. Com isso, determinadas exceções podem contornar as defesas implementadas pelo vm2 no nível da linguagem JavaScript. A exploração descrita no aviso envolve a geração de um TypeError especialmente construído por meio da conversão de Symbol para string. Esse processo pode fazer com que um objeto de erro originado no host seja vazado de volta para dentro do sandbox sem passar pela sanitização esperada pelo vm2. Uma vez que esse objeto vem do ambiente host, o invasor pode abusar de sua cadeia de construtores para recuperar acesso a componentes internos do Node.js, incluindo o objeto process. A partir desse acesso, torna-se possível alcançar a execução arbitrária de comandos no sistema subjacente, comprometendo diretamente a segurança do servidor. O aviso de segurança do mantenedor inclui uma prova de conceito que demonstra a execução remota de código na máquina host. A publicação de um PoC aumenta a urgência da correção, já que reduz a barreira técnica para que a falha seja testada ou incorporada em ataques reais, especialmente contra aplicações que executam código JavaScript fornecido por usuários. A recomendação para administradores e desenvolvedores é atualizar o vm2 para a versão 3.10.5 ou superior o quanto antes. Segundo o texto original, a versão mais recente disponível é a 3.11.2. Organizações que usam Node.js 25 com os recursos afetados habilitados devem priorizar a atualização e revisar se seus serviços permitem a execução de scripts externos ou enviados por usuários. A falha também se soma a um histórico recente de vulnerabilidades críticas envolvendo escape de sandbox no vm2. No início de 2026, a biblioteca já havia sido impactada por outra falha crítica, rastreada como CVE-2026-22709, também com potencial para execução arbitrária de código no host. Casos anteriores incluem as vulnerabilidades CVE-2023-30547, CVE-2023-29017 e CVE-2022-36067. A recorrência desse tipo de problema evidencia a dificuldade técnica de isolar código não confiável em ambientes JavaScript, especialmente quando a segurança depende da separação entre contextos, tratamento seguro de exceções e bloqueio de acesso a objetos internos do runtime. Para equipes de segurança, o risco é mais relevante em aplicações que oferecem execução dinâmica de código, automações com scripts customizados, ambientes de avaliação online, sistemas de plugins e plataformas SaaS com lógica programável pelo usuário. Nesses cenários, uma falha de sandbox pode transformar um recurso legítimo da aplicação em um caminho para controle do servidor. Além da atualização da biblioteca, é recomendável revisar a exposição desses ambientes, restringir permissões do processo Node.js, aplicar controles de isolamento adicionais no sistema operacional ou em containers, monitorar tentativas de exploração e auditar dependências que utilizem vm2 de forma direta ou indireta.

Pesquisadores divulgaram detalhes de um novo backdoor para Linux chamado PamDOORa, anunciado no fórum russo de cibercrime Rehub por US$ 1.600 por um invasor identificado como “darkworm”. A ferramenta foi apresentada como um kit de pós-exploração baseado em módulos PAM, com foco em persistência via SSH e roubo de credenciais de usuários legítimos. O PamDOORa foi projetado para funcionar como um Pluggable Authentication Module, ou PAM, uma estrutura usada em sistemas Unix e Linux para integrar mecanismos de autenticação de forma modular. Na prática, o PAM permite que administradores adicionem ou alterem métodos de autenticação, como senhas, tokens ou biometria, sem reescrever aplicações já existentes. De acordo com Assaf Morag, pesquisador da Flare.io, o PamDOORa atua como um backdoor pós-exploração para autenticação em servidores via OpenSSH. A ferramenta supostamente mantém persistência em sistemas Linux x86_64 e permite que o invasor acesse o ambiente comprometido por meio de uma combinação específica de senha “mágica” e porta TCP. Esse tipo de mecanismo cria uma porta de entrada secreta no processo de autenticação. Mesmo que o serviço SSH continue funcionando aparentemente de forma normal para usuários legítimos, o módulo malicioso pode reconhecer uma senha especial e permitir o acesso do invasor, contornando os fluxos tradicionais de autenticação. Além da persistência, o PamDOORa também foi desenvolvido para capturar credenciais. Quando usuários legítimos se autenticam no sistema comprometido, o módulo pode coletar os dados informados durante o processo de login. Como o PAM participa diretamente da autenticação, um módulo malicioso posicionado nesse fluxo pode ter acesso a informações sensíveis antes que elas sejam validadas ou descartadas pelo sistema. A ameaça chama atenção porque os módulos PAM normalmente são executados com privilégios elevados, muitas vezes como root. Isso significa que um módulo comprometido, mal configurado ou criado com finalidade maliciosa pode representar um risco significativo, permitindo roubo de credenciais, acesso não autorizado e controle persistente do host. O PamDOORa é apontado como o segundo backdoor Linux conhecido a mirar diretamente a pilha PAM, após o Plague. Embora o PAM seja uma estrutura poderosa e amplamente utilizada, sua modularidade também amplia a superfície de ataque quando arquivos de configuração ou módulos são manipulados por invasores. A Group-IB já havia alertado, em setembro de 2024, que modificações maliciosas em módulos PAM podem criar backdoors ou roubar credenciais de usuários. O risco é agravado pelo fato de que o PAM não armazena senhas, mas pode transmitir valores em texto claro durante determinados fluxos de autenticação, dependendo da implementação e do módulo utilizado. Um dos pontos citados por pesquisadores é o abuso do módulo pam_exec, que permite executar comandos externos durante processos de autenticação. Quando manipulado por invasores, esse recurso pode ser usado para injetar scripts maliciosos em arquivos de configuração do PAM, obter um shell privilegiado e manter persistência de forma discreta no sistema. No caso do PamDOORa, a análise da Flare.io indica que a ferramenta vai além de backdoors PAM mais simples encontrados em repositórios públicos. Além de roubar credenciais e permitir acesso persistente via SSH, o malware incorpora capacidades antiforenses para adulterar logs de autenticação e apagar rastros da atividade maliciosa. Essa manipulação de registros é relevante porque logs de autenticação estão entre os principais artefatos usados por equipes de segurança para identificar acessos suspeitos, tentativas de login, uso indevido de contas e movimentações anômalas. Ao alterar metodicamente esses registros, o backdoor pode dificultar investigações e atrasar a resposta a incidentes. Até o momento, não há evidências de que o PamDOORa tenha sido usado em ataques reais. Ainda assim, a cadeia de infecção mais provável envolveria um invasor obtendo previamente acesso root ao sistema por outro meio, como exploração de vulnerabilidade, credenciais comprometidas ou configuração insegura. Depois disso, o módulo PAM malicioso seria implantado para capturar credenciais e garantir acesso persistente via SSH. Esse ponto é importante: o PamDOORa não parece ser descrito como uma ferramenta de acesso inicial. Ele se encaixa melhor em uma fase posterior da invasão, quando o invasor já comprometeu o host e busca manter presença, ampliar acesso e coletar credenciais de outros usuários que utilizam o sistema. A dinâmica comercial da ferramenta também foi observada pelos pesquisadores. O PamDOORa foi inicialmente anunciado por US$ 1.600 em 17 de março de 2026. Em 9 de abril, o preço havia sido reduzido para US$ 900, uma queda de quase 50%. Essa mudança pode indicar baixa demanda entre compradores ou uma tentativa do operador “darkworm” de acelerar a venda. Para Morag, o PamDOORa representa uma evolução em relação aos backdoors PAM open source existentes. Embora técnicas como hooks em PAM, captura de credenciais e adulteração de logs já sejam conhecidas, a integração desses recursos em um implante modular, com mecanismos anti-debugging, gatilhos baseados em rede e pipeline de builder, aproxima a ferramenta de um nível mais operacional. Esse tipo de desenvolvimento mostra como recursos tradicionalmente associados a provas de conceito podem ser reorganizados em ferramentas mais completas para uso por operadores de intrusão. Em vez de scripts isolados e rudimentares, o PamDOORa aparece como um pacote mais coeso, voltado para persistência, furtividade e coleta de credenciais em ambientes Linux. Para equipes de segurança, a descoberta reforça a necessidade de monitorar alterações em módulos e arquivos de configuração do PAM, especialmente em servidores expostos ou críticos. Mudanças inesperadas em diretórios como /etc/pam.d/, presença de módulos desconhecidos, alterações em fluxos de autenticação SSH e inconsistências em logs devem ser tratadas como sinais relevantes de possível comprometimento. Também é importante revisar permissões, integridade de arquivos sensíveis, histórico de autenticação, uso de contas privilegiadas e eventos relacionados ao OpenSSH. Em ambientes corporativos, controles como gestão rigorosa de acesso administrativo, hardening de servidores Linux, auditoria de integridade e monitoramento centralizado de logs podem ajudar a reduzir o impacto de backdoors desse tipo.

A Palo Alto Networks informou que hackers podem ter tentado explorar, ainda em 9 de abril de 2026, uma vulnerabilidade crítica recém-divulgada no PAN-OS, sistema operacional usado em seus firewalls e appliances de segurança de rede. A falha, identificada como CVE-2026-0300, recebeu pontuação CVSS de 9.3/8.7 e já foi associada a atividades limitadas de exploração em ambiente real. A vulnerabilidade é um buffer overflow no serviço User-ID Authentication Portal do PAN-OS. Na prática, esse tipo de falha ocorre quando um sistema grava mais dados do que o espaço de memória reservado consegue suportar, abrindo caminho para corrupção de memória e possível execução de código. Segundo a Palo Alto Networks, um invasor não autenticado poderia explorar o problema enviando pacotes especialmente criados para executar código arbitrário com privilégios de root. As correções para a CVE-2026-0300 estavam previstas para começar a ser disponibilizadas em 13 de maio de 2026. Até a aplicação dos patches, a empresa recomendou que os clientes restrinjam o acesso ao PAN-OS User-ID Authentication Portal apenas a zonas confiáveis ou desativem completamente o recurso caso ele não esteja em uso. Como medida adicional de mitigação, a Palo Alto Networks orientou as organizações a desativarem Response Pages no Interface Management Profile para qualquer interface L3 que possa receber tráfego não confiável ou vindo da internet. Clientes que utilizam Advanced Threat Prevention também podem bloquear tentativas de exploração ativando o Threat ID 510019 a partir da versão 9097-10022 do conteúdo Applications and Threats. Em um comunicado publicado na quarta-feira, a empresa afirmou estar ciente de exploração limitada da falha. A atividade está sendo rastreada como CL-STA-1132, um cluster de ameaça suspeito de ligação estatal, mas ainda sem origem atribuída publicamente. De acordo com a Unit 42, equipe de inteligência de ameaças da Palo Alto Networks, os invasores exploraram a CVE-2026-0300 para obter execução remota de código não autenticada no PAN-OS. Após o sucesso da exploração, os responsáveis pela atividade conseguiram injetar shellcode em um processo worker do nginx. A análise aponta que as primeiras tentativas malsucedidas de exploração contra um dispositivo PAN-OS foram observadas em 9 de abril de 2026. Cerca de uma semana depois, os hackers conseguiram alcançar execução remota de código contra o appliance e realizar a injeção de shellcode, indicando uma evolução na exploração ao longo do tempo. Após obter acesso inicial, os invasores executaram ações para reduzir rastros da atividade. Entre os procedimentos observados estavam a limpeza de mensagens de crash do kernel, a exclusão de entradas e registros de falhas do nginx e a remoção de arquivos de core dump gerados por crashes. Esse comportamento sugere uma preocupação operacional em dificultar a análise forense e atrasar a detecção. As atividades pós-exploração incluíram enumeração de Active Directory, uma etapa comum em invasões mais amplas, usada para mapear usuários, grupos, permissões, sistemas e possíveis caminhos de movimentação lateral. Em 29 de abril de 2026, os invasores também implantaram payloads adicionais em um segundo dispositivo, incluindo EarthWorm e ReverseSocks5. Essas ferramentas são associadas a túneis, proxies e comunicação reversa, recursos frequentemente usados para manter acesso, redirecionar tráfego e viabilizar movimentação dentro de redes comprometidas. EarthWorm e ReverseSocks5 já foram observadas anteriormente em operações de diferentes grupos hackers ligados à China, embora a Palo Alto Networks não tenha atribuído publicamente a campanha CL-STA-1132 a um país ou grupo específico. A Unit 42 destacou que, nos últimos cinco anos, hackers envolvidos em espionagem cibernética patrocinada por Estados têm direcionado cada vez mais seus esforços contra ativos de borda de rede. Esse conjunto inclui firewalls, roteadores, dispositivos IoT, hipervisores e soluções de VPN, justamente porque esses sistemas costumam ter privilégios elevados e, muitas vezes, menos visibilidade de segurança do que endpoints tradicionais. Esse foco em dispositivos de borda cria um desafio importante para equipes de segurança. Diferentemente de estações de trabalho e servidores, que normalmente contam com agentes de EDR, telemetria detalhada e controles de monitoramento mais consolidados, appliances de rede podem ter registros limitados, baixa cobertura de detecção e menor frequência de análise operacional. Outro ponto relevante na campanha é o uso de ferramentas open source em vez de malware proprietário. Segundo a Unit 42, essa escolha ajuda os invasores a reduzir a eficácia de detecções baseadas em assinatura e facilita a integração das ferramentas ao ambiente comprometido. Em outras palavras, o uso de ferramentas conhecidas e disponíveis publicamente pode dificultar a separação entre atividade administrativa legítima e comportamento malicioso. A empresa também observou que os operadores da campanha adotaram um ritmo operacional disciplinado, com sessões interativas intermitentes ao longo de várias semanas. Esse padrão de atuação, menos ruidoso e mais espaçado, pode permanecer abaixo dos limites comportamentais usados por muitos sistemas automatizados de alerta. Para organizações que utilizam PAN-OS, a prioridade deve ser revisar a exposição do User-ID Authentication Portal, validar se interfaces L3 estão recebendo tráfego não confiável, aplicar as mitigações recomendadas e acompanhar a liberação dos patches. Também é importante revisar logs disponíveis, indicadores de crash, registros do nginx, sinais de alteração em dispositivos de borda e evidências de enumeração interna, especialmente em ambientes integrados ao Active Directory.

Uma nova vulnerabilidade zero-day no Linux, chamada Dirty Frag, permite que invasores locais elevem privilégios e obtenham acesso root em grande parte das principais distribuições Linux. A falha foi divulgada pelo pesquisador Hyunwoo Kim, que também publicou uma prova de conceito do exploit após a quebra do embargo de divulgação pública. Segundo Kim, a vulnerabilidade foi introduzida há cerca de nove anos no kernel Linux, mais especificamente na interface de algoritmo criptográfico algif_aead. A exploração permite que um usuário local modifique arquivos protegidos do sistema diretamente na memória, sem autorização, e alcance privilégios administrativos com um único comando. O Dirty Frag funciona por meio do encadeamento de duas falhas distintas no kernel: a vulnerabilidade xfrm-ESP Page-Cache Write e a vulnerabilidade RxRPC Page-Cache Write. Juntas, elas permitem alterações não autorizadas em arquivos protegidos carregados em cache, abrindo caminho para a escalada de privilégios. A falha pertence à mesma classe de vulnerabilidades de Dirty Pipe e Copy Fail, ambas também associadas à manipulação indevida de dados em cache de páginas do kernel. No entanto, o Dirty Frag explora o campo de fragmento de uma estrutura de dados diferente do kernel, ampliando a superfície técnica desse tipo de problema. De acordo com Kim, assim como ocorreu com a vulnerabilidade Copy Fail, o Dirty Frag permite escalada imediata de privilégios para root em grandes distribuições Linux e também depende do encadeamento de duas vulnerabilidades separadas. O pesquisador destacou que a falha é um bug lógico determinístico, ou seja, não depende de uma janela de tempo específica para funcionar. Essa característica torna o Dirty Frag particularmente relevante do ponto de vista defensivo. Como a exploração não exige uma condição de corrida, o exploit não depende de precisão temporal para ter sucesso. Além disso, segundo o pesquisador, o kernel não entra em pânico quando a tentativa falha, e a taxa de sucesso é considerada muito alta. Até o momento descrito na divulgação, a vulnerabilidade ainda não havia recebido um identificador CVE para identificação. Também não havia patches disponíveis para várias distribuições afetadas, incluindo Ubuntu, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, openSUSE Tumbleweed e Fedora. A documentação completa e a prova de conceito foram publicadas após a quebra do embargo em 7 de maio de 2026. Segundo Kim, um terceiro não relacionado publicou o exploit de forma independente, antecipando a divulgação pública. Após consulta aos mantenedores por meio da lista linux-distros@vs.openwall.org, o pesquisador afirmou que a publicação do documento foi feita a pedido dos responsáveis pela coordenação. Como medida temporária de mitigação, usuários Linux podem remover os módulos vulneráveis esp4, esp6 e rxrpc do kernel. No entanto, essa ação pode afetar funcionalidades importantes, já que a desativação desses componentes pode interromper VPNs IPsec e sistemas de arquivos distribuídos AFS. O comando indicado para mitigação cria uma configuração em /etc/modprobe.d/dirtyfrag.conf para impedir o carregamento dos módulos esp4, esp6 e rxrpc, além de tentar removê-los da sessão atual. A aplicação dessa medida deve ser avaliada com cautela por administradores, especialmente em ambientes corporativos que dependem de conectividade VPN ou recursos distribuídos de rede. A divulgação do Dirty Frag ocorre enquanto mantenedores de distribuições Linux ainda trabalham na distribuição de correções para a Copy Fail, outra falha de escalada de privilégios para root que já estaria sendo explorada ativamente em ataques. A CISA adicionou a Copy Fail ao catálogo Known Exploited Vulnerabilities, conhecido como KEV, e determinou que agências federais dos Estados Unidos protejam seus dispositivos Linux até 15 de maio. Na ocasião, a agência norte-americana alertou que esse tipo de vulnerabilidade é um vetor frequente usado por hackers e representa riscos significativos para ambientes federais. A recomendação foi aplicar as mitigações conforme orientação dos fornecedores, seguir as diretrizes aplicáveis para serviços em nuvem ou interromper o uso do produto caso não haja mitigação disponível. O caso também se soma a outra falha corrigida em abril pelas distribuições Linux: a Pack2TheRoot, uma vulnerabilidade de escalada de privilégios encontrada no daemon PackageKit após permanecer cerca de uma década presente no sistema. A sequência de descobertas mostra como bugs antigos em componentes fundamentais do ecossistema Linux ainda podem gerar impacto relevante quando explorados em ambientes modernos.