← Voltar ao blog

Security Briefing, 26 de abril de 2026: malware Snow entregue via Teams, violação da ADT ligada à ShinyHunters e janela de exploração de 13 horas do LMDeploy

O padrão de hoje é direto: atacantes estão abusando de chat confiável, identidade SaaS confiável e infraestrutura AI confiável mais rápido do que muitas equipes conseguem corrigir ou verificar.

---

---

1. UNC6692 transforma a confiança de helpdesk no Microsoft Teams em uma cadeia completa do malware Snow

O Google Mandiant afirma que o UNC6692 usa bombardeio de e-mails e impersonação no Microsoft Teams para pressionar funcionários a instalar um falso patch anti-spam. A vítima, na verdade, executa o conjunto Snow: a extensão de navegador SnowBelt, o túnel SnowGlaze e o backdoor em Python SnowBasin. A partir daí, os operadores despejam LSASS, movem-se lateralmente, alcançam controladores de domínio e exfiltram material do Active Directory. Isso não é apenas mais um phishing; é um caminho de intrusão nativo do chat disfarçado de suporte interno.

• Trate qualquer abordagem inesperada de TI via Teams como hostil até validação fora de banda.
• Correlacione telemetria de Quick Assist, suporte remoto, tarefas agendadas e extensões de navegador em conjunto.
• Se o falso patch foi executado, assuma roubo de identidade e movimento lateral.

---

2. ADT confirma violação após a ShinyHunters supostamente obter acesso por vishing a uma conta de funcionário ligada ao Okta

A ADT diz que atacantes roubaram dados de clientes e potenciais clientes, incluindo nomes, telefones, endereços e, em uma parcela menor, datas de nascimento e os últimos quatro dígitos de SSNs ou IDs fiscais. A ShinyHunters disse à BleepingComputer que a intrusão começou com um ataque de vishing contra uma conta SSO do Okta e depois se expandiu para o Salesforce. Mesmo que nem toda alegação do atacante esteja correta, a lição operacional é óbvia: quando uma identidade SaaS confiável cai, toda a plataforma de negócio conectada vira raio de impacto.

• Endureça a verificação por voz e os fluxos de retorno de chamada em todo processo de helpdesk e recuperação de identidade.
• Investigue logs de Okta, Salesforce e outros SaaS como um único incidente, não como tickets separados.
• Revise agora privilégio mínimo e monitoramento de exportações para plataformas de CRM e suporte.

---

3. LMDeploy mostra que a janela de exploração AI está encolhendo para horas

A falha SSRF do LMDeploy, CVE-2026-33626, teria sido explorada em 12 horas e 31 minutos após a divulgação. Atacantes usaram o carregador de imagens vision-language para sondar metadados AWS, Redis, MySQL, superfícies administrativas locais e um endpoint externo de callback. Isso importa porque o LMDeploy é exatamente o tipo de componente de serving de LLM que equipes implantam rápido e revisam pouco. Quando um advisory entrega a causa raiz e o caminho de código afetado, atacantes não esperam o seu próximo sprint.

• Aplique patch ou desative imediatamente implantações vulneráveis de LMDeploy vision-language.
• Bloqueie por padrão que caminhos de model serving alcancem metadados de nuvem e serviços administrativos internos.
• Trate servidores de inferência AI como infraestrutura exposta à internet, porque os atacantes já tratam assim.

---

O que as equipes de segurança devem fazer hoje

1. Trave fluxos de suporte baseados em Teams e reverifique eventos recentes de assistência remota.
2. Faça uma revisão de incidente de identidade SaaS se seu ambiente depende de Okta, Salesforce ou conectores de alta confiança semelhantes.
3. Inventarie componentes de AI expostos ou alcançáveis e corrija o LMDeploy antes da próxima onda de varredura.
4. Use esta manhã para fechar falhas de confiança, não apenas tickets.

---

---

Em resumo: O padrão de hoje é direto: atacantes estão abusando de chat confiável, identidade SaaS confiável e infraestrutura AI confiável mais rápido do que muitas equipes conseguem corrigir ou verificar.