A semana combinou vulnerabilidades em Gogs, Windows, Linux, PAN-OS, GitHub Enterprise Server e outros produtos com campanhas de smishing, RAT via Teams, abuso de OAuth e interrupção parcial da infraestrutura GlassWorm.
| Componente | Gogs, GlassWorm, Windows Netlogon, cliente CIFS do núcleo Linux com cifs-utils, fluxos OAuth, Microsoft Teams, Google Drive, WordPress comprometido e múltiplos produtos listados para correção. |
| Vetor | Exploração por repositórios e ramos maliciosos, abuso de marketplace e pacotes, phishing por código de dispositivo OAuth, engenharia social por Teams, smishing, varredura de interfaces de gerenciamento e falhas expostas à rede. |
| Impacto | Execução de comandos, elevação local de privilégio, controle remoto persistente, mineração de criptomoedas, coleta de credenciais, acesso a repositórios privados, interrupção temporária de C2 e risco de exploração acelerada por automação e IA. |
| Prioridade | Priorizar correções em ativos expostos, revisar repositórios e extensões de desenvolvimento, auditar fluxos OAuth, bloquear abuso de acesso remoto e caçar sinais de GlassWorm, Nimbus RAT, smishing e varreduras contra SonicWall SonicOS. |
| Versões e produtos | A lista inclui CVEs em WP Maps Pro, Palo Alto Networks PAN-OS e Prisma Access, Gitea, SharePoint, Casdoor, Notepad++, Flowise, Chrome, Veeam Backup & Replication, Plesk, GitLab, Oracle, Samba, Windows 11, OpenVPN Connect para macOS, GitHub Enterprise Server, BIND 9, Memcached, Apache CXF, ConnectWise Automate, PuTTY, 7-Zip e Roundcube Webmail. |
| IoCs | Para GlassWorm, conexões ao IP benigno 164.92.88[.]210 foram indicadas como sinal de possível host infectado instruído a beaconar após a ação coordenada de derrubada. |
O panorama técnico da semana mostra uma convergência de riscos que afeta servidores Git auto-hospedados, estáções de trabalho, ambientes Linux, plataformas de colaboração, identidade federada, extensões de desenvolvimento e interfaces administrativas expostas. O ponto comum não é uma única campanha, mas a redução do intervalo entre divulgação, correção e tentativa de abuso. Falhas já corrigidas aparecem junto de vulnerabilidades sem patch, enquanto operadores continuam explorando caminhos de baixo custo: contas criadas por padrão, ramos de repositório manipulados, marketplaces de extensões, fluxos OAuth projetados para dispositivos, sites WordPress comprometidos e ferramentas legítimas de suporte remoto.
A lista de correções destacada inclui vulnerabilidades em WP Maps Pro, PAN-OS e Prisma Access, Gitea, SharePoint, Casdoor, Notepad++, Flowise, Chrome, Veeam Backup & Replication, Plesk, GitLab, Oracle, Samba, Windows 11, OpenVPN Connect para macOS, GitHub Enterprise Server, BIND 9, Memcached, Apache CXF, ConnectWise Automate, PuTTY, 7-Zip, Roundcube Webmail, Gogs e a extensão Remote-SSH do Microsoft Visual Studio Code. Para defesa, a leitura operacional é direta: inventário, exposição externa, criticidade do ativo e evidência de exploração precisam guiar a fila de correção, não apenas a severidade nominal.
A ocorrência de maior risco operacional envolve o Gogs, serviço Git auto-hospedado de código aberto. A falha crítica foi descrita como uma vulnerabilidade de injeção explorável por atacantes autenticados por meio de pull requests com nomes de ramos maliciosos. O cenário se agrava porque instâncias em configuração padrão podem permitir registro aberto e criação irrestrita de repositórios. Nessa condição, um atacante sem conta prévia pode criar identidade e repositório, ajustar a configuração necessária para rebase merge e acionar a cadeia sem depender da interação de outro usuário.
O impacto informado é execução arbitrária de comandos no contexto do processo do servidor Gogs. Esse limite técnico já é suficiente para tratar o caso como prioridade máxima em ambientes expostos, pois o processo pode ter acesso amplo aos repositórios hospedados. O risco descrito inclui leitura de repositórios privados de outros usuários, coleta de hashes de senha, tokens de API, chaves SSH, segredos de segundo fator, modificação de código hospedado e pivô para sistemas alcançáveis pela rede. Instâncias em Windows, Linux e macOS com configurações padrão foram indicadas como afetadas, e não havia correção disponível no momento da publicação.
- Revisar imediatamente exposição pública de instâncias Gogs.
- Desabilitar registro aberto quando não for indispensável.
- Restringir criação de repositórios e permissões de rebase merge.
- Auditar pull requests recentes com nomes de ramos incomuns.
A operação GlassWorm sofreu uma interrupção coordenada quando quatro canais de comando e controle foram derrubados simultaneamente em 26 de maio de 2026, às 14h UTC. A campanha era conhecida por usar extensões trojanizadas do VS Code distribuídas no Microsoft VS Code Marketplace e no Open VSX, além de introduzir código malicioso por pacotes npm e Python comprometidos. A ação cortou a capacidade dos operadores de enviar novos comandos aos hosts infectados naquele momento, mas não elimina a possibilidade de retorno sob novas contas, domínios, pacotes ou extensões.
A atribuição técnica apresentada permanece baseada em sinais observados no malware, incluindo verificação de localidade para evitar infecção em países da Comunidade de Estados Independentes e comentários em russo no código. Esses elementos apontam para origem russa, mas devem ser tratados como indicadores, não como prova isolada de autoria estatal. Um elemento útil para hunting é o beacon para o endereço benigno 164.92.88[.]210, usado após a ação de contenção. Conexões a esse destino devem ser tratadas como sinal de que um endpoint pode ter recebido instruções relacionadas à contenção de GlassWorm.
- Buscar extensões do VS Code instaladas fora de processos aprovados.
- Verificar pacotes npm e Python adicionados recentemente em ambientes de desenvolvimento.
- Investigar tráfego para 164.92.88[.]210 como possível sinal de endpoint previamente afetado.
- Rotacionar segredos usados em estáções de desenvolvimento suspeitas.
A semana também trouxe três frentes ligadas a IA. A primeira é regulatória e operacional: o CERT-In recomendou que organizações na Índia corrijam vulnerabilidades exploradas ativamente em sistemas expostos à internet ou ativos críticos em até 12 horas quando viável. O órgão não apresentou o prazo como obrigação rígida, mas como expectativa indicativa baseada em criticidade e exposição. A justificativa é que ataques assistidos por IA estão comprimindo o intervalo entre divulgação e exploração, exigindo processos de triagem e correção mais rápidos.
A segunda frente envolve o grupo GREYVIBE, descrito como uma atividade russa ainda não documentada anteriormente e ativa desde agosto de 2025 contra organizações privadas, governamentais e militares na Ucrânia. O objetivo indicado é coleta de inteligência no contexto da guerra. O uso de modelos de linguagem pelo grupo foi descrito como integrado à operação, não apenas experimental. A terceira frente envolve campanhas que manipulam recomendações de chatbots para direcionar usuários que pesquisam ferramentas populares a sites suspeitos, onde executáveis adulterados instalam minerador de criptomoeda e podem implantar ScreenConnect para acesso remoto persistente.
O CVE-2026-41089, já corrigido pela Microsoft no Patch Tuesday de maio de 2026, entrou em exploração ativa conforme alerta do Centro de Cibersegurança da Bélgica. A vulnerabilidade é um estouro de buffer baseado em pilha no Windows Netlogon e permite que um atacante não autorizado execute código pela rede. Como não há detalhes públicos no contexto sobre a técnica de exploração, a defesa deve evitar inferir pré-condições adicionais, payloads ou sequência de ataque. A priorização deve partir da natureza remota, do componente de autenticação envolvido e da confirmação de exploração no ambiente externo.
Para equipes de Windows, a primeira resposta é verificar cobertura do ciclo de atualização de maio de 2026 nos servidores e estáções que exponham serviços associados ao domínio. O hunting deve se concentrar em falhas anômalas de Netlogon, tentativas de conexão incomuns a partir de redes não esperadas, reinicializações ou travamentos próximos a tráfego suspeito e criação de processos fora do padrão após eventos de autenticação. Sem detalhes de exploração, a telemetria comportamental e a validação de patch são mais confiáveis do que assinaturas específicas.
A vulnerabilidade CIFSwitch foi descrita como elevação local de privilégio no Linux, explorando uma falha lógica entre o cliente CIFS do núcleo Linux e o pacote de espaço de usuário cifs-utils. O bug do lado do núcleo teria existência desde 2007, e a correção foi incorporada à linha principal do Linux em 19 de maio de 2026. O impacto informado é a possibilidade de um usuário de baixo privilégio obter acesso root, o que muda a classificação operacional: não é um vetor inicial remoto por si só, mas aumenta muito o risco quando combinado com contas locais, workloads multiusuário, shells obtidos por outros meios ou ambientes onde montagens CIFS são usadas.
A superfície mais relevante são sistemas Linux que utilizam CIFS e têm usuários ou processos de baixa confiança capazes de interagir com caminhos de montagem e utilitários associados. A contenção deve priorizar atualização do núcleo quando o patch estiver disponível pela distribuição, revisão de permissões locais e restrição de contas que possam acionar o caminho vulnerável. Em ambientes de produção, eventos de elevação incomuns, alterações de identidade efetiva, execução anômala de utilitários CIFS e mudanças de permissões em torno de montagens de rede são sinais úteis para investigação.
O abuso de identidade apareceu em múltiplos formatos. A plataforma EvilTokens foi associada a campanhas de phishing-as-a-service que exploram o fluxo OAuth 2.0 de autorização por dispositivo em escala. Esse fluxo é legítimo, mas quando usado em phishing permite induzir a vítima a autorizar sessões sem entregar senha diretamente ao site falso. A automação e a geração rápida de infraestrutura por IA tornam a operação mais replicável. Em paralelo, o kit RatPressto surgiu em campanha ativa hospedada em sites WordPress legítimos comprometidos, servindo ScreenConnect para estabelecer acesso remoto persistente e mirando organizações financeiras para coleta silenciosa de credenciais, segredos e dados sensíveis.
Outro caso envolveu Microsoft Teams em uma intrusão contra um cliente do setor jurídico. O atacante usou vishing por voz dentro do Teams para convencer a vítima a conceder acesso remoto via Quick Assist. Em menos de 20 minutos, a cadeia avançou até a execução do Nimbus RAT, implante em Java que usa Google Drive e Google Sheets como canal de comando e controle para parecer tráfego legítimo. A atividade foi comparada a padrões de engenharia social associados a afiliados BlackSuit, mas a defesa deve focar no comportamento: contato inesperado no Teams, sessão de suporte remoto não aprovada, execução de Java fora do padrão e tráfego para serviços Google usado como canal operacional.
- Monitorar concessões OAuth por fluxo de dispositivo com origem, usuário e aplicativo fora do padrão.
- Bloquear ou controlar Quick Assist e ScreenConnect quando não houver necessidade operacional.
- Investigar sites WordPress internos ou parceiros usados como ponto de entrega de ferramentas remotas.
- Revisar execuções de Java que iniciem comunicação recorrente com Google Drive ou Google Sheets.
Uma operação coordenada de smishing foi identificada em 19 países na Europa, nas Américas e no Cáucaso, com 1.628 URLs maliciosas ativas confirmadas. A mesma infraestrutura teria sido usada contra contribuintes na Romênia, clientes de entrega DPD no Reino Unido e na Irlanda, portais de polícia rodoviária na Bulgária e na Armênia, autoridades fiscais na Grécia e usuários da T-Mobile nos Estados Unidos. A técnica social central é urgência falsa: multas inventadas, cobranças e mensagens que pressionam o usuário a realizar pagamento ou inserir informações pessoais.
A defesa deve tratar esse tipo de campanha como problema de identidade, marca e telemetria de mensagens, não apenas bloqueio de URL. Domínios recém-criados, páginas que imitam órgãos públicos ou empresas de entrega, tráfego móvel originado por SMS e picos de reclamações em canais de atendimento são sinais relevantes. Para resposta, é importante acionar provedores de hospedagem, equipes de marca, filtros de SMS, bancos e times antifraude, além de preservar exemplos defangados para correlação sem distribuir links ativos.
A pesquisa FROST, abreviação de Fingerprinting Remotely using OPFS-based SSD Timing, descreveu um canal lateral em JavaScript que explora medições de contenção em SSD via Origin Private File System. O ataque pode medir variações muito pequenas no tempo de acesso ao armazenamento para inferir atividade do usuário no sistema, incluindo visitas a sites e uso de aplicações, após a vítima clicar em um link malicioso. O estudo indicou funcionamento em Linux e macOS, sem necessidade de interação posterior.
O impacto não é execução de código nem vazamento direto de arquivos, mas exposição de padrões de atividade local que podem ser úteis para rastreamento e perfilamento. Para equipes de segurança de navegadores e privacidade, o ponto técnico é reduzir precisão de temporização, revisar isolamento de recursos locais acessíveis a JavaScript e monitorar abuso de APIs de armazenamento em páginas não confiáveis. Em ambientes corporativos de alto risco, políticas de navegação, isolamento por navegador e controles contra sites desconhecidos continuam sendo medidas relevantes.
A Dashlane informou que contas de usuários foram alvo de ataque de força bruta por uma parte externa. As contas impactadas foram suspensas pelos mecanismos de segurança da própria plataforma e depois liberadas. Não houve evidência apresentada de comprometimento dos sistemas da Dashlane, e a autoria não foi identificada. O caso deve levar organizações a revisar tentativas de login repetidas, reutilização de credenciais e adoção de autenticação multifator nos cofres de senha.
Também houve relato de exploit no Instagram que teria permitido redefinição de senhas por meio do Meta AI em contas sem autenticação multifator. O problema foi indicado como corrigido, mas a natureza pública do relato exige cautela na formulação: trata-se de alegação de exploração já remediada, sem detalhes técnicos adicionais no material. Para usuários e organizações, a ação defensiva concreta é exigir MFA em contas sensíveis e revisar eventos recentes de redefinição de senha.
A GreyNoise registrou aumento relevante de varredura contra interfaces de gerenciamento SonicWall SonicOS entre 9 e 18 de maio de 2026. Aproximadamente 56% das sessões vieram de redes anunciadas na Holanda e 44% da Ucrânia, com um único ASN, AS211736, respondendo por cerca de metade do volume. Em paralelo, famílias de ransomware como NightSpire e Payload foram analisadas, com Payload acumulando 50 vítimas em site de vazamento desde fevereiro de 2026 e alvos observados no Egito, México e Polônia.
A superfície exposta nesta semana cobre quatro grupos principais. O primeiro reúne ativos diretamente exploráveis ou altamente sensíveis, como Gogs, Windows Netlogon, PAN-OS, Prisma Access, SharePoint, GitHub Enterprise Server, BIND 9, Memcached, Apache CXF, ConnectWise Automate, Plesk, GitLab, Oracle, Samba e Roundcube Webmail. O segundo envolve estáções de desenvolvimento e pipelines, com extensões VS Code, pacotes npm e Python, Remote-SSH do VS Code, Gitea, Gogs e repositórios que podem carregar segredos e código de produção.
O terceiro grupo é identidade e colaboração: OAuth por fluxo de dispositivo, Teams, Quick Assist, ScreenConnect, Dashlane e contas Instagram sem MFA. O quarto é exposição de usuário final e navegação, incluindo smishing, FROST, executáveis adulterados distribuídos por sites recomendados por chatbots e ferramentas amplamente instaladas como Notepad++, Chrome, PuTTY, 7-Zip e OpenVPN Connect para macOS. A priorização deve considerar exposição externa, presença de exploração ativa, capacidade de execução de código, privilégio obtido e proximidade com segredos.
- Servidores Gogs com registro aberto, criação livre de repositórios e rebase merge habilitável.
- Hosts Windows sem atualização de maio de 2026 para CVE-2026-41089.
- Sistemas Linux que usam CIFS e
cifs-utilscom usuários locais de baixa confiança. - Estáções de desenvolvimento com extensões VS Code e pacotes npm ou Python não validados.
- Tenants com OAuth por fluxo de dispositivo sem monitoramento granular.
- Ambientes que permitem Quick Assist ou ScreenConnect fora de processos aprovados.
O hunting deve começar pelos sinais de maior especificidade. Em Gogs, procurar criação recente de contas e repositórios, alterações de configuração de merge, pull requests com nomes de ramos incomuns e processos filhos inesperados originados pelo serviço. Em GlassWorm, revisar extensões instaladas no VS Code, pacotes npm e Python recém-adicionados, segredos acessados em estáções de desenvolvimento e conexões ao IP 164.92.88[.]210 como marcador de possível host infectado envolvido na contenção.
Para identidade, correlacionar concessões OAuth por fluxo de dispositivo, logins com usuário pressionado por mensagens externas, sessões de Quick Assist, instalação ou execução de ScreenConnect e chamadas do Teams que antecedam mudanças de endpoint. No caso Nimbus RAT, tráfego recorrente para Google Drive e Google Sheets a partir de processos Java deve receber atenção quando não houver justificativa de negócio. Para smishing, combinar telemetria de SMS, DNS, proxy, reclamações de usuários e domínios que imitam órgãos públicos, entregas, telecomunicações ou pagamentos.
Em vulnerabilidades de infraestrutura, validar patch de Windows Netlogon, monitorar travamentos ou execuções anômalas em torno de serviços de domínio, revisar exposição de interfaces SonicWall SonicOS e correlacionar origens relacionadas à Holanda, Ucrânia e AS211736 quando aparecerem na própria telemetria. Para CIFSwitch, procurar mudanças de privilégio local, uso incomum de utilitários CIFS e eventos próximos a montagens de rede em hosts Linux.
- Processos filhos inesperados do serviço Gogs.
- Pull requests com nomes de ramos fora do padrão operacional.
- Conexões para 164.92.88[.]210 em endpoints de desenvolvimento.
- Concessões OAuth por código de dispositivo em aplicativos não aprovados.
- Sessões Quick Assist ou ScreenConnect iniciadas após contato por Teams.
- Execução de Java com comunicação recorrente a Google Drive ou Google Sheets.
- Picos de varredura contra SonicWall SonicOS em interfaces de gerenciamento.
- Eventos de elevação local próximos a uso de CIFS em Linux.
A resposta deve ser orientada por risco mensurável. Para Gogs, como não havia patch no momento da publicação, a mitigação precisa reduzir exposição e pré-condições: retirar instâncias da internet quando possível, desabilitar registro aberto, limitar criação de repositórios, restringir rebase merge, revisar permissões de escrita e auditar repositórios privados e segredos acessíveis ao processo. Para Windows Netlogon, aplicar a atualização de maio de 2026 e confirmar cobertura em controladores e sistemas relevantes. Para CIFSwitch, acompanhar pacotes do fornecedor da distribuição, aplicar núcleo corrigido quando disponível e reduzir privilégios locais em hosts com CIFS.
Em cadeia de desenvolvimento, bloquear extensões não aprovadas, revisar origem de pacotes npm e Python, invalidar tokens expostos em estáções suspeitas e exigir lockfiles e revisão de dependências. Em identidade, restringir o fluxo OAuth de dispositivo quando não for necessário, alertar concessões incomuns, impor MFA e controlar ferramentas de acesso remoto. Para Teams, Quick Assist e ScreenConnect, a política deve definir quem pode iniciar suporte, quais binários são permitidos e quais eventos exigem resposta imediata.
Para smishing e phishing hospedado em WordPress comprometido, a mitigação envolve bloqueio de domínios defangados nos controles internos, notificação a usuários, remoção junto a provedores e monitoramento de marcas imitadas. Para GlassWorm, a derrubada de C2 deve ser tratada como janela de contenção, não como encerramento definitivo. Hosts suspeitos precisam passar por isolamento, coleta de evidências, rotação de segredos e reconstrução quando a integridade do ambiente de desenvolvimento não puder ser comprovada.
- Inventariar os produtos listados e ordenar correção por exposição externa e exploração ativa.
- Aplicar patch de Windows Netlogon referente ao CVE-2026-41089.
- Endurecer Gogs removendo registro aberto e reduzindo permissões de repositório até haver correção.
- Atualizar Linux quando a correção de CIFSwitch chegar à distribuição usada.
- Restringir OAuth por fluxo de dispositivo e revisar concessões recentes.
- Controlar Quick Assist e ScreenConnect por política, allowlist e telemetria.
- Rotacionar segredos de estáções de desenvolvimento com suspeita de GlassWorm.
- Bloquear e reportar domínios de smishing sem publicar links ativos para usuários.
0 Comentários