← Volver al blog

Security Briefing, 26 de abril de 2026: malware Snow entregado por Teams, brecha de ADT ligada a ShinyHunters y ventana de explotación de 13 horas en LMDeploy

El patrón de hoy es directo: los atacantes están abusando del chat de confianza, de la identidad SaaS de confianza y de la infraestructura AI de confianza más rápido de lo que muchos equipos pueden parchear o verificar.

---

---

1. UNC6692 convierte la confianza en el helpdesk de Microsoft Teams en una cadena completa del malware Snow

Google Mandiant dice que UNC6692 usa bombardeo de correo e impersonación en Microsoft Teams para presionar a empleados a instalar un falso parche anti-spam. La víctima en realidad ejecuta el conjunto Snow: la extensión de navegador SnowBelt, el túnel SnowGlaze y la puerta trasera Python SnowBasin. Desde ahí, los operadores vuelcan LSASS, se mueven lateralmente, alcanzan controladores de dominio y exfiltran material de Active Directory. No es solo otro phishing; es una ruta de intrusión nativa del chat disfrazada de soporte interno.

• Trata cualquier contacto inesperado de IT por Teams como hostil hasta verificarlo fuera de banda.
• Revisa en conjunto la telemetría de Quick Assist, soporte remoto, tareas programadas y extensiones de navegador.
• Si se ejecutó el falso parche, asume robo de identidad y movimiento lateral.

---

2. ADT confirma una brecha tras el supuesto phishing por voz de una cuenta de empleado respaldada por Okta

ADT dice que atacantes robaron datos de clientes y prospectos, incluidos nombres, números de teléfono, direcciones y, en un subconjunto menor, fechas de nacimiento y los últimos cuatro dígitos de SSN o identificadores fiscales. ShinyHunters dijo a BleepingComputer que la intrusión comenzó con un ataque de vishing contra una cuenta SSO de Okta y luego se expandió a Salesforce. Aunque no todas las afirmaciones del atacante sean ciertas, la lección operativa es obvia: cuando cae una identidad SaaS de confianza, toda la plataforma de negocio conectada se convierte en radio de impacto.

• Endurece la verificación por voz y devolución de llamada en cada flujo de helpdesk y recuperación de identidad.
• Investiga Okta, Salesforce y otros logs SaaS como un solo incidente, no como tickets separados.
• Vuelve a revisar privilegio mínimo y monitoreo de exportaciones en CRM y plataformas de soporte ahora mismo.

---

3. LMDeploy demuestra que la ventana de explotación AI se está derrumbando a horas

La falla SSRF de LMDeploy, CVE-2026-33626, habría sido explotada dentro de 12 horas y 31 minutos tras su divulgación. Los atacantes usaron el cargador de imágenes vision-language para sondear metadatos de AWS, Redis, MySQL, superficies administrativas locales y un endpoint de callback externo. Eso importa porque LMDeploy es exactamente el tipo de componente de serving de LLM que los equipos despliegan rápido y revisan poco. Cuando una advisory entrega la causa raíz y la ruta de código afectada, los atacantes no esperan a tu próximo sprint.

• Parchea o deshabilita de inmediato los despliegues vulnerables de LMDeploy vision-language.
• Bloquea por defecto que las rutas de model serving alcancen metadatos cloud y servicios administrativos internos.
• Trata los servidores de inferencia AI como infraestructura expuesta a internet, porque los atacantes ya lo hacen.

---

Qué deben hacer hoy los equipos de seguridad

1. Asegura los flujos de soporte basados en Teams y vuelve a verificar eventos recientes de asistencia remota.
2. Ejecuta una revisión de incidente de identidad SaaS si tu entorno depende de Okta, Salesforce o conectores de alta confianza similares.
3. Inventaria componentes de AI expuestos o alcanzables y parchea LMDeploy antes de la próxima ola de escaneo.
4. Usa esta mañana para cerrar brechas de confianza, no solo tickets.

---

---

Conclusión: El patrón de hoy es directo: los atacantes están abusando del chat de confianza, de la identidad SaaS de confianza y de la infraestructura AI de confianza más rápido de lo que muchos equipos pueden parchear o verificar.