Entradas de blog etiquetadas con ' #cybersecurity ' Rss

KATARU... está atacanto a Linux?

KATARU es una variante de malware para IoT y Linux que ataca dispositivos con servicios Telnet expuestos y credenciales débiles o predeterminadas. Tras obtener acceso, descarga y ejecuta una carga útil maliciosa e intenta obtener privilegios de administrador mediante vulnerabilidades conocidas de Linux.

Una vez establecido, KATARU instala mecanismos de persistencia que le permiten sobrevivir a los reinicios y mantener el acceso a largo plazo. Utiliza comunicaciones de comando y control cifradas para evadir la detección y puede lanzar ataques DDoS, realizar ataques de fuerza bruta SSH, ejecutar comandos remotos y descargar malware adicional.

¿Por qué es digno de mención?

KATARU combina vulnerabilidades de seguridad de larga data, como servicios Telnet expuestos, contraseñas débiles y sistemas Linux sin parchear, con capacidades de malware modernas, como comunicaciones C2 cifradas y acceso persistente de nivel root. A diferencia de muchas botnets de IoT de corta duración, KATARU está diseñado para mantener el control a largo plazo de los dispositivos comprometidos. Este malware demuestra cómo los ciberdelincuentes pueden combinar herramientas y exploits disponibles públicamente para crear ataques efectivos y escalables.

Para las organizaciones con entornos de IoT o OT, KATARU refuerza la importancia de la aplicación de parches, el endurecimiento de la seguridad y una gestión sólida de las credenciales.

¿Cuál es la exposición o el riesgo?

Las organizaciones se enfrentan al mayor riesgo cuando los dispositivos IoT o Linux conectados a internet tienen Telnet habilitado, utilizan credenciales débiles o ejecutan firmware y sistemas operativos obsoletos. Una vez comprometidos, los dispositivos pueden formar parte de una botnet utilizada para ataques DDoS a gran escala y otras actividades maliciosas. Dado que KATARU incluye capacidades de escalada de privilegios y persistencia, las infecciones pueden sobrevivir a los reinicios y ser difíciles de eliminar.

El malware afecta a una amplia gama de dispositivos basados en Linux, incluidos routers, equipos IoT y otros sistemas conectados. Los dispositivos sin parchear o sin soporte pueden proporcionar a los atacantes una ventaja a largo plazo en el entorno.

¿Cómo pueden los compradores de software proteger las aplicaciones codificadas con Vibe?

Los compradores de software deben asumir que algunos componentes de las nuevas aplicaciones que utilicen en 2026 podrían haber sido codificados con Vibe. Esto no significa que contengan vulnerabilidades por defecto, sino que deben tomar medidas para limitar las consecuencias de cualquier aplicación que pueda contener un error de codificación explotable. En otras palabras, deben adoptar protocolos de seguridad de confianza cero.

La seguridad de confianza cero surgió antes de la IA, partiendo de la premisa de que cada usuario y aplicación era potencialmente vulnerable. En la era de la IA, podemos asumir que cada aplicación está potencialmente comprometida mediante código Vibe, y que cada aplicación con código Vibe posee vulnerabilidades explotables.

Puedes examinar rigurosamente cada aplicación de tu infraestructura para detectar estas vulnerabilidades, pero:

• Esto requiere un tiempo del que no dispones.
• Incluso la revisión más exhaustiva puede pasar por alto vulnerabilidades.
• Sus usuarios están incorporando aplicaciones codificadas con Vibe sin la aprobación del departamento de TI porque la TI en la sombra nunca murió.
• Al tratar cada aplicación como sospechosa, puede diseñar su infraestructura para limitar el impacto de una vulnerabilidad explotada.

¿Cómo reduce el modelo de confianza cero los riesgos de seguridad del código generado por IA?

La arquitectura de confianza cero está diseñada para aplicar una autenticación mejorada a cada intercambio de datos y ubicar a los usuarios y las aplicaciones dentro de segmentos de red estrictamente definidos mediante perímetros definidos por software.

En la práctica, esto significa que cada aplicación, ya sea codificada con Vibe o no, se ubica dentro de su propio perímetro. Este perímetro define las formas en que una aplicación puede interactuar con usuarios, datos y otras aplicaciones. Además, garantiza que los privilegios normales de la aplicación solo incluyan las dependencias específicas que necesita para funcionar.

Esto garantiza que, si una aplicación contiene una vulnerabilidad explotable que es el objetivo de un atacante, la superficie de ataque potencial es mínima. Además, el atacante no podrá moverse lateralmente a otras aplicaciones ni escalar privilegios. Si bien la aplicación codificada con Vibe puede contener más vulnerabilidades, el atacante se limita al acceso más básico.

Recomendaciones para reducir el riesgo

• Desactive Telnet y proteja el acceso remoto. Utilice SSH u otros métodos de administración seguros y restrinja el acceso a redes de confianza o VPN.
• Utilice credenciales seguras y únicas. Elimine las contraseñas predeterminadas y limite el acceso administrativo siempre que sea posible.
• Actualiza el firmware y los núcleos de Linux. Aplica las últimas actualizaciones de seguridad a los dispositivos basados en Linux.
• Segmenta las redes de IoT y OT. Restringe las comunicaciones innecesarias y limita el acceso directo a internet.
• Aísle y reconstruya los dispositivos comprometidos. Desconecte los sistemas afectados, realice un restablecimiento de fábrica o reinstale el sistema operativo, y aplique las actualizaciones de seguridad antes de volver a conectarlos.
• Reemplace los dispositivos que ya no son compatibles. Retire el hardware que ya no puede recibir actualizaciones de seguridad o configurarse de forma segura.

Conoce más en el siguiente video

¿Por qué la seguridad del código generado por IA supone un riesgo empresarial real?

A medida que la IA ha ido ganando terreno en el ámbito laboral, se han producido numerosas brechas de seguridad relacionadas con vulnerabilidades en el código generado por IA:

• Moltbook, una red social con codificación Vibe para agentes de IA, nunca habilitó la seguridad a nivel de fila, exponiendo 1,5 millones de claves API.
• Una farmacia que utilizaba un sitio web con código Vibe expuso los mensajes de los pacientes a través de un formulario de contacto configurado incorrectamente.
• Una aplicación de codificación de ambientes conocida como "Orchids" contenía una vulnerabilidad que permitía a los investigadores de seguridad acceder de forma remota a los puntos finales de los usuarios.
• Los datos de encuestas y ejemplos reales sugieren que muchos desarrolladores utilizan ahora herramientas de IA para escribir código. Mientras tanto, las vulnerabilidades de software pueden tardar años en descubrirse. Por ello, es probable que las vulnerabilidades que hemos visto hasta ahora representen solo la punta del iceberg.

¿Cómo produce vulnerabilidades el código generado por IA?

Los modelos de codificación generados por IA se entrenan con código escrito por humanos. Parte de los datos de entrenamiento contienen vulnerabilidades. Por lo tanto, los modelos de IA pueden replicar estas mismas vulnerabilidades en producción.

La respuesta más extensa es que las herramientas de codificación de IA desconocen sus propias limitaciones. Es posible que al modelo de codificación no se le haya mostrado un ejemplo de cómo debe ser un código seguro en un contexto específico. Cuando un desarrollador le indica al modelo que "codifique este módulo de forma segura", el modelo produce un código que parece plausiblemente seguro, pero que en realidad contiene vulnerabilidades.

Cuando decimos "aparentemente seguro", nos referimos a que el código hace referencia a bibliotecas y utiliza configuraciones de seguridad. Sin embargo, tras un análisis más detallado, se observa que la biblioteca es incorrecta y que las configuraciones de seguridad están mal configuradas. Esto se debe a que la IA genera resultados similares a sus datos de entrenamiento, en lugar de crear algo nuevo.

Es importante señalar que las vulnerabilidades que produce el código generado por IA no son novedosas. Errores como credenciales expuestas, entradas sin validar y autenticación faltante son comunes en el código generado por humanos, por lo que también lo son en el código generado por IA.

¿Es posible detectar vulnerabilidades en aplicaciones codificadas con Vibe?

La buena noticia es que las vulnerabilidades codificadas mediante Vibe son lo suficientemente comunes como para detectarlas con el mismo tipo de pruebas de software y prácticas de desarrollo seguro que se utilizan para identificar errores e inseguridades en el código tradicional. Sin embargo, la mala noticia es que las prácticas de desarrollo seguro podrían ser menos frecuentes de lo que cabría esperar.

Un informe de la Linux Foundation revela que casi un tercio de los desarrolladores desconoce las prácticas de desarrollo seguro. Si bien la mayoría recibe capacitación en seguridad, esto puede tardar hasta cinco años. Además, las investigaciones demuestran que la mayoría de los desarrolladores saben que el código generado por IA que distribuyen probablemente contenga vulnerabilidades . Aproximadamente un tercio de los desarrolladores distribuirá este código de todos modos.

El problema radica en la presión. La codificación Vibe acelera el desarrollo de aplicaciones. Esto significa que una empresa de software competitiva puede lanzar su producto al mercado antes que nadie. Los desarrolladores pueden preocuparse de que las medidas de seguridad ralenticen el desarrollo sin aportar un valor real a los compradores. Por lo tanto, existe un incentivo importante para minimizar las comprobaciones de seguridad antes de que una aplicación entre en producción.

¿Cómo pueden los compradores de software proteger las aplicaciones codificadas con Vibe?

Los compradores de software deben asumir que algunos componentes de las nuevas aplicaciones que utilicen en 2026 podrían haber sido codificados con Vibe. Esto no significa que contengan vulnerabilidades por defecto, sino que deben tomar medidas para limitar las consecuencias de cualquier aplicación que pueda contener un error de codificación explotable. En otras palabras, deben adoptar protocolos de seguridad de confianza cero.

La seguridad de confianza cero surgió antes de la IA, partiendo de la premisa de que cada usuario y aplicación era potencialmente vulnerable. En la era de la IA, podemos asumir que cada aplicación está potencialmente comprometida mediante código Vibe, y que cada aplicación con código Vibe posee vulnerabilidades explotables.

Puedes examinar rigurosamente cada aplicación de tu infraestructura para detectar estas vulnerabilidades, pero:

• Esto requiere un tiempo del que no dispones.
• Incluso la revisión más exhaustiva puede pasar por alto vulnerabilidades.
• Sus usuarios están incorporando aplicaciones codificadas con Vibe sin la aprobación del departamento de TI porque la TI en la sombra nunca murió.
• Al tratar cada aplicación como sospechosa, puede diseñar su infraestructura para limitar el impacto de una vulnerabilidad explotada.

¿Cómo reduce el modelo de confianza cero los riesgos de seguridad del código generado por IA?

La arquitectura de confianza cero está diseñada para aplicar una autenticación mejorada a cada intercambio de datos y ubicar a los usuarios y las aplicaciones dentro de segmentos de red estrictamente definidos mediante perímetros definidos por software.

En la práctica, esto significa que cada aplicación, ya sea codificada con Vibe o no, se ubica dentro de su propio perímetro. Este perímetro define las formas en que una aplicación puede interactuar con usuarios, datos y otras aplicaciones. Además, garantiza que los privilegios normales de la aplicación solo incluyan las dependencias específicas que necesita para funcionar.

Esto garantiza que, si una aplicación contiene una vulnerabilidad explotable que es el objetivo de un atacante, la superficie de ataque potencial es mínima. Además, el atacante no podrá moverse lateralmente a otras aplicaciones ni escalar privilegios. Si bien la aplicación codificada con Vibe puede contener más vulnerabilidades, el atacante se limita al acceso más básico.

Zero trust y su apoyo a las organizaciones

La seguridad de confianza cero puede ayudar a reducir el riesgo al limitar el acceso de cada aplicación, exigir la verificación de la identidad en cada intercambio y contener el impacto de una vulnerabilidad explotada con éxito.

Los compradores de software deben asumir que las nuevas aplicaciones pueden incluir componentes generados por IA y prever la posibilidad de errores de codificación que puedan ser explotados.

La programación basada en la dinámica del entorno puede acelerar el desarrollo, pero la presión por lanzar los productos rápidamente puede llevar a los equipos a minimizar las comprobaciones de seguridad antes de que las aplicaciones lleguen a producción.

Conoce más en el siguiente video

¿Cuál es la amenaza?

Este problema afecta al comportamiento de transferencia de archivos en las sesiones de Soporte y Acceso Remoto de ScreenConnect y podría exponer a las organizaciones a riesgos a través de la funcionalidad de transferencia de archivos para técnicos de la plataforma. Si bien ConnectWise no ha revelado detalles técnicos sobre la causa raíz, ha proporcionado recomendaciones provisionales para reducir la exposición. En concreto, las organizaciones deben eliminar los permisos de transferencia de archivos de los roles de técnico hasta que se publique una solución definitiva.

¿Por qué es digno de mención?

Las plataformas de administración remota, como ScreenConnect, suelen tener acceso privilegiado a múltiples puntos finales y entornos de clientes. En consecuencia, las vulnerabilidades relacionadas con el movimiento de archivos pueden generar importantes riesgos de seguridad.

ConnectWise también señala que los ciberdelincuentes ya habían atacado vulnerabilidades de ScreenConnect, incluyendo campañas vinculadas a operadores de ransomware y grupos patrocinados por estados. Además, Shadowserver rastrea cerca de 6000 instancias de ScreenConnect expuestas a internet, lo que aumenta el potencial de explotación oportunista si los permisos de transferencia de archivos permanecen habilitados.

¿Cuál es la exposición o el riesgo?

Las organizaciones se exponen a riesgos cuando los roles de técnico de ScreenConnect conservan permisos de transferencia de archivos para las sesiones de Soporte y Acceso. Los ciberdelincuentes podrían aprovechar estos permisos para transferir archivos maliciosos o confidenciales durante las sesiones remotas.

Hasta que ConnectWise publique una solución definitiva, las organizaciones se enfrentan a un mayor riesgo de movimiento no autorizado de archivos y posteriores ataques informáticos en entornos gestionados. El riesgo es especialmente alto en entornos donde las cuentas de técnico tienen amplios privilegios.

¿Cuál son las recomendaciones?

Las siguientes recomendaciones son realizadas para reducir el riesgo:

• Implemente de inmediato la solución provisional de ConnectWise: Elimine el permiso TransferFiles, o TransferFilesInSession para roles heredados, de los grupos de sesión pertinentes en Administración > Seguridad > Roles. Aplique los cambios a todos los roles aplicables.
• Revise todas las implementaciones de ScreenConnect: verifique tanto las instancias alojadas en la nube como las locales. Identifique y corrija los roles de técnico que conservan permisos de transferencia de archivos.
• Supervise la actividad sospechosa de transferencia de archivos: revise las acciones administrativas de ScreenConnect e investigue las transferencias de archivos recientes de las sesiones de Soporte y Acceso para detectar comportamientos inusuales, especialmente en entornos con altos privilegios.
• Prepárese para implementar la solución permanente: consulte el aviso de ConnectWise para obtener información actualizada, detalles sobre las vulnerabilidades CVE y versiones parcheadas a medida que estén disponibles.

• Minimice las interrupciones operativas: Identifique los flujos de trabajo de los técnicos que dependen de la transferencia de herramientas, scripts, registros o paquetes. Establezca alternativas aprobadas hasta que ConnectWise publique y valide una solución definitiva.

El ataque puede comenzar antes del primer día de trabajo

La estrategia comienza mucho antes de que aparezca una actividad sospechosa dentro de la red. Los atacantes construyen identidades profesionales falsas utilizando información robada, documentación falsificada, perfiles profesionales cuidadosamente preparados e incluso herramientas de inteligencia artificial capaces de ayudarles a generar contenido, fotografías, comunicaciones y respuestas convincentes durante los procesos de selección.

El resultado es especialmente peligroso porque la primera barrera que deben superar no es tecnológica. Es humana.

Un candidato aparentemente legítimo puede atravesar entrevistas, procesos de contratación y verificaciones hasta convertirse en un empleado más. Una vez contratado, la organización puede proporcionarle exactamente lo que necesita para trabajar: una cuenta corporativa, acceso al correo electrónico, aplicaciones empresariales, VPN, repositorios, herramientas de colaboración y diferentes niveles de privilegio.

En ese momento, la amenaza deja de parecer una intrusión, y el atacante forma parte de la empresa.

De una identidad falsa a un acceso real

Esta es precisamente la característica que hace tan difícil detectar este tipo de operación. Un trabajador falso no necesariamente necesita comportarse como un atacante tradicional. Puede iniciar sesión desde una ubicación autorizada, utilizar las herramientas corporativas habituales y comunicarse con otros empleados mediante canales legítimos.

Desde la perspectiva de muchos sistemas de seguridad, esas acciones pueden parecer normales.

El verdadero problema aparece cuando esa identidad comienza a utilizar el acceso que le fue concedido para realizar actividades que no corresponden con su función. Puede investigar repositorios, consultar documentación interna, explorar recursos en la nube, acceder a información sensible o buscar oportunidades para ampliar sus privilegios.

Y cuanto mayor sea el acceso concedido al empleado, mayor será también el impacto potencial de una identidad comprometida o directamente fraudulenta.

Por eso, el riesgo no termina con detectar que una persona utilizó una identidad falsa. Para cuando la organización descubre el engaño, el atacante puede haber tenido semanas o meses para conocer su entorno tecnológico, identificar información de valor y establecer mecanismos que le permitan continuar operando.

La inteligencia artificial está haciendo más convincente el engaño

La evolución de la inteligencia artificial añade una nueva dificultad a este escenario. Crear una identidad falsa convincente requiere cada vez menos esfuerzo cuando las herramientas disponibles pueden ayudar a generar fotografías, perfiles profesionales, documentos, mensajes e incluso respuestas adaptadas a diferentes situaciones.

Esto significa que los procesos tradicionales de validación pueden enfrentarse a candidatos que no solamente cuentan con documentación aparentemente legítima, sino que además son capaces de mantener una identidad digital coherente durante todo el proceso de contratación.

La amenaza, por tanto, no consiste simplemente en preguntarse si un perfil es falso. Las empresas necesitan considerar si la persona detrás de una identidad digital realmente corresponde con quien afirma ser y, posteriormente, si sus actividades dentro de la organización coinciden con las responsabilidades que le fueron asignadas.

El verdadero objetivo: la confianza que existe detrás de una cuenta

Aquí es donde el concepto de trabajador falso adquiere una dimensión mucho mayor. El atacante no está intentando únicamente superar una solución de seguridad; está intentando aprovechar la confianza que existe dentro de una organización.

Primero obtiene la confianza del proceso de contratación. Después recibe una identidad corporativa. Esa identidad le permite obtener confianza dentro de los sistemas. Y finalmente esa confianza puede convertirse en acceso a información, aplicaciones, infraestructura y datos de alto valor.

Es una cadena que conecta personas, procesos, identidades y tecnología.

Y cuando una de esas etapas falla, las siguientes pueden convertirse en una consecuencia directa.

La seguridad ya no puede depender únicamente de detectar al intruso

El fenómeno de los trabajadores falsos obliga a las organizaciones a ampliar su concepto de seguridad. No basta con proteger el perímetro, bloquear malware o detectar comportamientos sospechosos después de que un usuario haya iniciado sesión.

La seguridad debe comenzar mucho antes y continuar durante todo el ciclo de vida de una identidad corporativa.

Esto implica fortalecer los procesos de incorporación, verificar adecuadamente las identidades, aplicar el principio de mínimo privilegio y evitar que una cuenta tenga acceso innecesario a información o sistemas que no requiere para realizar su trabajo. También significa supervisar continuamente el comportamiento de las cuentas, porque una identidad legítima puede convertirse en una fuente de riesgo cuando sus acciones dejan de corresponder con su función.

El objetivo no es desconfiar de cada empleado. Es dejar de asumir que una identidad autenticada es automáticamente una identidad confiable.

La nueva frontera de la ciberseguridad

Los trabajadores falsos representan una evolución importante en las técnicas de intrusión porque aprovechan algo que ningún firewall puede bloquear por sí solo: la confianza organizacional.

Una empresa puede tener excelentes controles de seguridad y aun así enfrentarse a un escenario en el que el atacante ya posee credenciales válidas, conoce los procesos internos y tiene autorización para utilizar determinadas herramientas.

Por eso, la pregunta que las organizaciones deben hacerse está cambiando.

Ya no se trata únicamente de “¿cómo evitamos que alguien entre?”, sino también de “¿cómo sabemos que quien tiene acceso realmente debería tenerlo y qué está haciendo con ese acceso?”

La respuesta requiere combinar controles de identidad, acceso, correo, endpoints, aplicaciones y monitoreo continuo. Cada señal puede parecer insignificante por separado, pero al correlacionarse puede revelar un comportamiento que de otro modo pasaría desapercibido.

Porque cuando el atacante consigue un empleo, la amenaza ya no se presenta como una intrusión. Se presenta como una actividad cotidiana.

Y precisamente ahí está el verdadero desafío para la seguridad empresarial.

Conoce más en el siguiente video

En conjunto, estos mecanismos proporcionan al atacante un control en tiempo real sobre el flujo de trabajo de phishing dentro de la sesión del navegador de la víctima, lo que permite un nivel de flexibilidad y evasión que no suele verse en las páginas de phishing estáticas.

Detección y defensa

Esta campaña demuestra cómo el phishing está evolucionando más allá de los sitios web falsos y los dominios sospechosos, y cómo está reduciendo muchos de los indicadores en los que los equipos de seguridad se han basado tradicionalmente para la detección.

Las organizaciones deben centrarse en identificar comportamientos maliciosos y controles de identidad en lugar de simplemente bloquear URL de phishing conocidas. Las principales medidas defensivas incluyen:

• Supervisar los flujos de autorización de OAuth y las cadenas de redireccionamiento para detectar destinos inusuales o inesperados.
• Inspeccionar la actividad del navegador relacionada con URL de tipo blob, especialmente cuando se utilizan para renderizar páginas de inicio de sesión o flujos de trabajo de autenticación.
• Detección de registros sospechosos de trabajadores de servicios asociados con contenido de origen externo.
• Aplicar métodos de autenticación multifactor resistentes al phishing, como las claves de seguridad FIDO2 y las contraseñas.
• Utilizar controles de seguridad de correo electrónico que analicen la ruta completa de clics en lugar de basarse únicamente en la URL inicial.
• Capacitar a los usuarios para que tengan cuidado con las solicitudes inesperadas de firma de documentos, incluso cuando los enlaces parezcan utilizar la infraestructura de confianza de Microsoft.

A medida que los atacantes trasladan cada vez más sus métodos de phishing al propio navegador, los defensores deberán prestar mayor atención a la protección de la identidad , la seguridad del navegador y la detección de comportamientos maliciosos. El desafío ya no reside simplemente en identificar un sitio web malicioso. En campañas como esta, la página de phishing puede no existir en ningún otro lugar que no sea el navegador de la víctima.

¿Qué hace que este ataque sea diferente?

A diferencia de las campañas de phishing convencionales que se basan en un sitio web similar alojado en un servidor, este ataque utiliza una arquitectura residente en el navegador diseñada para reducir su visibilidad tanto para los usuarios como para las herramientas de seguridad.

• No hay ninguna página de phishing que bloquear. El contenido de phishing nunca se muestra como una página web convencional. En cambio, se genera a partir de una URL virtual dentro del navegador de la víctima. Dado que la página solo existe durante esa sesión del navegador, no hay una URL de phishing persistente que las herramientas de seguridad puedan recuperar, analizar o bloquear con antelación.
• Servicios de Microsoft de confianza a lo largo de toda la cadena de ataque. En lugar de dirigir a las víctimas a un sitio web obviamente sospechoso, el ataque las redirige a través de la infraestructura legítima de Microsoft, incluyendo login.microsoftonline.com y Microsoft Teams. Dado que la navegación visible se mantiene dentro de los servicios de Microsoft de confianza, es menos probable que los usuarios y los escáneres automatizados identifiquen la actividad como maliciosa.
• Ejecución de phishing basada en el navegador. Una vez que se carga la página de phishing basada en blobs, se registra un service worker y se ejecuta parte del flujo de trabajo dentro de un iframe aislado. En conjunto, estos componentes ayudan a gestionar las solicitudes, controlar la navegación y coordinar la experiencia de phishing desde la propia sesión del navegador.
• Control dinámico del atacante. La página de phishing recibe instrucciones de la infraestructura de backend mediante mecanismos de mensajería del navegador. Dado que el flujo de trabajo se controla dinámicamente en lugar de mediante redirecciones predefinidas, los operadores pueden modificar los destinos y el comportamiento en tiempo real.
• Mayor legitimidad. El correo electrónico incluye un archivo de invitación de calendario como archivo adjunto inofensivo. Si bien no forma parte del contenido malicioso, contribuye a que el mensaje parezca una comunicación empresarial rutinaria y puede aumentar la confianza del destinatario.

Flujo de ataque

1. La víctima recibe un correo electrónico con el tema de DocuSign.

2. Se adjunta un archivo de invitación de calendario al correo electrónico. No parece malicioso, ya que apunta a un punto final OAuth legítimo de Microsoft. Se incluye para que el correo electrónico parezca una invitación normal a una reunión de negocios o a un calendario.

3. Un parámetro de redireccionamiento diseñado dirige al usuario a Microsoft Teams.

4. Microsoft Teams carga un recurso externo alojado en cdn.bloom[.]io.

5. El navegador convierte ese contenido en una URL de tipo blob.

6. La URL del blob renderiza la página de phishing localmente dentro del navegador.

7. Los service workers, los iframes y los controles de backend gestionan el flujo de trabajo de phishing y la navegación del usuario.

8. La configuración oculta de comando y control demuestra que no se trata de una página independiente, sino que forma parte de una plataforma de phishing gestionada que puede ser operada, actualizada y dirigida de forma centralizada a muchas víctimas a la vez.

Conoce más en el siguiente video

En conjunto, estos mecanismos proporcionan al atacante un control en tiempo real sobre el flujo de trabajo de phishing dentro de la sesión del navegador de la víctima, lo que permite un nivel de flexibilidad y evasión que no suele verse en las páginas de phishing estáticas.

Detección y defensa

Esta campaña demuestra cómo el phishing está evolucionando más allá de los sitios web falsos y los dominios sospechosos, y cómo está reduciendo muchos de los indicadores en los que los equipos de seguridad se han basado tradicionalmente para la detección.

Las organizaciones deben centrarse en identificar comportamientos maliciosos y controles de identidad en lugar de simplemente bloquear URL de phishing conocidas. Las principales medidas defensivas incluyen:

• Supervisar los flujos de autorización de OAuth y las cadenas de redireccionamiento para detectar destinos inusuales o inesperados.
• Inspeccionar la actividad del navegador relacionada con URL de tipo blob, especialmente cuando se utilizan para renderizar páginas de inicio de sesión o flujos de trabajo de autenticación.
• Detección de registros sospechosos de trabajadores de servicios asociados con contenido de origen externo.
• Aplicar métodos de autenticación multifactor resistentes al phishing, como las claves de seguridad FIDO2 y las contraseñas.
• Utilizar controles de seguridad de correo electrónico que analicen la ruta completa de clics en lugar de basarse únicamente en la URL inicial.
• Capacitar a los usuarios para que tengan cuidado con las solicitudes inesperadas de firma de documentos, incluso cuando los enlaces parezcan utilizar la infraestructura de confianza de Microsoft.

A medida que los atacantes trasladan cada vez más sus métodos de phishing al propio navegador, los defensores deberán prestar mayor atención a la protección de la identidad , la seguridad del navegador y la detección de comportamientos maliciosos. El desafío ya no reside simplemente en identificar un sitio web malicioso. En campañas como esta, la página de phishing puede no existir en ningún otro lugar que no sea el navegador de la víctima.

¿Cúal es la amenaza?

SynkLoader es un malware multietapa recientemente descubierto que se distribuye a través de campañas de phishing en Microsoft Teams. Los ciberdelincuentes se hacen pasar por personal de soporte técnico y envían mensajes convincentes diseñados para engañar a los usuarios y lograr que descarguen y ejecuten archivos maliciosos.

Una vez ejecutado, SynkLoader muestra una pantalla de bloqueo falsa de Windows que solicita a los usuarios que introduzcan sus credenciales. Las credenciales capturadas pueden utilizarse para acceder a las cuentas de usuario, establecer persistencia y facilitar actividades maliciosas adicionales en el entorno de la víctima.

Al combinar la ingeniería social con el robo de credenciales, los atacantes pueden obtener un punto de acceso inicial que puede conducir a una vulneración más amplia de la red.

¿Por qué es digno de mención?

SynkLoader pone de manifiesto una tendencia creciente entre los atacantes que abusan de plataformas de colaboración de confianza, como Microsoft Teams, para eludir los controles de seguridad tradicionales basados en correo electrónico. Al suplantar la identidad del personal de soporte técnico, los ciberdelincuentes explotan la confianza de los usuarios y generan una mayor sensación de urgencia, aumentando así la probabilidad de lograr una intrusión exitosa.

Dado que Teams se utiliza ampliamente para las comunicaciones empresariales diarias, los mensajes maliciosos pueden parecer más legítimos a los usuarios y pueden dar lugar al robo de credenciales, al acceso no autorizado o a la instalación de software malicioso adicional.