O Google anunciou uma nova camada de proteção para o Android que pode mudar significativamente a forma como usuários instalam aplicativos fora da Play Store. A empresa revelou um novo “fluxo avançado” de sideloading que exigirá uma espera obrigatória de 24 horas antes da instalação de apps distribuídos por desenvolvedores não verificados. A medida busca reforçar a segurança da plataforma sem eliminar completamente a flexibilidade histórica do ecossistema Android. O sideloading é o processo de instalar aplicativos manualmente, sem utilizar a loja oficial do sistema. Embora esse recurso seja valorizado por usuários avançados, desenvolvedores independentes e comunidades de software livre, ele também é frequentemente explorado por hackers para disseminar malware, golpes financeiros e aplicativos adulterados. Segundo o Google, a nova política tenta reduzir justamente esse tipo de abuso, dificultando ataques que dependem de pressão psicológica, urgência ou manipulação do usuário em tempo real. A novidade surge em meio ao plano da companhia de exigir que todos os aplicativos Android sejam publicados por desenvolvedores verificados para que possam ser instalados em dispositivos Android certificados. Essa exigência já havia sido anunciada anteriormente e tem como objetivo permitir que o Google identifique maus atores com mais rapidez, além de dificultar a distribuição de aplicativos maliciosos. Na prática, a empresa quer criar um modelo em que a abertura do Android continue existindo, mas com mais barreiras contra fraudes. Um dos principais cenários que preocupam o Google envolve golpes em que criminosos convencem usuários a instalar aplicativos manualmente e, durante esse processo, conceder permissões elevadas. Isso pode permitir, por exemplo, desativar o Play Protect, sistema nativo de proteção contra malware presente em aparelhos Android certificados. Ao obter esse tipo de acesso, o invasor ganha espaço para assumir o controle do dispositivo, roubar credenciais, monitorar atividades ou realizar fraudes bancárias. Para reduzir esse risco, o novo processo exigirá várias etapas adicionais antes que um app de um desenvolvedor não verificado possa ser instalado. O usuário precisará ativar o modo de desenvolvedor nas configurações do sistema, confirmar que está executando a ação por vontade própria e que não está sendo orientado por terceiros, reiniciar o aparelho e se autenticar novamente. Em seguida, haverá uma espera obrigatória de 24 horas. Após esse prazo, será necessário confirmar novamente a decisão usando biometria ou PIN do dispositivo. Somente depois de concluir todas essas etapas será possível instalar aplicativos de desenvolvedores não verificados. O Google informou que essa permissão poderá ser concedida por tempo limitado, como sete dias, ou de forma contínua, desde que o usuário compreenda os riscos envolvidos. A lógica por trás da mudança é simples: a maioria dos golpes depende de urgência e manipulação imediata. Ao impor uma pausa de 24 horas, o Google acredita que aumenta as chances de a vítima perceber a fraude antes de concluir a instalação. Segundo Sameer Samat , presidente do ecossistema Android, esse intervalo torna muito mais difícil a persistência do ataque. A avaliação da empresa é que, nesse período, o usuário pode descobrir que a suposta emergência era falsa — como uma alegação de prisão de um familiar ou um alerta fraudulento sobre comprometimento da conta bancária — e interromper o processo antes de entregar acesso ao invasor. Ao mesmo tempo, a iniciativa reacendeu críticas de parte da comunidade de tecnologia. Mais de 50 desenvolvedores e marketplaces, entre eles F-Droid, Brave, Electronic Frontier Foundation, Proton, Tor Project e Vivaldi, têm contestado as novas exigências de verificação. Para esse grupo, as mudanças podem criar barreiras para pequenos desenvolvedores, aumentar o atrito para distribuição independente e levantar preocupações com privacidade, especialmente pela falta de clareza sobre quais dados pessoais precisarão ser fornecidos, como essas informações serão armazenadas, protegidas e eventualmente compartilhadas com autoridades. Como tentativa de amenizar essas críticas, o Google afirmou que lançará contas gratuitas de “distribuição limitada”, voltadas para estudantes, hobbystas e desenvolvedores independentes. Esse modelo permitirá compartilhar aplicativos com até 20 dispositivos sem exigir documento oficial emitido pelo governo nem taxa de registro. A proposta é preservar um caminho viável para quem desenvolve fora dos grandes ecossistemas comerciais, sem abrir completamente mão dos controles de segurança. A companhia destacou ainda que o novo fluxo avançado não se aplica a instalações feitas por meio do Android Debug Bridge (ADB), ferramenta normalmente usada por desenvolvedores e profissionais técnicos. Isso indica que o Google está tentando segmentar melhor os diferentes perfis de uso, restringindo mais fortemente os cenários considerados mais exploráveis por golpistas, sem comprometer totalmente os ambientes de desenvolvimento legítimos. De acordo com o cronograma divulgado, tanto as contas de distribuição limitada quanto o novo fluxo avançado para sideloading estarão disponíveis em agosto de 2026. Já a exigência formal de verificação para desenvolvedores deve entrar em vigor no mês seguinte. A mensagem central do Google é que uma abordagem única para todo o ecossistema não funciona e que diferentes trilhas serão oferecidas para equilibrar segurança, abertura e acessibilidade. O anúncio acontece em um momento de pressão crescente sobre a segurança no Android. Paralelamente, foi identificada uma nova ameaça chamada Perseus, malware para Android que estaria mirando usuários na Turquia e na Itália com foco em tomada de controle do dispositivo e fraudes financeiras. Nos últimos quatro meses, pelo menos 17 famílias de malware Android foram observadas em circulação, incluindo nomes como FvncBot, SeedSnatcher, ClayRat, Wonderland, Cellik, Frogblight, NexusRoute, ZeroDayRAT, SURXRAT, Phantom, Massiv, BeatBanker, Mirax e Oblivion RAT. Esse contexto ajuda a explicar por que o Google está endurecendo as regras para instalação fora da Play Store. Embora o sideloading continue sendo um recurso importante para liberdade do usuário e distribuição alternativa de software, ele também se tornou um dos caminhos preferidos para campanhas de infecção, takeover de dispositivos e golpes bancários. O desafio agora será encontrar o ponto de equilíbrio entre segurança real e preservação da natureza aberta que sempre diferenciou o Android de outras plataformas móveis.

Uma campanha ativa de ransomware está explorando uma vulnerabilidade crítica de dia zero em soluções da Cisco, elevando o nível de alerta no cenário global de cibersegurança. O grupo por trás do ransomware Interlock  está utilizando a falha CVE-2026-20131 , que afeta o Cisco Secure Firewall Management Center (FMC) , para obter acesso root remoto sem autenticação . A vulnerabilidade, classificada com pontuação máxima CVSS 10.0 , envolve um problema de desserialização insegura de dados Java , permitindo que hackers executem código arbitrário diretamente no sistema afetado. Na prática, isso significa que um invasor pode comprometer totalmente o dispositivo sem precisar de credenciais ou interação do usuário. De acordo com análises da Amazon Threat Intelligence , a falha já vinha sendo explorada como zero-day desde 26 de janeiro de 2026 , mais de um mês antes de sua divulgação oficial pela Cisco. Esse fator deu aos atacantes uma vantagem significativa, permitindo comprometer organizações antes mesmo que medidas de defesa pudessem ser aplicadas. A descoberta foi possível após uma falha operacional do próprio grupo hacker, que expôs parte de sua infraestrutura. Isso permitiu identificar detalhes do arsenal utilizado, incluindo trojans personalizados, scripts de reconhecimento e técnicas avançadas de evasão. O ataque começa com o envio de requisições HTTP maliciosas para um endpoint específico do FMC, permitindo a execução de código Java. Após a exploração bem-sucedida, o sistema comprometido envia uma requisição para um servidor externo confirmando o acesso, e em seguida baixa um binário ELF que inicia as próximas fases do ataque. Entre as ferramentas identificadas na operação estão: Script PowerShell para reconhecimento detalhado de ambientes Windows Trojans de acesso remoto (RATs) desenvolvidos em Java e JavaScript Scripts Bash para transformar servidores Linux em proxies reversos e ocultar a origem dos ataques Webshells em memória para execução remota de comandos Beacon de rede para comunicação com servidores de comando e controle Uso do ConnectWise ScreenConnect  para persistência e acesso remoto Ferramentas de análise de memória como o Volatility Framework Esses recursos permitem aos hackers realizar movimentação lateral, exfiltração de dados e manutenção de acesso persistente , dificultando a detecção e resposta por parte das equipes de segurança. A análise também indica que o grupo Interlock opera provavelmente em um fuso horário UTC+3 , e utiliza infraestrutura baseada em TOR para negociação de resgates, reforçando seu perfil como uma operação estruturada de ransomware. Diante da exploração ativa, a recomendação é que organizações apliquem imediatamente as correções disponibilizadas pela Cisco, realizem varreduras para identificar possíveis comprometimentos e revisem instalações suspeitas de ferramentas de acesso remoto como o ScreenConnect. O caso evidencia um desafio crítico da segurança moderna: o impacto dos ataques que exploram vulnerabilidades antes da existência de correções. Mesmo organizações com programas maduros de gestão de vulnerabilidades podem ficar expostas nesse intervalo. Além disso, o cenário atual mostra uma mudança nas estratégias de ransomware. Com a redução nas taxas de pagamento, grupos hackers estão explorando mais vulnerabilidades em dispositivos de borda, como VPNs e firewalls , e utilizando ferramentas legítimas já presentes nos sistemas para evitar detecção. Esse movimento indica uma evolução no modelo de ataque, com foco não apenas em criptografia de dados, mas também em extorsão baseada em roubo de informações e uso secundário de acessos comprometidos , como envio de campanhas de phishing a partir de infraestruturas invadidas.

Uma vulnerabilidade de alta gravidade foi identificada em instalações padrão do Ubuntu Desktop 24.04 e versões posteriores , permitindo que invasores locais escalem privilégios até o nível de root . A falha, rastreada como CVE-2026-3888  e com pontuação 7.8 no CVSS , foi analisada pela Qualys e pode resultar no comprometimento completo do sistema afetado. O problema não está em um único componente isolado, mas na interação entre dois serviços amplamente utilizados no sistema: o snap-confine , responsável por gerenciar ambientes isolados (sandbox) de aplicações Snap, e o systemd-tmpfiles , que realiza a limpeza automática de arquivos e diretórios temporários, como /tmp, /run e /var/tmp. De acordo com a análise , a vulnerabilidade surge a partir de uma falha lógica no processo de limpeza automática. O systemd-tmpfiles remove diretórios considerados obsoletos após um determinado período — 30 dias no Ubuntu 24.04 e 10 dias em versões mais recentes . Esse comportamento pode ser explorado por um invasor que aguarda a exclusão de um diretório crítico utilizado pelo snap-confine, especificamente o /tmp/.snap. Uma vez que esse diretório é removido, o invasor recria a estrutura com conteúdo malicioso. Na próxima execução de uma aplicação Snap, o snap-confine monta esses arquivos com privilégios elevados, permitindo a execução arbitrária de código como root . O ataque, embora exija tempo e sincronização precisa, não requer interação do usuário e pode ser realizado com privilégios mínimos. Esse tipo de exploração baseado em timing (janela de tempo)  torna o ataque mais complexo, mas não menos perigoso. Segundo os pesquisadores, a janela de oportunidade pode variar entre 10 e 30 dias , dependendo da configuração do sistema, o que indica que o invasor pode preparar o ambiente de forma silenciosa e aguardar o momento ideal para executar o ataque. Além dessa falha, também foi identificada uma vulnerabilidade adicional envolvendo uma condição de corrida (race condition)  no pacote uutils coreutils . Essa falha permite que um invasor substitua entradas de diretório por links simbólicos (symlinks) durante execuções de tarefas automatizadas (cron) com privilégios elevados. Na prática, isso pode resultar na exclusão arbitrária de arquivos como root ou facilitar novas etapas de escalada de privilégios. A vulnerabilidade CVE-2026-3888 já foi corrigida nas seguintes versões: Ubuntu 24.04 LTS — versões do snapd anteriores à 2.73+ubuntu24.04.1 Ubuntu 25.10 LTS — versões do snapd anteriores à 2.73+ubuntu25.10.1 Ubuntu 26.04 LTS (desenvolvimento) — versões anteriores à 2.74.1+ubuntu26.04.1 Upstream snapd — versões anteriores à 2.75 No caso da falha envolvendo o uutils, a mitigação foi realizada rapidamente com a reversão do comando rm para a versão tradicional do GNU coreutils  no Ubuntu 25.10, enquanto correções adicionais já foram aplicadas no repositório upstream. O incidente reforça um ponto importante na segurança de sistemas Linux modernos: nem todas as vulnerabilidades estão associadas a falhas clássicas de memória ou execução de código, mas podem surgir da interação inesperada entre componentes legítimos do sistema . Esse tipo de falha é particularmente difícil de detectar, pois envolve comportamentos considerados normais individualmente, mas que, combinados, criam vetores de ataque. Para ambientes corporativos e usuários que utilizam versões afetadas, a recomendação é aplicar as atualizações de segurança imediatamente, revisar políticas de limpeza automática e monitorar atividades suspeitas em diretórios temporários, que continuam sendo um dos principais pontos de exploração em sistemas Unix-like.

Uma nova vulnerabilidade crítica identificada no serviço Telnetd do GNU InetUtils  está gerando preocupação entre especialistas em segurança. A falha, registrada como CVE-2026-32746 , permite que um invasor remoto execute código com privilégios de root sem qualquer tipo de autenticação , o que representa um dos cenários mais críticos em termos de comprometimento de sistemas. Classificada com pontuação 9.8 no CVSS , a vulnerabilidade foi descoberta pela empresa israelense Dream e afeta todas as versões do telnetd até a 2.7 . O problema está relacionado a um erro de escrita fora dos limites (out-of-bounds write) no manipulador da subopção LINEMODE Set Local Characters (SLC) , que resulta em um buffer overflow  — condição amplamente explorada por hackers para execução arbitrária de código. O ponto mais crítico do ataque é que ele ocorre antes mesmo da etapa de autenticação , durante o handshake inicial do protocolo Telnet. Na prática, isso significa que um invasor pode explorar a falha simplesmente estabelecendo uma conexão com a porta 23  e enviando uma mensagem especialmente construída, sem necessidade de credenciais, interação do usuário ou acesso privilegiado à rede. Segundo análise divulgada , uma única conexão já é suficiente para explorar a vulnerabilidade , tornando o ataque extremamente simples e de alta escalabilidade. Em ambientes onde o serviço telnetd está em execução com privilégios elevados — como é comum em configurações padrão utilizando inetd ou xinetd — o impacto pode ser devastador, permitindo controle total do sistema comprometido. A exploração bem-sucedida pode abrir caminho para diversas ações maliciosas, incluindo a instalação de backdoors persistentes , exfiltração de dados sensíveis e movimentação lateral dentro da rede, utilizando o sistema invadido como ponto de apoio para ataques adicionais. Em cenários corporativos, isso pode representar um risco significativo para toda a infraestrutura. O funcionamento técnico da falha envolve o manipulador SLC, responsável por negociar opções durante o handshake do protocolo Telnet. Devido à vulnerabilidade, hackers conseguem enviar múltiplos parâmetros maliciosos que corrompem a memória do processo, permitindo a manipulação arbitrária de dados e, consequentemente, a execução remota de código. Outro fator que aumenta a gravidade do cenário é a ausência de correção imediata. A expectativa é que um patch seja disponibilizado apenas até 1º de abril de 2026 , o que amplia a janela de exposição para organizações que ainda utilizam Telnet em seus ambientes. Enquanto a atualização oficial não é liberada, especialistas recomendam medidas emergenciais, como: Desativar o serviço Telnet , caso não seja essencial Executar o telnetd com privilégios reduzidos, evitando uso como root Bloquear a porta 23  em firewalls de rede e host Restringir e isolar ao máximo o acesso ao serviço A nova falha surge pouco tempo após outra vulnerabilidade crítica no mesmo componente, a CVE-2026-24061 , também com pontuação 9.8, que já está sendo explorada ativamente. Esse histórico recente reforça que serviços legados como o Telnet continuam sendo um vetor relevante de ataque, especialmente em ambientes onde ainda não foram completamente descontinuados ou substituídos por alternativas mais seguras, como SSH.

Um novo kit de exploração voltado a dispositivos Apple com iOS está sendo usado por múltiplos grupos desde pelo menos novembro de 2025 e acendeu um novo alerta no ecossistema mobile. Batizada de DarkSword , a cadeia de ataque foi identificada em análises do Google Threat Intelligence Group (GTIG) , da iVerify  e da Lookout . Segundo os levantamentos, a ferramenta foi utilizada em campanhas distintas com alvos na Arábia Saudita, Turquia, Malásia e Ucrânia , combinando espionagem, roubo de informações sensíveis e interesse em ativos ligados ao universo cripto. A descoberta chama atenção porque o DarkSword surge logo após a revelação do Coruna , tornando-se o segundo kit de exploração para iOS descoberto em cerca de um mês . A nova cadeia foi desenvolvida para atingir iPhones com versões entre iOS 18.4 e 18.7 , e teria sido empregada por um grupo suspeito de espionagem russa, identificado como UNC6353 , em ataques contra usuários ucranianos. Esse mesmo grupo já havia sido relacionado ao uso do Coruna em campanhas anteriores, por meio da injeção de código JavaScript em sites comprometidos. As análises indicam que o DarkSword foi projetado para assumir o controle completo do dispositivo  e, em seguida, coletar rapidamente o maior volume possível de dados. Diferentemente de spywares tradicionais, que costumam permanecer por longos períodos no aparelho para monitoramento contínuo, essa ferramenta adota uma abordagem de “ataque relâmpago” : invade, coleta, exfiltra e apaga rastros em questão de segundos ou poucos minutos. Esse comportamento sugere um modelo de operação focado em velocidade, furtividade e redução do tempo de permanência no dispositivo invadido. Entre os dados visados estão credenciais, arquivos do iCloud Drive, contatos, mensagens SMS, histórico do Safari, cookies, fotos, registros de chamadas, senhas de Wi-Fi, histórico de localização, dados de calendário, informações de chip e rede celular, lista de aplicativos instalados , além de conteúdo de apps nativos da Apple, como Notas e Saúde . Também entram na mira dados relacionados a carteiras de criptomoedas, corretoras, Telegram e WhatsApp , o que reforça a possibilidade de uma motivação não apenas ligada à espionagem, mas também a ganhos financeiros. De acordo com os relatórios, a cadeia de exploração utiliza seis vulnerabilidades  para implantar três cargas maliciosas , incluindo três falhas zero-day , exploradas antes da disponibilização de correções pela Apple. As vulnerabilidades associadas ao DarkSword são: CVE-2025-31277  — falha de corrupção de memória no JavaScriptCore, corrigida na versão 18.6 CVE-2026-20700  — bypass de Pointer Authentication Code (PAC) em modo usuário no dyld, corrigido na versão 26.3 CVE-2025-43529  — falha de corrupção de memória no JavaScriptCore, corrigida nas versões 18.7.3 e 26.2 CVE-2025-14174  — falha de corrupção de memória no ANGLE, corrigida nas versões 18.7.3 e 26.2 CVE-2025-43510  — falha de gerenciamento de memória no kernel do iOS, corrigida nas versões 18.7.2 e 26.1 CVE-2025-43520  — falha de corrupção de memória no kernel do iOS, corrigida nas versões 18.7.2 e 26.1 A Lookout apontou que o DarkSword foi identificado a partir da análise de uma infraestrutura maliciosa associada ao UNC6353. Em um dos domínios comprometidos, foi encontrado um iFrame malicioso  responsável por carregar um JavaScript capaz de identificar o dispositivo visitante e verificar se ele deveria ser direcionado à cadeia de exploração para iOS. Ainda não está claro como esses sites foram comprometidos, mas o modelo de operação indica o uso de watering hole , técnica em que páginas legítimas ou populares são infectadas para atingir visitantes de interesse. O ponto técnico mais relevante é que o JavaScript encontrado procurava especificamente por aparelhos com versões entre iOS 18.4 e 18.6.2 , mostrando um foco bem delimitado. Isso diferencia o DarkSword do Coruna, que visava versões mais antigas, entre iOS 13.0 e 17.2.1 . Na prática, isso mostra que os invasores estão mantendo arsenais paralelos de exploração , adaptados para diferentes faixas de versões do sistema operacional. O fluxo do ataque começa quando a vítima acessa, via Safari, uma página com o iFrame malicioso. A partir daí, o DarkSword consegue romper a sandbox do WebContent, que é o processo de renderização do Safari, e usa o WebGPU  para injetar código no mediaplaybackd , um daemon do sistema introduzido pela Apple para lidar com funções de reprodução de mídia. Esse movimento abre caminho para o malware identificado como GHOSTBLADE , que passa a acessar processos privilegiados e áreas restritas do sistema de arquivos. Após a escalada de privilégios, um módulo orquestrador carrega componentes adicionais destinados a coletar dados e inserir uma carga de exfiltração no SpringBoard , interface central do iOS. É essa etapa que permite enviar as informações roubadas para servidores externos por HTTP(S) . Segundo a iVerify, a cadeia usa falhas no JavaScriptCore JIT  para obter execução remota de código, depois escapa da sandbox por meio do processo de GPU e, por fim, explora vulnerabilidades no kernel para obter leitura, escrita e chamadas arbitrárias de funções dentro do mediaplaybackd. Outro ponto que chamou atenção foi o grau de sofisticação da plataforma. A ferramenta foi descrita como uma cadeia completa de exploração e roubo de dados escrita em JavaScript , com estrutura modular, o que sugere preocupação com manutenção, extensibilidade e desenvolvimento contínuo . Em outras palavras, não se trata de um código improvisado, mas de uma plataforma ofensiva profissional, capaz de evoluir rapidamente conforme novas necessidades operacionais surgem. Ao mesmo tempo, os relatórios indicam sinais contraditórios. Apesar da sofisticação da exploração, o código apresenta baixa ofuscação , nomes evidentes em componentes da infraestrutura e falhas de segurança operacional. Isso levanta duas hipóteses: ou o grupo responsável pelo uso do DarkSword não possui recursos robustos de engenharia, ou simplesmente não se preocupou em esconder melhor sua operação. Esse detalhe reforça a avaliação de que o UNC6353 pode ser menos sofisticado tecnicamente do que os desenvolvedores da cadeia de exploração que utiliza , o que fortalece a tese de um mercado secundário de exploits altamente avançados disponível para grupos com diferentes perfis e objetivos. Os investigadores também encontraram referências a versões iOS 17.4.1 e 17.5.1  nos arquivos JavaScript, sinalizando que o DarkSword pode ter sido adaptado de uma geração anterior da mesma ferramenta ou de uma base técnica já usada contra versões mais antigas do sistema. Isso sugere reaproveitamento de código e evolução incremental da cadeia, prática comum em operações ofensivas maduras. Além do UNC6353, o uso do DarkSword foi associado a outros dois atores . O primeiro é o UNC6748 , que teria atacado usuários na Arábia Saudita em novembro de 2025 por meio de um site temático ligado ao Snapchat, identificado como snapshare[.]chat , para entregar o backdoor em JavaScript GHOSTKNIFE , voltado ao roubo de informações. O segundo caso envolve atividade associada ao fornecedor turco de vigilância comercial PARS Defense , que também teria usado o DarkSword em novembro de 2025 para implantar o backdoor GHOSTSABER , ferramenta capaz de enumerar dispositivos e contas, listar arquivos, exfiltrar dados e executar JavaScript arbitrário. O Google observou ainda diferenças operacionais entre os atores. Enquanto a atividade atribuída ao UNC6353 , em dezembro de 2025, suportava apenas versões entre iOS 18.4 e 18.6 , o uso ligado ao UNC6748  e à PARS Defense  também incluía aparelhos com iOS 18.7 . Esse detalhe mostra que a mesma cadeia de exploração pode circular entre diferentes operadores, com pequenas adaptações, fortalecendo a percepção de que há uma proliferação comercial de capacidades ofensivas avançadas para iPhone . O alerta mais amplo é que, pelo segundo mês consecutivo, grupos distintos recorreram a watering hole attacks  para comprometer usuários de iPhone sem necessariamente exigir interação complexa da vítima. E, segundo a iVerify, esses incidentes não foram campanhas individualizadas contra poucos alvos específicos. A avaliação é de que a combinação entre Coruna e DarkSword pode colocar em risco centenas de milhões de aparelhos sem correção , especialmente aqueles executando versões entre iOS 13 e iOS 18.6.2 . No pano de fundo, o caso reacende um debate cada vez mais sensível no setor: quão grande, estruturado e acessível está o mercado de exploits para iOS , incluindo falhas zero-day e n-day? A circulação de ferramentas como Coruna e DarkSword entre grupos com perfis distintos, motivações híbridas e graus variados de sofisticação mostra que o uso de capacidades antes restritas a operações de alto nível pode estar se tornando mais disseminado. Para usuários, empresas e governos, isso significa que o iPhone continua sendo um alvo altamente valioso — e que o tempo entre a descoberta de uma falha, sua exploração ativa e a necessidade de aplicação de correções está cada vez menor.

A cidade russa de Perm enfrentou uma interrupção significativa em seu sistema de pagamento de estacionamento após um ataque cibernético do tipo DDoS (negação de serviço distribuída) derrubar a infraestrutura digital responsável pelo serviço. O incidente ocorreu na última semana e deixou o sistema indisponível por vários dias, obrigando as autoridades locais a suspenderem a cobrança o que, na prática, tornou o estacionamento gratuito temporariamente. De acordo com autoridades municipais , o sistema já foi totalmente restabelecido e voltou a operar normalmente, com todos os métodos de pagamento disponíveis. A falha foi causada por um ataque em larga escala que sobrecarregou os sistemas automatizados responsáveis pelo gerenciamento das cobranças, impedindo motoristas de utilizarem o aplicativo oficial e o site para efetuar pagamentos. Durante o período de indisponibilidade, entre os dias 10 e 13 de março, a prefeitura garantiu que nenhum motorista seria penalizado pela falta de pagamento. Em condições normais, o estacionamento pago em Perm já é gratuito aos fins de semana, mas a interrupção estendeu essa gratuidade de forma excepcional para toda a cidade. Este não é um caso isolado. Nos últimos anos, sistemas de estacionamento em outras cidades russas também foram alvo de ataques semelhantes. Em 2023, um ataque DDoS contra uma operadora de telecomunicações impactou os serviços de pagamento em Krasnodar. Já em outubro de 2024, a cidade de Tver sofreu um ataque mais destrutivo contra sua administração pública, resultando na indisponibilidade de sistemas críticos. Na ocasião, um grupo hacktivista pró-Ucrânia assumiu a responsabilidade pelo ataque em Tver, alegando ter apagado dezenas de máquinas virtuais, sistemas de backup, websites, e-mails e centenas de estações de trabalho da administração municipal. Apesar do histórico, ainda não há confirmação de que o incidente em Perm esteja relacionado a esse grupo ou a campanhas anteriores. O episódio reforça uma tendência crescente de ataques direcionados a serviços urbanos e infraestruturas digitais públicas na Rússia, especialmente em meio ao contexto geopolítico atual. Outros incidentes recentes incluem ataques que impactaram a distribuição de alimentos, sistemas de segurança residencial e até plataformas de reserva e check-in utilizadas por companhias aéreas e aeroportos no país. Mais do que um problema técnico, esses ataques demonstram como serviços aparentemente simples como o pagamento de estacionamento podem se tornar pontos críticos de interrupção, afetando diretamente a rotina da população e evidenciando a importância da resiliência cibernética em ambientes urbanos cada vez mais digitalizados.

O Departamento de Energia dos Estados Unidos está prestes a divulgar, pela primeira vez, uma estratégia oficial de cibersegurança voltada especificamente à proteção da infraestrutura energética do país. O anúncio foi feito por Alex Fitzsimmons, subsecretário de Energia e diretor do Office of Cybersecurity, Energy Security, and Emergency Response ( CESER ), durante um evento em Washington, D.C. A iniciativa surge como um complemento à estratégia nacional de cibersegurança recentemente publicada pelo governo norte-americano , com foco direto no fortalecimento da segurança e da resiliência do setor energético considerado uma das infraestruturas críticas mais sensíveis do país. A proposta busca estabelecer diretrizes mais claras sobre como o governo pretende atuar diante do aumento das ameaças cibernéticas, especialmente em um cenário de crescente sofisticação dos ataques. Um dos pilares centrais do plano será o fortalecimento da colaboração com o setor privado. Nos Estados Unidos, grande parte da infraestrutura energética é operada por empresas privadas, o que torna a cooperação entre governo e indústria essencial para a defesa contra ataques. A estratégia pretende ampliar o compartilhamento de informações em tempo real, permitindo que essas organizações tenham acesso a dados acionáveis para proteger seus próprios ambientes. Outro ponto de destaque será o uso estratégico de inteligência artificial para defesa cibernética. O governo reconhece que hackers já estão utilizando IA para potencializar ataques, e, por isso, pretende investir em tecnologias capazes de detectar, prevenir e responder a ameaças avançadas. A aplicação dessas soluções será especialmente direcionada à proteção de infraestruturas energéticas críticas, incluindo aquelas com relevância para cenários de conflitos e segurança nacional. Além disso, o plano abordará mecanismos para fortalecer a capacidade de resposta a incidentes cibernéticos e físicos, utilizando lições aprendidas em ataques anteriores para aprimorar a resiliência do setor. A ideia é criar um ciclo contínuo de aprendizado e evolução, onde informações obtidas em incidentes reais possam ser rapidamente disseminadas e aplicadas para evitar novos ataques. Embora a data exata de lançamento ainda não tenha sido divulgada, autoridades indicaram que a publicação ocorrerá em breve. A expectativa é que o documento represente um marco importante na estratégia de defesa cibernética dos Estados Unidos, especialmente diante do aumento de ataques direcionados a infraestruturas críticas em todo o mundo.

O grupo hacker Medusa assumiu a autoria de dois ataques cibernéticos de grande impacto nos Estados Unidos, atingindo o University of Mississippi Medical Center (UMMC), maior hospital do estado do Mississippi, e o condado de Passaic, em Nova Jersey. A operação criminosa reivindicou recentemente a invasão ao UMMC, uma das instituições de saúde mais relevantes da região, responsável por empregar cerca de 10 mil pessoas e abrigar estruturas únicas no estado, como o único hospital infantil, o único centro de trauma Nível I, a única unidade neonatal de terapia intensiva Nível IV e os únicos programas de transplante de órgãos do Mississippi. O ataque ao hospital causou uma paralisação severa no fim de fevereiro, deixando toda a organização fora do ar por nove dias. Com a indisponibilidade dos sistemas, médicos e enfermeiros tiveram de recorrer a processos manuais para manter os atendimentos. Unidades críticas passaram a operar com papel e caneta, enquanto o centro de infusão oncológica precisou remarcar pacientes . Em meio à crise, equipes internas improvisaram estruturas emergenciais para garantir a continuidade de serviços essenciais, inclusive com o funcionamento de uma clínica de infusão urgente totalmente offline. Apesar de os hospitais e departamentos de emergência permanecerem em operação, o UMMC decidiu fechar temporariamente suas 35 clínicas. A gravidade do incidente levou à atuação do FBI e do Departamento de Segurança Interna dos Estados Unidos, que passaram a apoiar os esforços de resposta e recuperação. A reabertura total da instituição ocorreu em 2 de março, mas dias depois o grupo Medusa publicou a reivindicação do ataque e exigiu o pagamento de US$ 800 mil para não vazar supostos dados roubados da organização. Os hackers estabeleceram o dia 20 de março como prazo para a divulgação das informações. A instituição hospitalar evitou comentar publicamente sobre a ameaça de extorsão. Especialistas apontam que a operação Medusa provavelmente tem origem na Rússia, com base em indícios como a ausência de ataques contra países da Comunidade dos Estados Independentes, a atividade em fóruns de língua russa e o uso de caracteres cirílicos em ferramentas operacionais. Ativo desde 2021, o grupo já demonstrou repetidamente interesse em atingir alvos sensíveis, especialmente organizações de saúde e governos locais nos Estados Unidos. Além do hospital no Mississippi, o Medusa também assumiu nesta semana um ataque contra o condado de Passaic, em Nova Jersey, onde vivem quase 600 mil pessoas. Segundo autoridades locais, o incidente foi tratado inicialmente como um ataque de malware e afetou linhas telefônicas e sistemas de TI utilizados em repartições públicas. Assim como no caso do hospital, os criminosos também exigiram US$ 800 mil para encerrar a pressão sobre a vítima. Os dois casos reforçam uma tendência preocupante no cenário de cibersegurança: grupos hackers continuam mirando instituições essenciais, explorando a urgência operacional e a pressão social para aumentar as chances de pagamento. Quando hospitais e órgãos públicos são afetados, o impacto deixa de ser apenas tecnológico e passa a comprometer diretamente serviços fundamentais à população, ampliando os prejuízos operacionais, financeiros e reputacionais.

A Agência de Segurança Cibernética e Infraestrutura dos Estados Unidos (CISA) adicionou uma nova vulnerabilidade ao seu catálogo de falhas exploradas ativamente (KEV), acendendo um alerta para organizações que utilizam o Wing FTP Server. A falha, identificada como CVE-2025-47813 , permite o vazamento de informações sensíveis, incluindo o caminho de instalação da aplicação no servidor. Apesar de classificada com severidade moderada (CVSS 4.3), a vulnerabilidade já está sendo explorada ativamente por hackers, o que aumenta significativamente o risco operacional. O problema ocorre devido a um erro na geração de mensagens de erro quando valores excessivamente longos são inseridos no cookie de sessão UID . Na prática, ao manipular esse parâmetro, um invasor autenticado consegue forçar o sistema a retornar mensagens contendo o caminho completo do servidor onde o Wing FTP está instalado. Esse tipo de informação, embora pareça simples, pode ser extremamente valioso em ataques mais sofisticados. A vulnerabilidade afeta todas as versões do Wing FTP até a versão 7.4.3. A correção foi disponibilizada na versão 7.4.4, lançada em maio de 2025, após divulgação responsável realizada pelo pesquisador Julien Ahrens, da RCE Security. Além disso, a mesma atualização também corrige outra falha crítica ainda mais grave: a CVE-2025-47812 , com pontuação máxima de severidade (CVSS 10.0), que permite execução remota de código (RCE). Essa vulnerabilidade já havia sido observada sendo explorada ativamente desde julho de 2025. Relatórios anteriores indicam que hackers têm utilizado essa falha crítica para baixar e executar arquivos maliciosos em linguagem Lua, realizar reconhecimento no ambiente comprometido e instalar ferramentas de acesso remoto (RMM), ampliando o controle sobre os sistemas afetados. A análise técnica do problema revela que o endpoint /loginok.html  não valida corretamente o valor do cookie UID. Quando esse valor ultrapassa o tamanho máximo suportado pelo sistema operacional, o servidor gera uma mensagem de erro que expõe o caminho completo da aplicação no ambiente local. Embora a CVE-2025-47813 seja, isoladamente, uma falha de divulgação de informações, especialistas alertam que esse tipo de vulnerabilidade pode servir como etapa inicial para ataques mais complexos. Em especial, ela pode ser utilizada em conjunto com a falha de execução remota de código, facilitando a exploração completa do sistema. Até o momento, não há detalhes públicos sobre como exatamente essa vulnerabilidade está sendo explorada em ataques reais, nem se está sendo utilizada em cadeia com outras falhas. No entanto, o fato de ter sido incluída no catálogo KEV da CISA indica que há evidências concretas de exploração ativa. Diante desse cenário, a recomendação é clara: organizações devem atualizar imediatamente o Wing FTP Server para a versão corrigida. A CISA estabeleceu o prazo até 30 de março de 2026  para que agências federais dos EUA apliquem as correções necessárias, reforçando a urgência da mitigação. O caso evidência um ponto crítico na segurança cibernética: mesmo vulnerabilidades consideradas de baixa ou média severidade podem se tornar altamente perigosas quando combinadas com outras falhas ou utilizadas em cadeias de ataque mais elaboradas. Para equipes de segurança, isso exige uma abordagem contínua de gestão de vulnerabilidades e correções rápidas, especialmente em softwares expostos à internet.

Uma nova fase da campanha GlassWorm está explorando tokens roubados do GitHub para comprometer centenas de repositórios Python, ampliando significativamente o alcance de ataques à cadeia de suprimentos de software. A operação, identificada por pesquisadores da StepSecurity , afeta desde aplicações Django até projetos de machine learning, dashboards em Streamlit e pacotes publicados no PyPI. O ataque consiste na inserção de código malicioso ofuscado em arquivos comuns como setup.py , main.py  e app.py . Qualquer usuário que execute comandos como pip install a partir de um repositório comprometido, ou que clone e rode o código, acaba ativando o malware sem perceber. A atividade maliciosa foi rastreada desde 8 de março de 2026. Após obter acesso às contas de desenvolvedores, os hackers utilizam uma técnica avançada de manipulação de histórico Git: eles reaplicam commits legítimos sobre a branch principal , adicionando código malicioso, e realizam um force push . Esse processo mantém intactos elementos como mensagem do commit, autor e data, dificultando a identificação da adulteração. Essa nova vertente da campanha foi denominada ForceMemo  e segue uma cadeia de ataque estruturada em quatro etapas. Inicialmente, os invasores comprometem sistemas de desenvolvedores por meio de extensões maliciosas do VS Code  e do editor Cursor , que incluem funcionalidades específicas para roubo de credenciais, como tokens do GitHub. Na sequência, esses tokens são utilizados para modificar todos os repositórios associados à conta comprometida. O código malicioso, codificado em Base64, é inserido ao final de arquivos Python estratégicos. Esse payload inclui verificações para evitar execução em sistemas configurados com idioma russo, uma característica recorrente em campanhas desse tipo. O malware também se destaca pelo uso de uma abordagem incomum de comando e controle (C2). Em vez de utilizar servidores tradicionais, ele consulta o campo de “memo” de transações associadas a uma carteira da blockchain Solana para obter a URL do payload malicioso. Essa técnica permite atualizar dinamicamente os pontos de controle sem depender de infraestrutura centralizada facilmente detectável. Uma vez ativado, o código baixa cargas adicionais, incluindo scripts JavaScript criptografados projetados para roubo de criptomoedas e exfiltração de dados. Segundo a análise, o endereço da carteira utilizado na operação já registra atividade desde novembro de 2025, indicando planejamento prévio de longo prazo. Investigações adicionais apontam que o mesmo grupo hacker está diversificando seus métodos de distribuição. Uma nova variante da campanha utiliza dependências transitivas em extensões para disseminar o malware, aumentando sua capacidade de propagação sem interação direta do usuário. Além disso, mais de 150 repositórios GitHub foram comprometidos com código malicioso oculto por meio de caracteres Unicode invisíveis, dificultando ainda mais a detecção manual. Em todos os casos, a infraestrutura baseada em Solana permanece como elemento comum, reforçando a atribuição das diferentes ondas de ataque ao mesmo operador. Outro ponto crítico destacado é o uso do force push  como vetor de ataque. Essa técnica reescreve completamente o histórico do repositório sem gerar pull requests ou registros visíveis na interface do GitHub, tornando o ataque praticamente invisível para muitos fluxos tradicionais de revisão de código. A campanha também atingiu diretamente o ecossistema npm. Dois pacotes React Native react-native-international-phone-number  e react-native-country-select foram comprometidos e tiveram versões maliciosas publicadas diretamente no registro, sem passar pelo fluxo padrão de release no GitHub. Essas versões incluíam scripts executados durante a instalação ( preinstall hooks ), responsáveis por iniciar o ataque. Assim como na variante Python, o código ignora sistemas russos, consulta uma carteira Solana para obter instruções e baixa malwares específcos para cada plataforma. Um dos aspectos mais sofisticados dessa variante é a execução do payload inteiramente em memória, sem gravação em disco. Em sistemas macOS e Linux, isso ocorre via função eval(), enquanto em outros ambientes é utilizado o sandbox vm.Script do Node.js. Além disso, o malware implementa um mecanismo de persistência leve, registrando um arquivo local que impede nova execução por até 48 horas, reduzindo a chance de detecção. A campanha GlassWorm evidencia uma evolução significativa nos ataques à cadeia de suprimentos, combinando comprometimento de contas, manipulação de histórico de código, uso de blockchain como infraestrutura de comando e técnicas avançadas de evasão. Para equipes de segurança, o caso mostra a necessidade de monitoramento contínuo de repositórios, validação de integridade de código e proteção rigorosa de credenciais de desenvolvedores.

Organizações ucranianas estão na mira de uma nova campanha de espionagem cibernética atribuída, com forte probabilidade, a hackers ligados à Rússia. A operação foi identificada pela equipe de inteligência LAB52, da S2 Grupo, que observou a atividade em fevereiro de 2026 e apontou semelhanças com uma campanha anterior associada ao grupo Laundry Bear, também rastreado como UAC-0190 ou Void Blizzard. De acordo com a análise , a ofensiva utiliza iscas com temas judiciais e beneficentes para instalar uma backdoor baseada em JavaScript, batizada de DRILLAPP , que roda por meio do navegador Microsoft Edge. O malware chama atenção por explorar recursos nativos do navegador para executar atividades de espionagem, incluindo upload e download de arquivos, captação de áudio pelo microfone e registro de imagens via webcam. A campanha foi identificada em duas versões distintas. Na primeira, vista no início de fevereiro, o ataque começa com um arquivo de atalho do Windows, no formato LNK , que cria um arquivo HTA  na pasta temporária do sistema. Em seguida, esse arquivo carrega um script remoto hospedado no Pastefy , um serviço legítimo de publicação de texto. Para garantir persistência no sistema comprometido, os arquivos LNK são copiados para a pasta de inicialização do Windows, permitindo que sejam executados automaticamente após a reinicialização da máquina. Durante esse processo, a vítima visualiza uma URL com iscas relacionadas à instalação do Starlink ou à fundação beneficente ucraniana Come Back Alive , estratégia que ajuda a dar aparência legítima à atividade maliciosa. Na etapa seguinte, o arquivo HTML é executado pelo Microsoft Edge em modo headless , ou seja, sem interface visível ao usuário. A partir daí, o navegador carrega o script ofuscado hospedado remotamente no Pastefy. O diferencial dessa técnica está no uso de parâmetros adicionais de execução, como --no-sandbox, --disable-web-security, --allow-file-access-from-files, --use-fake-ui-for-media-stream, --auto-select-screen-capture-source=true e --disable-user-media-security. Na prática, esses parâmetros reduzem proteções do navegador e permitem que o código malicioso tenha acesso ao sistema de arquivos local, além de capturar câmera, microfone e até conteúdo da tela sem exigir interação do usuário. Isso transforma o navegador em uma espécie de ferramenta de acesso remoto improvisada, mas com uma aparência muito menos suspeita do que a de um malware tradicional. Segundo a investigação, a DRILLAPP funciona como uma backdoor leve, projetada para facilitar o acesso a arquivos e a coleta de dados sensíveis por meio dos próprios recursos do navegador. Além disso, o malware gera uma impressão digital do dispositivo na primeira execução usando uma técnica conhecida como canvas fingerprinting . Esse identificador é então combinado com dados do país da vítima, inferido a partir do fuso horário da máquina. O código verifica especificamente fusos horários ligados a países como Reino Unido, Rússia, Alemanha, França, China, Japão, Estados Unidos, Brasil, Índia, Ucrânia, Canadá, Austrália, Itália, Espanha e Polônia. Caso não encontre correspondência, o sistema define o país como Estados Unidos por padrão. Esse tipo de coleta ajuda os invasores a classificar os alvos e adaptar o controle da operação. A segunda variante da campanha, detectada no fim de fevereiro de 2026, abandonou o uso de arquivos LNK e passou a explorar módulos do Painel de Controle do Windows , mantendo, porém, a mesma lógica geral de infecção. Nessa nova versão, a própria backdoor também recebeu melhorias, passando a suportar enumeração recursiva de arquivos, envio em lote de múltiplos arquivos e download arbitrário de conteúdo. Um dos pontos mais relevantes destacados pela análise envolve a forma como os hackers contornam limitações do JavaScript. Em condições normais, scripts executados no navegador não conseguem baixar arquivos remotos livremente por razões de segurança. Para superar essa restrição, os operadores da campanha passaram a explorar o Chrome DevTools Protocol (CDP) , um protocolo interno presente em navegadores baseados em Chromium. Esse recurso só pode ser utilizado quando o navegador é iniciado com o parâmetro --remote-debugging-port habilitado. Essa escolha técnica mostra que os invasores estão testando abordagens menos convencionais para evitar detecção por ferramentas tradicionais de segurança. Em vez de recorrer apenas a binários maliciosos clássicos, a operação transforma um processo amplamente confiável e rotineiro o navegador web em uma plataforma de espionagem. Outro indício de que o malware ainda está em desenvolvimento apareceu em uma variante preliminar identificada em 28 de janeiro de 2026. Nessa versão inicial, o código apenas se comunicava com o domínio gnome[.]com, sem ainda baixar a carga principal hospedada no Pastefy. Isso sugere uma fase de teste ou amadurecimento da operação antes da implantação mais completa observada em fevereiro. A avaliação do caso reforça uma tendência importante no cenário de ameaças: o uso de softwares legítimos e amplamente presentes nos ambientes corporativos como cobertura para ações de espionagem. No caso da DRILLAPP, o Microsoft Edge oferece exatamente o tipo de camuflagem que os hackers procuram: é um processo comum, pouco suspeito, com permissões amplas e recursos avançados que, quando abusados, podem abrir caminho para coleta silenciosa de informações sensíveis. Mais do que uma simples nova amostra de malware, a DRILLAPP mostra como campanhas de espionagem modernas estão evoluindo para explorar funcionalidades internas de aplicações confiáveis. Para equipes de defesa, isso amplia o desafio de detecção, já que o comportamento malicioso pode ficar escondido dentro de processos legítimos do sistema operacional e do navegador, dificultando a diferenciação entre uso normal e atividade comprometida.

Com o aumento recente no preço da memória RAM, especialistas recomendam que usuários e administradores de sistemas explorem melhor os recursos disponíveis nos sistemas operacionais para otimizar o uso da memória existente. No Linux, dois mecanismos se destacam nesse cenário: zram  e zswap , tecnologias que utilizam compressão de memória para reduzir o impacto da falta de RAM. Ambos funcionam em conjunto com o mecanismo de swap , responsável por mover dados da memória para armazenamento quando o sistema começa a ficar sem RAM disponível. Embora muitos usuários acreditem que computadores com muita memória não precisam de swap, especialistas alertam que manter algum espaço de swap configurado continua sendo importante para evitar travamentos e garantir estabilidade em situações de uso extremo. O zram cria um dispositivo de swap diretamente na memória RAM, mas com dados compactados. Na prática, quando o sistema precisa liberar espaço, ele comprime os dados em vez de gravá-los diretamente no disco. Como a compressão geralmente reduz o tamanho dos dados pela metade e o acesso à RAM é muito mais rápido que ao armazenamento, o sistema consegue manter mais processos ativos com melhor desempenho. Esse mecanismo é particularmente útil em dispositivos com armazenamento lento ou limitado, como computadores com eMMC, microSD ou single-board computers como Raspberry Pi, além de sistemas com pouca memória disponível. Já o zswap  funciona de forma diferente. Em vez de substituir o swap em disco, ele atua como uma camada intermediária de compressão , armazenando temporariamente páginas de memória compactadas antes que sejam gravadas no disco. Isso reduz significativamente a quantidade de dados enviados ao swap tradicional e melhora a performance geral do sistema. Uma diferença importante é que zram e zswap não devem ser usados ao mesmo tempo, pois ambos tentam resolver o mesmo problema compressão de memória e acabam duplicando operações, desperdiçando recursos e anulando os ganhos de desempenho. Na prática, algumas distribuições Linux modernas já utilizam essas técnicas por padrão. O Fedora, por exemplo, habilita zram automaticamente, enquanto outras distribuições permitem ativar zswap com poucas alterações na configuração do bootloader. Diante da tendência de aumento no custo de memória e da demanda crescente por recursos computacionais impulsionada, entre outros fatores, por aplicações de inteligência artificial ferramentas como zram e zswap podem ajudar usuários a extrair mais desempenho de sistemas existentes sem precisar investir imediatamente em upgrades de hardware.