Os responsáveis pela campanha GhostAction ampliaram suas técnicas de ataque à cadeia de suprimentos de software, passando a utilizar phishing contra desenvolvedores e um malware para roubo de credenciais disfarçado de arquivo de fonte. A nova etapa da operação foi identificada em 94 repositórios GitHub comprometidos, segundo investigação da plataforma de inteligência de ameaças OpenSourceMalware. Anteriormente, os invasores exploravam arquivos de automação do GitHub Actions para extrair informações sensíveis de projetos comprometidos. A evolução da campanha ocorre após o GitHub implementar medidas para impedir a execução dos workflows maliciosos. A investigação identificou o registro do domínio my-github[.]com em 9 de outubro de 2026, associado ao endereço IP 193.32.204[.]199, anteriormente utilizado para receber informações extraídas pelos ataques. O domínio apresenta um padrão semelhante ao my-gitlab[.]com, registrado 17 dias antes. Entretanto, segundo o pesquisador Paul McCarty, não existem evidências suficientes para associar os dois endereços ao mesmo grupo, pois utilizam registradores, configurações DNS e infraestruturas diferentes. Phishing permite roubar contas e permissões do GitHub No mesmo dia do registro, o domínio my-github[.]com foi utilizado em uma campanha de phishing direcionada a um mantenedor de projeto de código aberto. A mensagem, enviada pelo endereço noreply@my-github[.]com, simulava um alerta de segurança do GitHub sobre um suposto acesso suspeito à conta a partir de Moscou, na Rússia. O destinatário era orientado a acessar um link para proteger suas credenciais. Segundo a OpenSourceMalware, a página fraudulenta funcionava como um proxy reverso, permitindo capturar a senha e o código de autenticação de dois fatores (2FA) da vítima. Além disso, um JavaScript malicioso automatizava a autorização de um aplicativo OAuth do GitHub, utilizando o fluxo de autenticação por código de dispositivo. O mecanismo solicitava permissões repo, workflow e read:org, possibilitando aos invasores acessar e modificar repositórios, alterar arquivos do GitHub Actions e consultar informações sobre organizações. O código obtinha os identificadores necessários para a autorização, acessava a página de autenticação e enviava automaticamente a aprovação por meio da sessão autenticada da vítima. A técnica dispensava a necessidade de o usuário digitar o código de dispositivo ou aprovar conscientemente o aplicativo OAuth. O objetivo era obter um token de acesso reutilizável à API do GitHub e enviá-lo ao domínio malicioso pela porta TCP 8443. Com essas permissões, os operadores poderiam identificar repositórios acessíveis à conta comprometida e inserir novos workflows maliciosos no diretório .github/workflows/. Malware escondido em fonte compromete computadores de desenvolvedores A segunda etapa da campanha introduziu um mecanismo capaz de continuar operando nos computadores dos desenvolvedores mesmo após a remoção dos workflows maliciosos. Para isso, os invasores adicionaram três componentes aos repositórios comprometidos. O primeiro é um arquivo tasks.json do Visual Studio Code (VS Code), configurado com a opção runOn: folderOpen, que permite iniciar uma tarefa automaticamente quando a pasta do projeto é aberta no editor. O segundo é o arquivo public/fonts/fa-solid-400.woff2, aparentemente uma fonte utilizada pela aplicação, mas que contém um malware especializado no roubo de credenciais. O nome do arquivo é o mesmo utilizado na campanha Fake Font/PolinRider, associada a operadores norte-coreanos e documentada em janeiro de 2026. Essa semelhança, porém, não estabelece uma atribuição da GhostAction aos mesmos responsáveis. O malware procura informações sensíveis, incluindo: Chaves de acesso da AWS. Tokens de autenticação do PyPI e npm. Credenciais de login do GitHub. Credenciais de clusters Kubernetes. Chaves privadas SSH. Credenciais de serviços de IA, incluindo Anthropic Claude e Google Gemini. Quando executado pelo VS Code, o programa também instala uma tarefa cron para executar código fornecido pelos invasores a cada cinco minutos, estabelecendo um mecanismo de persistência. As informações coletadas são transmitidas por HTTP sem criptografia para o servidor controlado pelos atacantes, utilizando a porta 8080. O terceiro componente consiste em um segundo workflow do GitHub Actions, utilizado como alternativa caso o malware instalado no computador não seja executado. Esse workflow amplia os formatos de credenciais procurados e pode enviar os dados coletados para um GitHub Gist secreto caso a transmissão HTTP falhe. Os arquivos maliciosos foram identificados com nomes como lint.yml, ci-check.yml, build-check.yml, repo-health.yml, audit.yml, code-review.yml, test-suite.yml e cache-cleanup.yml. Ataque alcança 66 proprietários de repositórios A OpenSourceMalware identificou 94 repositórios comprometidos pertencentes a 66 proprietários diferentes. Desse total, 15 repositórios foram excluídos, renomeados ou tornados privados. Entre os 79 restantes, 65 não recebiam atualizações havia mais de um ano, incluindo um projeto sem modificações há mais de nove anos. A análise também identificou uma mudança no comportamento dos invasores após as medidas adotadas pelo GitHub. Em 9 de outubro, a plataforma começou a impedir a execução dos workflows maliciosos. Como resultado, as tentativas observadas nos dias 10 e 12 de outubro não conseguiram extrair credenciais. Seis dias após o bloqueio, os operadores passaram a utilizar o mecanismo baseado no VS Code, que não depende da infraestrutura de execução do GitHub Actions. Embora não seja possível confirmar que a mudança foi causada diretamente pelas restrições, os pesquisadores destacam que a nova técnica desloca parte do ataque para os computadores dos desenvolvedores, fora do alcance dos controles aplicados aos workflows pela plataforma. Pesquisadores identificam falhas na operação Apesar da ampliação das técnicas utilizadas, a investigação encontrou limitações na implementação do malware. Segundo Jenn Gile, cofundadora da OpenSourceMalware, o filtro responsável por identificar variáveis de ambiente deixa de reconhecer grande parte das chaves de API. Além disso, a busca por arquivos no diretório pessoal do usuário pode exceder o tempo de execução e descartar informações coletadas. Outro problema é a utilização de um único endereço IP para atividades de phishing, exfiltração de dados e varreduras na internet, facilitando a identificação da infraestrutura e de possíveis infecções. A identidade dos responsáveis pela campanha permanece desconhecida. Para reduzir os riscos, a OpenSourceMalware recomenda que desenvolvedores afetados revoguem acessos e tokens do GitHub utilizando um dispositivo confiável, alterem senhas, auditem seus repositórios e substituam todas as credenciais potencialmente expostas. Também é importante notificar usuários que tenham clonado os projetos comprometidos, considerando que o malware pode ser executado localmente ao abrir os arquivos no VS Code.

Uma campanha maliciosa identificada como REF8801 utiliza uma falsa aceleradora de startups Web3 para distribuir malwares em sistemas Windows e macOS por meio de pacotes npm. A operação oferece créditos gratuitos para modelos de inteligência artificial, como Anthropic Claude e Google Gemini, além de ferramentas de programação e auditorias de segurança. Segundo os pesquisadores Jia Yu Chan e Daniel Stepanic, da Elastic Security Labs, os pacotes distribuem programas para roubo de informações e backdoors, além de modificar agentes de programação com IA para redirecionar suas comunicações a servidores controlados pelos invasores. A campanha utiliza a identidade da Apex Accelerator, uma suposta aceleradora de capital de risco voltada a startups e empreendedores do setor de criptomoedas. A investigação identificou dois pacotes npm maliciosos: @apexacc/cli: divulgado como Apex Copilot CLI, um assistente de IA para fundadores de projetos Web3. @apexacc/audit: apresentado como Web3 Security Scanner, um servidor Model Context Protocol (MCP) com 18 ferramentas para análise de tokens, carteiras digitais e contratos inteligentes. Ambos foram publicados pelo usuário npm "apexaccelerator" e associados à conta GitHub "apexaccs" e à organização Apex Foundation. Os pacotes e seus repositórios já não estão acessíveis. Embora a identidade dos responsáveis permaneça desconhecida, a Elastic identificou comentários em russo no histórico do código-fonte. Os indícios, entretanto, não permitem determinar a origem dos operadores. Campanha utiliza investimentos e eventos para conquistar vítimas A operação apresenta indícios de atividade desde março de 2026. Registros do Internet Archive mostram que a Apex Foundation anunciava investimentos de US$ 235 mil, subsídios e conexões com fundos de venture capital, investidores-anjo e empresas de private equity. A infraestrutura da organização foi associada aos domínios apexaccs[.]org e apexfdn[.]xyz, identificados em registros analisados pela Socket desde abril. Publicações na plataforma X mostram que os responsáveis abordavam desenvolvedores de carteiras de criptomoedas e ferramentas de inteligência de mercado, oferecendo investimentos condicionados à execução de ferramentas de avaliação. Para aumentar sua credibilidade, o grupo também explorava sua presença em eventos como o TOKEN2049, em Singapura, e outros encontros presenciais. A campanha já havia sido parcialmente documentada pela SafeDep em julho de 2026, quando três pacotes npm relacionados à operação foram identificados distribuindo o Atomic Stealer (AMOS), malware especializado no roubo de informações em dispositivos macOS: @apexfdn/apex @copilot-mcp/apex @apexfdn/copilot-mcp Pacotes distribuem malwares diferentes para Windows e macOS Após a instalação, os pacotes não entregam as funcionalidades prometidas. O @apexacc/audit produz resultados de segurança fabricados, enquanto o @apexacc/cli apresenta avaliações sem fundamentação, inclusive de projetos fictícios. Na prática, ambos iniciam cadeias de infecção específicas para cada sistema operacional. A comunicação começa com uma requisição HTTP POST ao endereço vrf.apexaccs[.]org/api/v1/vrf, identificando o ambiente como Windows ou macOS. No Windows, o ataque utiliza comandos PowerShell codificados em Base64 para baixar scripts adicionais e executar o arquivo malicioso "bludness.exe". O executável, desenvolvido com PyInstaller, verifica privilégios administrativos e tenta contornar o Controle de Conta de Usuário (UAC) por meio do método ucmDebugObjectMethod(), da ferramenta UACME. As etapas seguintes utilizam outro executável PyInstaller e um carregador desenvolvido em Golang, que modifica componentes como Antimalware Scan Interface (AMSI), Event Tracing for Windows (ETW) e ntdll.dll para dificultar a detecção por soluções de segurança. O malware final coleta informações do sistema, processos ativos, conteúdo da área de transferência, redes Wi-Fi, capturas de tela e dados armazenados em carteiras de criptomoedas, extensões, mensageiros, aplicativos de acesso remoto, clientes VPN, FTP e plataformas de jogos. Também compromete informações dos navegadores Google Chrome, Microsoft Edge, Mozilla Firefox e Yandex. A ameaça consegue contornar proteções App-Bound Encryption (ABE) do Chrome para extrair senhas, cookies de sessão, histórico de navegação e outros dados. As informações roubadas são enviadas aos invasores pelo Telegram. No macOS, a infecção começa com o download de um script Bash que recupera um arquivo compactado do domínio verify.apexfdn[.]xyz. O pacote contém um instalador do backdoor CloudSyncD, que apresenta uma falsa solicitação de autorização para capturar a senha do usuário. A credencial é utilizada para executar componentes maliciosos com privilégios elevados por meio do sudo. O CloudSyncD coleta informações de hardware e sistema operacional e estabelece comunicação com o servidor ccmihr[.]com, permitindo receber comandos e executar novos payloads. O malware foi documentado pela Jamf Threat Labs em setembro de 2026, após ser identificado em campanhas que utilizavam falsos instaladores do Zoom. A análise destacou o uso de técnicas nativas do macOS, proteção de strings e mecanismos de execução que procuram reduzir a gravação de arquivos maliciosos no disco. Agentes de inteligência artificial também são comprometidos Além da instalação de malwares, a campanha apresenta uma capacidade adicional: interceptar e redirecionar o tráfego de modelos de linguagem utilizados por agentes de IA. Os pacotes conseguem modificar configurações de agentes para redirecionar requisições destinadas ao OpenRouter para uma API controlada pelos invasores. Também registram um servidor MCP malicioso no ambiente da vítima. Segundo a Elastic Security Labs, essas alterações permitem acessar prompts, históricos de conversas, trechos de código e resultados produzidos pelas ferramentas integradas aos agentes. O servidor MCP controlado pelos atacantes também pode fornecer instruções incorporadas aos prompts, além de nomes, descrições e parâmetros de ferramentas que influenciam as decisões do modelo. Dessa forma, os responsáveis pela campanha conseguem não apenas visualizar informações transmitidas pelos agentes, mas também interferir em suas ações posteriores. A investigação aponta uma operação que combina engenharia social, distribuição de malwares por pacotes npm e manipulação de integrações de inteligência artificial, tendo como principais alvos desenvolvedores e empresas do ecossistema Web3.

Um tribunal dos Estados Unidos determinou, nesta segunda-feira, a manutenção da prisão de Abdulrahman Alfozan, ex-engenheiro da OpenAI acusado de instalar um dispositivo de gravação clandestino em uma sala de reuniões executivas da empresa, em São Francisco. O objetivo, segundo os promotores, seria interceptar conversas confidenciais e obter informações sensíveis. Documentos judiciais apresentados no domingo revelaram que Alfozan, cidadão saudita de 35 anos, manteve comunicações frequentes pelo WhatsApp com um integrante da família real da Arábia Saudita ao longo de 2025 e 2026. O contato mais recente teria ocorrido em 5 de outubro de 2026, quatro dias antes de sua prisão. Segundo a acusação, o integrante da família real tentou recrutar o engenheiro para uma iniciativa de inteligência artificial na Arábia Saudita. Em maio de 2026, teria enviado a mensagem: "A Arábia Saudita precisa mais de você do que os EUA!", recebendo como resposta "100", interpretada pelos investigadores como concordância. O contato também teria perguntado repetidamente quando Alfozan deixaria a OpenAI. O engenheiro respondeu que pretendia permanecer na empresa até adquirir o direito às suas ações. Alfozan ingressou na OpenAI por volta de julho de 2025, com salário-base anual de US$ 385 mil. De acordo com o Departamento de Justiça dos Estados Unidos (DoJ), ele teria instalado um dispositivo de gravação de áudio discretamente conectado à porta USB localizada na parte traseira de uma televisão da sala de reuniões executivas. O equipamento teria sido modificado para impedir a transferência de dados entre o dispositivo e a televisão. As gravações eram armazenadas em um cartão microSD com conteúdo criptografado, dificultando o acesso não autorizado aos arquivos. A investigação também identificou que Alfozan utilizou a conta pessoal do ChatGPT de sua esposa para pesquisar como construir um gravador de áudio contínuo capaz de capturar sons de um microfone e armazenar arquivos WAV compactados em um cartão SD. Antes da instalação, o acusado teria utilizado um agente de produtividade da OpenAI para descobrir quais salas eram frequentadas pela liderança e pelos executivos da empresa, incluindo ambientes utilizados em reuniões com parceiros externos. Ele também teria passado períodos consideráveis próximo à sala onde posteriormente instalou o equipamento. O ex-engenheiro foi acusado de utilizar ou tentar utilizar um dispositivo eletrônico ou mecânico para interceptar comunicações orais. Caso seja condenado, poderá receber pena máxima de cinco anos de prisão. Risco de fuga e viagem planejada à Arábia Saudita Os promotores argumentaram que Alfozan apresentava risco de fuga devido aos seus recursos financeiros e aos possíveis contatos com representantes de um governo estrangeiro sem tratado de extradição com os Estados Unidos. A investigação revelou que ele havia planejado viajar para Riad, capital saudita, em 12 de outubro de 2026, acompanhado da esposa e do filho, utilizando passagens apenas de ida. Embora tenha sido preso três dias antes da viagem, sua esposa e seu filho teriam deixado os Estados Unidos sem ele. Na véspera da partida, a mulher informou ao FBI que seu visto americano estava expirando e que pretendia retornar permanentemente à Arábia Saudita com a criança. Os promotores sustentam que o acusado desenvolveu dispositivos personalizados e criptografados para registrar secretamente reuniões envolvendo executivos da OpenAI, parceiros comerciais de alto nível e autoridades governamentais. Investigação identifica novos dispositivos e registros digitais Durante buscas na residência de Alfozan e uma análise preliminar de seus equipamentos eletrônicos, incluindo seu iPhone, investigadores encontraram novas evidências relacionadas à suspeita de espionagem. Entre os materiais identificados estavam componentes eletrônicos semelhantes aos utilizados nos dispositivos encontrados na OpenAI e em uma bolsa desaparecida do acusado. Fotografias registradas entre 22 e 28 de setembro de 2026 mostravam outro dispositivo de gravação oculto, além de imagens aparentemente relacionadas às conexões de televisores e outros equipamentos eletrônicos em diferentes instalações da OpenAI. Entre os locais fotografados estava uma segunda sala de conferências utilizada para reuniões confidenciais. Os investigadores também recuperaram uma anotação excluída do celular, datada de setembro, contendo links para dispositivos de gravação, incluindo produtos da Seeed Studio, fabricante de equipamentos encontrados tanto nos escritórios da OpenAI quanto na residência do acusado. O histórico de navegação revelou ainda que Alfozan acessou, em 4 de outubro de 2026, uma pasta chamada Saudi Gov Docs. Entre 6 de julho e 21 de setembro de 2026, ele também teria utilizado um agente de produtividade da OpenAI para consultar informações sobre compromissos comerciais e governamentais relacionados à Arábia Saudita, incluindo atividades do Ministério das Comunicações e Tecnologia da Informação saudita (MCIT). Possível motivação permanece sob investigação Segundo os promotores, as evidências sugerem que Alfozan utilizou seus conhecimentos de engenharia para desenvolver dispositivos sofisticados de gravação que pretendia levar à Arábia Saudita. As autoridades investigam se o objetivo era obter vantagens comerciais pessoais, fornecer informações a um governo estrangeiro ou combinar ambas as finalidades. Até o momento, não há confirmação de que informações confidenciais tenham sido efetivamente transferidas ao governo saudita, nem de que os contatos com a família real estivessem diretamente envolvidos na suposta instalação dos dispositivos. A investigação permanece em andamento. A acusação considera que a conduta representa riscos à proteção de informações estratégicas do setor tecnológico e potencialmente à segurança nacional dos Estados Unidos.

A Siemens corrigiu uma vulnerabilidade de alta gravidade no Siemens Software Center que estava sendo explorada em ataques ClickFix para distribuir um trojan de acesso remoto (RAT). A falha permite a execução de código malicioso por meio da técnica de DLL sideloading, que explora o carregamento de bibliotecas DLL por aplicações legítimas. Identificada como CVE-2026-110936, a vulnerabilidade recebeu pontuação 8,4 no CVSS v4.0. O problema ocorre porque o software carrega bibliotecas de vínculo dinâmico (DLLs) a partir de caminhos de pesquisa não controlados, permitindo que um invasor local autenticado insira arquivos especialmente preparados para executar código com os mesmos privilégios da aplicação. A correção foi disponibilizada na versão 4.0.9.8 do Siemens Software Center. A descoberta foi atribuída ao pesquisador Jose Oregon, da Huntress Labs. Em um alerta separado, a Siemens explicou que os invasores utilizaram uma cópia legítima e assinada digitalmente do Siemens Software Center, posicionando uma DLL maliciosa chamada archive.dll no mesmo diretório do executável. Segundo a empresa, a versão 3.5.8.7, que era a mais recente na época dos ataques, carregava arquivos auxiliares de sua própria pasta sem verificar sua integridade. Essa característica permitiu que os hackers utilizassem o programa confiável como intermediário para executar código malicioso. A cadeia de ataque identificada envolve o uso de msiexec.exe para iniciar o instalador AllMyBasic.msi, responsável por executar o SiemensSoftwareCenter.exe. A atividade foi associada à plataforma ClickFix chamada Romulus, recentemente analisada pela Forescout por sua utilização na distribuição do Legion Loader e de outros malwares. De acordo com a Huntress, algumas dessas campanhas também utilizaram GPTs personalizados maliciosos no ChatGPT para direcionar vítimas a endereços fraudulentos. Nessas páginas, os usuários encontravam instruções ClickFix que os induziam a copiar e executar comandos no próprio computador. Quando executados, os comandos acionavam scripts PowerShell para baixar um instalador MSI. O arquivo explorava a técnica de DLL sideloading para instalar um trojan de acesso remoto, permitindo aos invasores controlar o sistema comprometido. A Siemens divulgou três indicadores de comprometimento (IoCs) associados à campanha: 96.62.218[.]59 — hospedagem de payloads e comunicação de comando e controle (C2). wizardexpensive[.]com — hospedagem de payloads e comunicação C2. 2.27.248[.]127 — canal de distribuição do instalador AllMyBasic.msi. Para reduzir os riscos, a Siemens recomenda atualizar o Software Center para a versão 4.0.9.8 ou posterior e iniciar a aplicação para aplicar a atualização. As organizações também devem bloquear os endereços IP e domínios maliciosos identificados, além de investigar execuções de SiemensSoftwareCenter.exe a partir do diretório AppData\Local\Programs, especialmente quando o processo for iniciado por msiexec.exe. A campanha combina engenharia social, abuso de software legítimo e execução de DLLs maliciosas, utilizando aplicações assinadas digitalmente para facilitar a instalação de ferramentas de acesso remoto.

Uma vulnerabilidade no software Wi-Fi da Broadcom permite que invasores executem códigos com privilégios de root em roteadores e pontos de acesso sem conhecer a senha da rede ou realizar qualquer procedimento de autenticação. A falha foi divulgada em 16 de outubro pelo pesquisador de segurança Quentin Kaiser e pode afetar milhões de dispositivos em todo o mundo. O ataque exige apenas que o invasor esteja dentro do alcance do sinal Wi-Fi do equipamento. Durante os testes, Kaiser demonstrou a exploração da vulnerabilidade em roteadores fornecidos por operadoras de internet da Bélgica, conseguindo extrair senhas de redes sem fio e estabelecer acesso remoto aos dispositivos. Segundo o pesquisador, a vulnerabilidade ainda não possui identificação CVE e nenhuma correção foi disponibilizada aos roteadores afetados. Também não há registros conhecidos de exploração em ataques reais. Falha no WPS permite execução remota de código A vulnerabilidade está na implementação do Wi-Fi Protected Setup (WPS) desenvolvida pela Broadcom. O recurso facilita a conexão de dispositivos a redes sem fio sem exigir a digitação manual da senha. O problema ocorre no processamento e na remontagem de mensagens WPS fragmentadas. Ao transmitir mensagens especialmente manipuladas, um invasor dentro do alcance da rede consegue provocar corrupção de memória no roteador. A partir dessa condição, Kaiser desenvolveu duas técnicas de exploração: uma para extrair informações da memória do equipamento e outra para executar códigos arbitrários com privilégios administrativos. Em um roteador Askey TCG3000, utilizado pela Orange Belgium, o pesquisador conseguiu recuperar a senha Wi-Fi (PSK) armazenada nas configurações do dispositivo, transmiti-la pelo sinal sem fio e posteriormente conectar-se à rede. Já no BBOX3V+, fabricado pela Sagemcom e distribuído pela Proximus, a exploração permitiu estabelecer uma reverse shell, oferecendo acesso remoto à linha de comando do roteador. Nesse segundo cenário, a comunicação ocorreu diretamente por quadros Wi-Fi, dispensando servidores externos para controlar o dispositivo comprometido. Ambos os ataques foram realizados sem autenticação e, segundo Kaiser, podem funcionar a distâncias consideráveis, desde que o invasor permaneça dentro do alcance do sinal. Milhões de roteadores podem estar vulneráveis O código WPS da Broadcom está incorporado a roteadores e pontos de acesso comercializados por dezenas de fabricantes. Kaiser estima que milhões de equipamentos possam apresentar a vulnerabilidade. A investigação identificou duas famílias principais de chipsets afetados: BCM3380, BCM3383 e BCM33834: modelos antigos baseados no sistema operacional eCos, para os quais não existe uma correção funcional conhecida. BCM3390, BCM65xx e BCM68xx: modelos mais recentes baseados em Linux, que poderiam receber uma correção mediante a substituição do software responsável pelo gerenciamento Wi-Fi. Nos dispositivos antigos, o pesquisador classifica o problema como forever day, expressão utilizada para vulnerabilidades que provavelmente permanecerão sem correção durante toda a vida útil dos equipamentos. Na Bélgica, a exploração foi confirmada em roteadores de três das quatro principais operadoras: Proximus, Orange Belgium e VOO. A Telenet também pode estar exposta, mas seus equipamentos não foram testados. Uma relação mais ampla publicada pelo pesquisador inclui dispositivos de fabricantes como Cisco, Huawei e ARRIS. Entretanto, a lista reúne equipamentos com vulnerabilidade confirmada e outros classificados apenas como potencialmente afetados por verificações automatizadas. As estimativas indicam centenas de milhares de roteadores vulneráveis por operadora belga, embora Kaiser ressalte que esses números são aproximados. Broadcom conhece o problema desde 2018, segundo pesquisador A origem da vulnerabilidade remonta a pelo menos 2010, quando o código afetado já estava presente no software da Broadcom. De acordo com Kaiser, a fabricante disponibilizou uma correção incompleta em 2018 e posteriormente orientou seus clientes a migrar para outro pacote de software Wi-Fi, chamado hostapd. Nos chipsets antigos baseados em eCos, entretanto, nenhuma solução funcional teria sido disponibilizada. O pesquisador afirma que a Broadcom reconheceu conhecer a vulnerabilidade desde 2018, inclusive por notificações anteriores, mas não publicou um comunicado de segurança nem registrou um identificador CVE. Kaiser acredita que essa ausência de divulgação contribuiu para que diversos fabricantes de roteadores não corrigissem o problema. O caso também foi encaminhado ao CERT Coordination Center, mas acabou encerrado no mesmo dia. Segundo o pesquisador, isso ocorreu porque a Broadcom possui autoridade para atribuir identificadores CVE aos próprios produtos e não realizou o registro. Como identificar dispositivos vulneráveis Atualmente, não existe uma atualização de segurança disponível para os equipamentos afetados nem uma configuração específica indicada pelo pesquisador capaz de impedir a exploração pelo sinal Wi-Fi. Para auxiliar na identificação dos dispositivos, Kaiser disponibilizou regras YARA que permitem localizar o código vulnerável em firmwares extraídos dos equipamentos. Também foi publicado um script capaz de analisar pontos de acesso Wi-Fi em funcionamento e indicar possíveis condições de vulnerabilidade. Essas ferramentas, entretanto, são destinadas à triagem. Um equipamento corrigido ainda pode apresentar correspondência com as regras, exigindo verificações adicionais antes de confirmar a exposição. Para dispositivos que não receberão atualizações, a substituição do hardware é considerada a alternativa prática. O pesquisador destaca que a vulnerabilidade pode ser particularmente útil em operações nas quais invasores se aproximam fisicamente das instalações de uma organização para comprometer redes sem fio. Esse tipo de abordagem já foi utilizado por hackers associados ao governo russo, que exploraram conexões Wi-Fi a partir de locais próximos às organizações atacadas.

O OpenCode confirmou que um invasor conseguiu acessar um sistema legado da empresa na noite de 16 de outubro de 2026, em um incidente que pode ter exposto chaves de API de serviços de inteligência artificial, incluindo OpenAI, Anthropic e Google, armazenadas por usuários do OpenCode Console. O Console é um serviço hospedado opcional do OpenCode que permite às equipes utilizar modelos de IA por meio de chaves de API vinculadas ao ambiente de trabalho. Dessa forma, os integrantes podem acessar os modelos sem visualizar diretamente as credenciais utilizadas nas requisições. Segundo a empresa, 1,4% dos usuários do OpenCode Console foram afetados, todos com provedores externos de inteligência artificial conectados. Os envolvidos receberam um e-mail na manhã de 17 de outubro, com o assunto "Action Required: Potential provider key breach", orientando a revogação e substituição das credenciais. Em publicação na rede social X, o OpenCode informou que usuários que não receberam a notificação não foram afetados pelo incidente. Invasão afeta credenciais armazenadas no Console A exposição potencial está restrita às chaves de API cadastradas diretamente no OpenCode Console. As versões de linha de comando e desktop do OpenCode armazenam localmente as credenciais em um banco de dados SQLite, sem enviá-las aos servidores da empresa. O cofundador Dax Raad esclareceu que o comprometimento envolve especificamente o OpenCode Console, e não o OpenCode como um todo. O principal risco está no funcionamento das chaves de API, que permitem autenticar requisições aos provedores de inteligência artificial. Caso uma credencial seja copiada, terceiros podem utilizá-la para consumir serviços e gerar cobranças na conta do proprietário até que ela seja revogada. Excluir a chave do Console não impede sua utilização externa. Da mesma forma, os limites de orçamento configurados na plataforma não controlam requisições realizadas diretamente contra os provedores. Por isso, o OpenCode orientou os usuários afetados a revogar as credenciais nos painéis da OpenAI, Anthropic ou Google, gerar novas chaves e atualizar aplicações e scripts que utilizavam as anteriores. A empresa também recomenda verificar os registros de consumo e faturamento desde pelo menos 16 de outubro, identificar possíveis requisições não autorizadas e configurar alertas ou limites de gastos diretamente nos provedores. Utilizar credenciais diferentes para cada ferramenta também facilita a identificação de usos indevidos. Usuários relatam cobranças não autorizadas Embora o OpenCode ainda não tenha confirmado a utilização indevida das credenciais, alguns usuários relataram prejuízos financeiros associados ao incidente. Segundo o Dealroom, Colin Parsons afirmou na rede social X que sua chave da OpenAI teria sido utilizada para gerar US$ 281 em cobranças, enquanto a credencial da Anthropic teria acumulado outros US$ 168. Outro usuário, Preston Zeller, relatou perdas de aproximadamente US$ 1.700. O Notebookcheck também publicou relatos de usuários do Reddit que identificaram cerca de US$ 400 em consumo não autorizado na Anthropic e aproximadamente € 200 em serviços do Google. Neste último caso, o projeto teria sido suspenso. Esses valores são baseados em declarações dos próprios usuários e não representam prejuízos confirmados oficialmente pelo OpenCode. Até o momento, a empresa afirma apenas que as credenciais podem ter sido expostas, sem confirmar se foram efetivamente copiadas ou utilizadas por invasores. OpenCode relaciona incidente a ataque de destilação de IA Em comunicado publicado em 17 de outubro, o OpenCode classificou o incidente como uma investigação em andamento e informou que estava trabalhando com OpenAI, Anthropic e Google para solucionar o problema. A empresa também afirmou que a invasão estaria relacionada a um ataque de destilação de modelos de inteligência artificial em larga escala, mas não explicou como essa atividade estaria conectada ao acesso não autorizado. A destilação, nesse contexto, envolve a coleta de grandes volumes de respostas de modelos de IA para treinar outros sistemas, potencialmente concorrentes. Em setembro, a Anthropic havia informado que organizações envolvidas nesse tipo de atividade utilizavam redes de contas falsas, cartões de crédito roubados, credenciais comprometidas e chaves de API coletadas indevidamente para acessar seus modelos. Além da destilação, credenciais roubadas podem ser comercializadas em mercados criminosos ou utilizadas para consumir recursos de IA às custas de terceiros. O OpenCode não identificou os responsáveis pela invasão, o sistema legado comprometido, o método de acesso ou a quantidade de chaves potencialmente expostas. Também não informou o número absoluto de usuários correspondente aos 1,4% afetados. Em 18 de outubro, Dax Raad afirmou que os sistemas da empresa continuavam sendo alvo de tentativas de ataque. Segundo o executivo, os invasores estavam tentando comprometer a infraestrutura continuamente havia aproximadamente 48 horas. Raad acrescentou que, como consequência dessas atividades, a empresa estava reforçando os mecanismos de segurança de seus sistemas.

A ConnectWise anunciou a desativação de sete identidades de aplicações e a suspensão de três serviços em nuvem após identificar acessos não autorizados a ambientes Microsoft 365 de clientes. As medidas foram implementadas em 17 de outubro de 2026, às 07h UTC, enquanto a empresa investiga o comprometimento de credenciais utilizadas por suas soluções de backup e gerenciamento. A companhia revogou certificados associados às conexões afetadas do ConnectWise Cloud Backup, anteriormente conhecido como SkyKick, impedindo novas autenticações. Os serviços SaaS Security e Cloud Management também foram temporariamente retirados de operação como medida preventiva. Segundo a ConnectWise, a desativação das conexões impede novas autenticações, mas não desfaz alterações realizadas anteriormente nos ambientes dos clientes. Tokens de acesso emitidos antes da revogação podem continuar válidos até expirarem, enquanto credenciais adicionais criadas pelos invasores exigem investigação e remoção específicas. A suspensão interrompeu os backups programados, o acesso aos arquivos armazenados e as funcionalidades de restauração. A empresa afirmou que os arquivos existentes permanecem criptografados, isolados e preservados, sem evidências de acesso ou comprometimento pelos invasores. O monitoramento e os alertas do SaaS Security também estão indisponíveis, assim como os recursos de gerenciamento de usuários e licenças do Cloud Management. ConnectWise investiga origem do comprometimento A ConnectWise informou que identificou o incidente em 14 de outubro de 2026, por meio de seus mecanismos de monitoramento de segurança, e iniciou procedimentos internos e externos de investigação e resposta. Após a implementação das medidas de contenção, a companhia não observou novas atividades maliciosas bem-sucedidas nos ambientes que monitora. Entretanto, ressaltou que não possui visibilidade direta sobre todos os ambientes Microsoft 365 de seus clientes. Ainda não está claro se alguma vulnerabilidade nos produtos contribuiu para o comprometimento. O mecanismo exato de exposição das credenciais permanece sob investigação. O ataque explorou a confiança concedida às aplicações ConnectWise pelos administradores dos ambientes Microsoft 365. Ao obter credenciais dessas aplicações, os invasores conseguiram solicitar tokens ao Microsoft Entra ID utilizando permissões previamente autorizadas, sem precisar roubar individualmente as senhas dos usuários. Dependendo dos privilégios existentes, esse acesso pode permitir a consulta a caixas de e-mail, documentos do SharePoint, mensagens do Teams e informações de diretório. A investigação também identificou técnicas para ampliar privilégios, incluindo a atribuição da função de Administrador Global a aplicações, a inclusão de novos segredos de cliente (client secrets) em ferramentas confiáveis e a criação de aplicações com permissões adicionais. Esses mecanismos podem estabelecer persistência nos ambientes comprometidos, permitindo que os hackers recuperem o acesso mesmo após a revogação da credencial originalmente explorada. Huntress identifica segunda onda de ataques contra 16 organizações A Huntress identificou uma segunda onda de tentativas direcionadas em 15 de outubro, originadas do endereço IP 144.172.64[.]128. A atividade envolveu 16 ambientes Microsoft Entra associados a organizações dos setores de políticas públicas, segurança nacional, comércio e minerais críticos. Segundo Jon Semon, analista principal de operações de segurança da Huntress, as últimas autenticações maliciosas observadas a partir do endereço original ocorreram às 08h45 UTC de 15 de outubro. Atividades manuais direcionadas continuaram até aproximadamente 14h20 UTC. A primeira etapa da nova onda ocorreu entre 09h25min04s e 12h35min50s, com tentativas de obtenção de tokens do Microsoft Graph por meio da aplicação SkyKick. A segunda etapa, entre 13h54min39s e 14h20min24s, apresentou características de operação manual e direcionou tentativas de acesso ao Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Microsoft Entra e APIs de gerenciamento do Office 365. As tentativas contra esses 16 ambientes não tiveram sucesso, segundo a Huntress. A empresa também afirmou ter alta confiança de que os invasores direcionaram atividades contra aplicações ConnectWise Cloud Management integradas ao Exchange Online, Microsoft Teams e SharePoint. O abuso da aplicação do Teams foi confirmado em pelo menos um ambiente. Até o momento da análise, a Huntress não havia identificado novas atividades maliciosas desde 15 de outubro, mas ressaltou que não existem evidências de que a interrupção tenha sido provocada pela divulgação pública do incidente. Quase mil ambientes Microsoft Entra registraram atividade suspeita A Huntress identificou atividades de autenticação associadas ao endereço IP malicioso em quase mil ambientes Microsoft Entra, dos quais aproximadamente 300 registraram autenticações bem-sucedidas. Entretanto, autenticação bem-sucedida não significa necessariamente comprometimento efetivo. Em determinados ambientes, a ausência de um principal de serviço (service principal) impediu que os invasores obtivessem acesso aos recursos pretendidos. Os números representam uma ampliação da investigação em relação aos 173 ambientes com autenticações não autorizadas confirmadas inicialmente. A ConnectWise também divulgou dois novos endereços IP associados à atividade, identificados por meio do monitoramento de segurança de parceiros e clientes: 144.172.64[.]128 — endereço originalmente associado aos ataques. 144.172.64[.]99 — novo indicador identificado. 144.172.64[.]60 — novo indicador identificado. Sete identidades de aplicações foram desativadas A ConnectWise confirmou a desativação das seguintes identidades utilizadas por seus serviços: Aplicação Application ID ConnectWise Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83 Cloud Management – MS Teams 24205314-2b89-4e07-a2a4-579e898a5640 Cloud Management – Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519 Cloud Management – MS Graph 0de14c77-b9b0-4137-9360-34878a929827 Cloud Management – Partner Center 412dcf96-176d-4b3a-a1b0-4981ad66971e Cloud Management – SharePoint Online b2b55f5b-7758-4719-8d8f-88ae172e6bdb A empresa recomenda que parceiros e clientes mantenham as conexões afetadas desabilitadas até novas orientações. Recomendações para administradores Microsoft 365 A Huntress orienta os provedores de serviços gerenciados (MSPs) a investigar tanto seus próprios ambientes Microsoft 365 quanto os de todos os clientes administrados, incluindo aqueles com conexões antigas ou inativas do SkyKick. A análise deve abranger registros de autenticação desde 13 de outubro de 2026, com atenção aos três endereços IP associados à campanha. Os registros de autenticação e auditoria devem ser preservados antes da execução de medidas de contenção. Também é recomendado revisar credenciais de aplicações, relações de confiança federadas, permissões administrativas, proprietários de aplicações, concessões OAuth e alterações recentes em políticas de segurança. Os administradores devem procurar regras não autorizadas de encaminhamento de e-mails, modificações nas caixas de entrada, regras de transporte e acessos delegados a mensagens. Para reduzir o risco de persistência, a Huntress recomenda utilizar políticas de gerenciamento de aplicações que restrinjam a criação de segredos de cliente e limitem sua validade. A redução de usuários com funções Application Administrator e Cloud Application Administrator também dificulta a inclusão indevida de credenciais. Recursos como Conditional Access para identidades de carga de trabalho, que exigem licenciamento adicional, e Microsoft Entra ID Protection podem restringir origens de autenticação e identificar principais de serviço suspeitos. A ConnectWise mantém Cloud Backup, SaaS Security e Cloud Management suspensos enquanto realiza a remediação e validação de segurança. Ainda não foi informado um prazo para o restabelecimento dos serviços.

Uma campanha de ataques cibernéticos está explorando uma credencial comprometida do ConnectWise Cloud Backup, anteriormente conhecido como SkyKick, para obter acesso não autorizado a ambientes Microsoft 365 (M365) de clientes. A empresa de segurança Huntress confirmou autenticações indevidas em 173 ambientes de parceiros e clientes, enquanto a Microsoft classificou a atividade como um ataque ativo à cadeia de suprimentos. O ConnectWise Cloud Backup é um serviço de backup e recuperação em nuvem utilizado por provedores de serviços gerenciados (MSPs) para proteger dados do Microsoft 365 e Google Workspace. Para executar suas funções, a aplicação recebe permissões abrangentes sobre caixas de e-mail, OneDrive, SharePoint, Teams e informações de diretório. Segundo a Huntress, a credencial comprometida pode ser utilizada em todos os ambientes que concederam autorização à aplicação, ampliando o alcance potencial do incidente. Em 15 de outubro de 2026, entre 06h13 e 08h34 UTC, os invasores utilizaram o endereço IP 144.172.64[.]128 para obter tokens de acesso ao Microsoft Graph. As autenticações ocorreram em intervalos de poucos segundos, seguindo uma sequência ordenada de identificadores GUID, comportamento compatível com uma operação automatizada baseada em uma lista de alvos. A investigação, conduzida pelo pesquisador Jonathan Semon, identificou que os hackers utilizavam ferramentas próprias para autenticar na aplicação e herdar suas permissões existentes. Dessa forma, poderiam acessar mensagens, arquivos e informações de diretório disponíveis ao serviço de backup, sem precisar comprometer individualmente as contas dos usuários. A Huntress também associou o mesmo endereço IP a tentativas de password spraying contra quatro escritórios de advocacia nos dias 13 e 14 de outubro. Entretanto, não foram identificadas autenticações bem-sucedidas de usuários nessas tentativas. Invasores tentam ampliar privilégios e estabelecer persistência Em pelo menos um ambiente de parceiro, a Huntress identificou uma segunda aplicação da ConnectWise atribuindo a si mesma privilégios de Administrador Global e adicionando novas credenciais a aplicações confiáveis. A aplicação ConnectWise Cloud Management para Microsoft Teams, identificada pelo ID 24205314-2b89-4e07-a2a4-579e898a5640, assumiu a função de Global Administrator e executou um script Python, identificado pelo User-Agent Python-urllib/3.12. O script modificou duas aplicações existentes: uma ferramenta de gerenciamento de MSP e a própria plataforma Huntress Security Platform, adicionando novos segredos de cliente (client secrets) a ambas. Essa técnica permite ampliar o acesso para além da aplicação inicialmente comprometida. Como ferramentas de gerenciamento de MSPs frequentemente possuem permissões em ambientes de diversos clientes, credenciais adicionais podem abrir caminhos para outros sistemas e organizações. A Todyl confirmou atividade semelhante envolvendo autenticação não autorizada no Microsoft Graph por meio da aplicação ConnectWise Cloud Backup. Segundo Nicholas Koken, diretor de Engenharia de Detecção da Todyl, os invasores herdaram permissões de leitura e gravação de e-mails e anexos, acesso completo a caixas postais pelo Exchange Web Services, arquivos do OneDrive e SharePoint, conversas do Teams e funcionalidades de restauração de dados. A empresa alertou que revogar sessões de usuários não interrompe esse tipo de acesso. Desabilitar a aplicação impede a emissão de novos tokens naquele ambiente, mas os tokens já emitidos podem permanecer válidos por até 90 minutos. Microsoft confirma ataque ativo à cadeia de suprimentos A Microsoft confirmou que acompanha uma campanha ativa envolvendo o comprometimento da aplicação OAuth confiável do ConnectWise Cloud Backup, identificada pelo AppId 506e08f9-6e9a-4da4-942b-a099a03644ae. Segundo a empresa, os hackers provavelmente exploraram permissões previamente concedidas pelos clientes, incluindo privilégios elevados como Directory.ReadWrite.All, que permite modificar informações de diretório. Após as autenticações registradas em 15 de outubro, a Microsoft observou atividades de reconhecimento por meio da API Microsoft Graph e tentativas de adicionar credenciais aos principais de serviço (service principals) relacionados, com o objetivo de manter acesso direto aos ambientes comprometidos. A Huntress também identificou um possível padrão de seleção de alvos em ordem alfabética, com destaque para organizações cujos nomes começam pela letra A. Apesar disso, a empresa recomenda investigar todos os ambientes potencialmente expostos. ConnectWise suspende acesso ao Cloud Backup Em resposta ao incidente, a ConnectWise confirmou acessos não autorizados a identidades de aplicações em seu ambiente Cloud Backup e suspendeu o acesso da aplicação por tempo indeterminado, enquanto prosseguem as investigações e medidas de correção. A companhia informou que, até o momento, não encontrou evidências de comprometimento dos dados de backup de seus parceiros. Isso, entretanto, não elimina a possibilidade de acesso indevido a informações disponíveis nos ambientes Microsoft 365 por meio das permissões comprometidas. A empresa divulgou os identificadores das aplicações associadas à atividade: Aplicação Application ID ConnectWise Cloud Backup 506e08f9-6e9a-4da4-942b-a099a03644ae ConnectWise Cloud Management 2399d300-6fca-4e6a-a686-399fefe75b83 Cloud Management – MS Teams 24205314-2b89-4e07-a2a4-579e898a5640 Cloud Management – Exchange Online b78f6a77-d4e5-46fb-87e5-d1648bd02519 Cloud Management – MS Graph 0de14c77-b9b0-4137-9360-34878a929827 Cloud Management – Partner Center 412dcf96-176d-4b3a-a1b0-4981ad66971e Cloud Management – SharePoint Online b2b55f5b-7758-4719-8d8f-88ae172e6bdb Recomendações para identificar possíveis comprometimentos A ConnectWise e as empresas de segurança recomendam que administradores verifiquem os registros de autenticação no Microsoft Entra Admin Center. A investigação deve ser realizada em Monitoring → Sign-in logs → Service principal sign-ins, utilizando o identificador da aplicação ConnectWise Cloud Backup. A aba convencional de autenticações de usuários não apresenta os registros necessários. Entre as principais medidas recomendadas estão: Investigar autenticações originadas do IP 144.172.64[.]128 e de endereços desconhecidos fora dos intervalos esperados da Microsoft e Azure. Manter a aplicação desabilitada até a confirmação da substituição de todas as credenciais comprometidas. Habilitar os registros de atividade do Microsoft Graph. Auditar credenciais adicionadas às aplicações desde 13 de outubro de 2026. Verificar alterações de funções administrativas realizadas por aplicações ConnectWise ou SkyKick. Revisar concessões OAuth e modificações em principais de serviço. A Huntress ressalta que determinadas operações, como consultas de diretório pelo Microsoft Graph, podem não produzir registros de auditoria suficientes para comprovar o acesso. Por isso, a ausência de evidências nos logs não deve ser interpretada como garantia de que os dados não foram acessados. Outro ataque compromete infraestrutura de atualização da AOMEI Paralelamente, o Google Mandiant, o Google Threat Intelligence Group e o ManageEngine Threat Analysis Lab divulgaram uma campanha distinta contra a infraestrutura de atualização do AOMEI Backupper, software utilizado para backup, clonagem de discos e recuperação de desastres. A operação, atribuída ao grupo até então não documentado UNC7017, ocorreu entre abril e julho de 2026 e utilizou uma técnica de adulteração temporária da cadeia de suprimentos, denominada ephemeral supply chain tampering. Os invasores modificavam configurações nos servidores de atualização da AOMEI durante intervalos de apenas cinco a dez minutos, redirecionando o software para baixar arquivos ZIP maliciosos hospedados em servidores controlados pelos atacantes. Em seguida, restauravam as configurações legítimas. Os pacotes distribuíam o malware CROSSROAD, responsável por validar o ambiente e preparar a instalação de componentes adicionais. O código também estabelecia persistência por tarefas agendadas para executar o SHINYROAD, um backdoor modular que utiliza DLL sideloading para estabelecer comunicação clandestina com servidores de comando e controle. A campanha teria afetado organizações dos setores de tecnologia, telecomunicações, ensino superior e áreas relacionadas em países como Brasil, Estados Unidos, Austrália, Índia, Portugal, Espanha, Singapura, África do Sul, Paquistão, Suíça e Turquia. Diferentemente de comprometimentos tradicionais de servidores de atualização, a operação utilizava alterações de curta duração, dificultando a identificação de modificações maliciosas persistentes.

Um grupo de hackers suspeito de atuar em operações avançadas explorou uma vulnerabilidade no Fortinet FortiOS para instalar o PEERSTITCH, um malware até então desconhecido que opera diretamente na memória dos dispositivos. A ameaça modifica processos legítimos do sistema para contornar verificações de segurança em determinadas sessões VPN, dificultando sua identificação por ferramentas convencionais. A descoberta foi divulgada por pesquisadores da Unit 42, divisão de inteligência de ameaças da Palo Alto Networks, que identificaram a exploração da vulnerabilidade CVE-2025-61624, classificada com pontuação 5,4 na escala CVSS. A falha, do tipo path traversal, afeta o interpretador de comandos do FortiOS, FortiPAM, FortiProxy e FortiSwitchManager. Ela permite que invasores com privilégios elevados gravem ou excluam arquivos arbitrários utilizando argumentos especialmente preparados em comandos existentes. A Fortinet corrigiu a vulnerabilidade em abril de 2026. Segundo os pesquisadores Daniel Gott e Shawn Westfall, o PEERSTITCH não mantém arquivos binários persistentes no disco, não abre portas de escuta e não estabelece conexões externas próprias. Em vez disso, utiliza o tráfego gerado por processos legítimos do equipamento comprometido para realizar suas comunicações. Ataque começou com comprometimento do FortiManager A investigação está relacionada a uma invasão identificada em setembro de 2024 contra um provedor de serviços gerenciados de telecomunicações. A campanha, rastreada como CL-STA-0954, também conhecida como UNC5820, começou com a exploração da vulnerabilidade crítica FortiJump (CVE-2024-47575), presente no Fortinet FortiManager. Após comprometer o equipamento, os invasores extraíram um arquivo contendo configurações operacionais, materiais criptográficos e bancos de dados relacionados a mais de 500 firewalls FortiGate gerenciados. Entre as informações obtidas estavam números de série dos equipamentos, endereços IP públicos, mapas de topologia da rede, tabelas de roteamento, configurações de interfaces, bancos SQLite de gerenciamento centralizado, credenciais administrativas e SSL/VPN armazenadas em formato cifrado, além de certificados digitais e chaves privadas. Os dados foram utilizados para reconhecimento da infraestrutura, interceptação de tráfego, estabelecimento de acessos prolongados e criação de sessões SSL/VPN não autorizadas em firewalls de perímetro. Posteriormente, os invasores exploraram a CVE-2025-61624 para implantar o PEERSTITCH nos dispositivos comprometidos. Como funciona o malware PEERSTITCH O PEERSTITCH é um executável Linux ARM64 de 64 bits, desenvolvido em linguagem C. Sua instalação utiliza um auto-script responsável por baixar cinco componentes de um servidor externo localizado em 23.240.77[.]233:8085. Os arquivos incluem o script de preparação pM.js, o módulo JavaScript a.js (salvo como index.js), o módulo WebAssembly a.wasm (salvo como index.wasm), o orquestrador b.js (salvo como ipssem.js) e o injetor ARM64 dd (salvo como lldprx). Após um atraso programado, o orquestrador executa o injetor, que modifica diretamente a memória de dois processos essenciais do FortiOS: /bin/miglogd e /bin/iked. O malware identifica os processos em execução, analisa seus mapas de memória e utiliza a interface ptrace para se conectar a eles. Em seguida, interrompe temporariamente sua execução com PTRACE_INTERRUPT, aloca regiões de memória executáveis e injeta código malicioso, redirecionando o fluxo de execução. Essa técnica permite estabelecer um canal de comunicação oculto entre processos legítimos, sem depender de arquivos persistentes ou conexões de rede convencionais. Malware modifica validações de sessões VPN O principal diferencial técnico do PEERSTITCH está na manipulação do processamento de sessões VPN. O código injetado no processo miglogd procura dois marcadores específicos nos dados processados: a porta TCP 8550 e o endereço IP 169.254.0.1. Esses valores funcionam como identificadores internos para reconhecimento de padrões, não representando necessariamente uma porta aberta ou uma conexão de rede ativa. Quando identifica os marcadores, o código malicioso encaminha um token ou identificador de sessão ao processo iked, responsável por operações relacionadas às VPNs. O código injetado no iked procura esse identificador nas sessões VPN subsequentes. Quando encontra uma sessão marcada, modifica o fluxo de execução para ignorar determinadas validações de segurança normalmente aplicadas pelo FortiOS. Dessa forma, os invasores conseguem alterar o tratamento de sessões VPN específicas sem modificar diretamente os arquivos executáveis originais do sistema. Hackers também utilizaram shell reverso e técnicas antiforenses Além do PEERSTITCH, os responsáveis pela campanha estabeleceram um canal independente de comando e controle (C2), explorando o módulo nativo mod_md do Apache presente nos firewalls FortiGate para iniciar um shell reverso baseado em SSH. Os invasores também se passaram pela plataforma FortiManager para obter informações de outros firewalls gerenciados na rede comprometida. A Unit 42 identificou indícios de que outras vulnerabilidades, como CVE-2024-26009 e CVE-2024-26008, poderiam estar relacionadas à operação. Entretanto, essa hipótese não foi confirmada. A exploração dessas falhas exige que os dispositivos estejam cadastrados no FortiGate Cloud/FortiCloud SSO, condição que não estava presente nos equipamentos afetados. A investigação também documentou técnicas utilizadas para eliminar evidências da invasão, incluindo interrupção da geração de logs syslog, exclusão de registros de falhas, desativação de telemetria e remoção automática de contas administrativas não autorizadas e objetos de auto-script após sua execução. Segundo a Unit 42, a operação demonstra conhecimento aprofundado da arquitetura dos equipamentos Fortinet, dos componentes internos do FortiOS e dos protocolos utilizados no gerenciamento centralizado. O comprometimento do FortiManager permitiu aos invasores obter informações sobre centenas de firewalls e ampliar o alcance da operação para outras redes gerenciadas. A utilização do PEERSTITCH acrescentou uma camada de ocultação ao ataque, permitindo manipular processos diretamente na memória e manter mecanismos de acesso sem os artefatos normalmente associados à instalação de malware em disco.

O grupo hacker Silent Lynx foi associado a uma nova série de ataques cibernéticos contra organizações governamentais da Comunidade dos Estados Independentes (CEI), principalmente na Ásia Central. As operações, identificadas entre junho de 2025 e agosto de 2026, utilizam diferentes métodos de infecção, incluindo a exploração da vulnerabilidade CVE-2025-8088 no WinRAR, para instalar ferramentas de acesso remoto nos sistemas comprometidos. Segundo investigações da Cisco Talos e do Recorded Future Insikt Group, a campanha é rastreada como UAT-6275 e TAG-193. Os ataques empregam documentos maliciosos com macros, downloaders criados com PS2EXE, scripts PowerShell hospedados no GitHub e arquivos RAR especialmente preparados. O objetivo é instalar ferramentas de shell reverso desenvolvidas pelo grupo, como FoalShell, Chvost, Laplas e PickleShell, que permitem aos invasores executar comandos e interagir remotamente com os dispositivos infectados. De acordo com a pesquisadora Ashley Shen, as atividades estão concentradas em nove países: Cazaquistão, Quirguistão, Tadjiquistão, Turcomenistão, Uzbequistão, Armênia, Azerbaijão, Rússia e Belarus. Silent Lynx atua desde pelo menos 2020 O Silent Lynx foi documentado publicamente pela primeira vez pela Seqrite Labs no início de 2025, após ataques direcionados a embaixadas, escritórios de advocacia, bancos apoiados por governos e centros de pesquisa no Quirguistão e no Turcomenistão. Os pesquisadores avaliam que o grupo possui vínculos com o Cazaquistão e atua desde pelo menos 2020. Suas operações apresentam semelhanças com atividades atribuídas a outros grupos, incluindo YoroTrooper, também conhecido como Comrade Saiga, além de ShadowSilk, Cavalry Werewolf e Tomiris. Existe a suspeita de que UAT-6275 e YoroTrooper integrem um mesmo conjunto mais amplo de operações. Entretanto, até o momento, não foram identificados indicadores técnicos ou ferramentas compartilhadas que confirmem diretamente essa relação. Outra investigação, divulgada pela VMRay, identificou atividades do grupo Hydra Saiga, também conhecido como Comrade Saiga, que comprometeu pelo menos 34 organizações em oito países desde dezembro de 2024. As operações de reconhecimento também alcançaram mais de 200 alvos adicionais em diferentes regiões do mundo. Esse grupo tem demonstrado interesse particular em infraestruturas relacionadas a recursos hídricos na Ásia Central, utilizando ferramentas desenvolvidas em Rust, Go e Python, além de técnicas Living-off-the-Land, que aproveitam recursos legítimos dos sistemas para executar atividades maliciosas. Campanhas utilizam documentos diplomáticos e contas governamentais Os ataques associados ao Silent Lynx começam principalmente com campanhas direcionadas de spear-phishing, utilizando documentos relacionados a diplomacia, comércio internacional, energia e aviação. Entre janeiro de 2025 e maio de 2026, foram identificadas pelo menos oito campanhas na região. Os e-mails fraudulentos são enviados a partir de contas governamentais comprometidas e apresentam documentos com aparência oficial para aumentar a credibilidade das mensagens. Entre os materiais utilizados estão uma carta diplomática direcionada ao Ministério das Relações Exteriores da Armênia, um formulário de solicitação relacionado ao espaço aéreo do Turcomenistão e uma proposta comercial envolvendo a refinaria de petróleo de Orsk, na Rússia. A investigação também identificou três diretórios de preparação de ataques acessíveis publicamente, associados ao grupo. Eles armazenavam ferramentas compatíveis com Linux e um código de prova de conceito para explorar a CVE-2025-25257, vulnerabilidade de injeção SQL no Fortinet FortiWeb. A presença desses recursos sugere uma possível ampliação das capacidades operacionais dos invasores, embora não confirme sua utilização em ataques. Quatro métodos de infecção identificados A análise da Cisco Talos identificou quatro cadeias de ataque utilizadas pelo Silent Lynx ao longo da campanha. Em junho de 2025, os invasores distribuíram documentos do Microsoft Word contendo macros maliciosas, responsáveis por baixar e executar um segundo componente no sistema comprometido. Em julho, passaram a utilizar downloaders desenvolvidos com PS2EXE, ferramenta que transforma scripts PowerShell em executáveis Windows. Esses arquivos baixavam os payloads de shell reverso e criavam tarefas agendadas para garantir a persistência. Em outubro de 2025, o grupo começou a distribuir arquivos RAR contendo atalhos maliciosos do Windows (LNK). Quando executados, os atalhos iniciavam comandos PowerShell para baixar scripts hospedados no GitHub e estabelecer acesso remoto. Versões posteriores dessa técnica também passaram a instalar o PickleShell na pasta de inicialização do Windows, permitindo sua execução automática sempre que o usuário entrasse no sistema. Em abril de 2026, os invasores incorporaram a exploração da vulnerabilidade CVE-2025-8088 no WinRAR. Arquivos RAR especialmente preparados eram utilizados para instalar o PickleShell diretamente na pasta de inicialização do Windows. Segundo os pesquisadores, essa foi a primeira vez que o UAT-6275 utilizou uma vulnerabilidade de segurança como mecanismo de distribuição de malware, representando uma evolução em suas técnicas de ataque. Operações indicam interesse em informações estratégicas A continuidade das campanhas e a diversificação dos métodos de infecção indicam que o Silent Lynx mantém interesse em organizações governamentais da Ásia Central e de outros países da CEI. Entre os alvos de maior interesse estão agências ambientais, ministérios da economia e infraestruturas relacionadas ao setor energético. Para a Cisco Talos, a seleção dessas organizações está relacionada ao valor estratégico de informações sobre diplomacia regional, desenvolvimento econômico e gestão de recursos naturais. A adoção de ferramentas personalizadas, mecanismos de persistência e exploração de vulnerabilidades conhecidas demonstra a capacidade do grupo de adaptar suas operações para manter acesso a ambientes governamentais e coletar informações de interesse.

O governo da Índia determinou que as operadoras de telecomunicações passem a exibir o nome registrado de quem realiza uma ligação, além do número de telefone, a partir de 1º de novembro de 2026. A medida busca facilitar a identificação de chamadas desconhecidas e combater ligações de spam e tentativas de fraude telefônica. A determinação foi formalizada pelo Departamento de Telecomunicações (DoT) por meio de uma circular publicada pelo Ministério das Comunicações em 13 de outubro. O documento estabelece a implementação do serviço Calling Name Presentation (CNAP), responsável por apresentar a identidade do titular da linha durante o recebimento de chamadas. Inicialmente, a obrigatoriedade será aplicada às redes móveis 4G e de gerações posteriores, incluindo o 5G. A implementação em redes 2G, 3G e na rede telefônica pública comutada (PSTN) será analisada separadamente. Como funcionará a identificação das chamadas Pelas novas regras, a tela do celular apresentará duas informações durante uma chamada recebida: o número de telefone e o nome associado à linha. Caso o número já esteja salvo na agenda do destinatário, será exibido o nome cadastrado nos contatos. Para números desconhecidos em chamadas nacionais, o sistema consultará o banco de dados da operadora responsável pela origem da ligação e apresentará o nome registrado do assinante. Já as ligações originadas fora da Índia serão identificadas pela indicação "International Call" (Chamada Internacional). Para viabilizar o funcionamento do CNAP, cada operadora deverá criar e manter uma base de dados que relacione os nomes dos assinantes aos respectivos números telefônicos. A operadora que recebe a chamada consultará essas informações para apresentar a identificação ao destinatário. O mecanismo pretende oferecer uma identificação baseada nos registros das empresas de telecomunicações, reduzindo a dependência de aplicativos de terceiros para reconhecer números desconhecidos. Privacidade e segurança das informações O Ministério das Comunicações também estabeleceu requisitos para proteger os dados utilizados pelo sistema. As operadoras deverão adotar uma abordagem de segurança desde a concepção da solução, conhecida como secure by design. Entre as exigências está a proibição de armazenar a identidade consultada após o encerramento da chamada recebida. As empresas também deverão manter a qualidade dos serviços conforme a legislação aplicável e disponibilizar infraestrutura de rede, conectividade e bancos de dados suficiente para processar as consultas. Outra determinação envolve a disponibilização do recurso Calling Line Identification Restriction (CLIR), que permite aos usuários optar por ocultar sua identificação ao realizar chamadas. Empresas poderão utilizar nomes comerciais registrados As regras também contemplam usuários de linhas empresariais e contratos com múltiplas conexões, que poderão solicitar a exibição de um nome comercial preferencial em substituição ao nome do titular. Essa identificação deverá corresponder a uma marca registrada oficialmente no órgão indiano responsável por patentes e marcas ou a um nome comercial cadastrado no portal de tributação Goods and Services Tax (GST). Para novas conexões, o nome preferencial deverá constar tanto no formulário de contratação quanto no registro do assinante. O solicitante precisará apresentar à operadora os documentos originais que comprovem o direito de utilização do nome, além de fornecer cópias para inclusão no cadastro. Com a implementação obrigatória do CNAP, a Índia pretende ampliar a transparência das chamadas telefônicas e oferecer aos usuários mais informações para identificar contatos desconhecidos, especialmente diante de tentativas de golpes e comunicações fraudulentas.

A Huge Networks está entre as 16 empresas presentes no Guia de soluções anti-DDoS publicado pela revista RTI na edição de setembro de 2026. O levantamento reúne fornecedores e tecnologias disponíveis para mitigação de ataques distribuídos de negação de serviço (DDoS), com informações técnicas declaradas pelas próprias empresas participantes. No guia, a Huge Networks aparece em duas posições: como fabricante de tecnologia anti-DDoS e como operadora de trânsito IP. A empresa desenvolve o HugeGuard e também opera sua própria rede, identificada pelo sistema autônomo AS264409. Segundo o guia, apenas 3 das 16 empresas participantes ocupam simultaneamente essas duas posições. A ficha da Huge também apresenta suporte às três principais topologias de mitigação: on-premises, em nuvem e híbrida. Segundo o guia, somente 2 das 16 empresas combinam tecnologia e rede próprias com essas três modalidades. A Huge Networks é uma delas. Na arquitetura on-premises, a mitigação é realizada no ambiente do cliente. A modalidade em nuvem utiliza a infraestrutura externa de mitigação da empresa, enquanto o modelo híbrido combina recursos locais e cloud para adaptar a proteção ao perfil da rede e às características do ataque. Entre os recursos relacionados pelo guia estão proteção contra ataques nas camadas 3, 4 e 7, além de proteção de APIs. A ficha também informa que a Huge mantém centros de mitigação no Brasil, permitindo que o tráfego processado pela infraestrutura de proteção permaneça no país. Para entrega do tráfego limpo ao ambiente protegido, a Huge oferece quatro alternativas indicadas no levantamento: BGP FlowSpec, cross connect, túnel GRE e IX/VLAN. A oferta também contempla monitoramento em tempo real e resposta a incidentes em regime 24x7. Na mesma edição, a Huge Networks veiculou um anúncio de página inteira do HugeGuard. Nele, a empresa apresenta o HugeGuard Cloud com capacidade agregada superior a 30 Tbps, mais de 50 PoPs, latência adicional inferior a 5 ms e SLA de 99,99%. O HugeGuard Hybrid, que combina mitigação na borda com capacidade em nuvem, aparece com SLA de 99,995%, e o HugeGuard Wall, com processamento 100% local. O Guia de soluções anti-DDoS da RTI funciona como um mapeamento das empresas e dos recursos disponíveis nesse mercado. A própria publicação informa que os dados foram fornecidos pelas organizações participantes. Fonte: revista RTI, setembro de 2026, p. 44. Guia on-line: arandanet.com.br/revista/rti Mais informações sobre o HugeGuard