¿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

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.

Convertir los procesos comerciales cotidianos en trampas de autenticación.

Lo que hace que Kali365 y otras plataformas similares sean particularmente efectivas es su capacidad para disfrazar los ataques de autenticación como actividades comerciales rutinarias.

Las campañas de ataque Kali365 detectadas por los investigadores de Barracuda incluyen mensajes protegidos o cifrados, enlaces a documentos compartidos, solicitudes de firma electrónica, notificaciones de pago y facturación, alertas de correo de voz, advertencias de almacenamiento del buzón, solicitudes de revisión de cuarentena y notificaciones de cumplimiento y seguridad. Ninguna de estas características es nueva ni innovadora.

En cada caso, la víctima cree estar realizando una tarea laboral normal. La solicitud parece pertinente a su función y coherente con los flujos de trabajo cotidianos. En lugar de pedirle credenciales, se le indica que complete lo que parece ser un paso de verificación legítimo.

Ejemplo de correo electrónico de phishing con un enlace a una página de destino maliciosa.

Cómo funciona el phishing mediante código de dispositivo

El ataque comienza cuando la víctima recibe un correo electrónico de phishing con un enlace a una página web maliciosa. En lugar de mostrar un formulario de inicio de sesión falso de Microsoft, la página muestra un código de verificación del dispositivo e indica al usuario que continúe la autenticación mediante el proceso de inicio de sesión legítimo de Microsoft. La víctima es redirigida a una página auténtica de Microsoft y completa el proceso de inicio de sesión y autenticación multifactor (MFA) con normalidad.

Mensaje de autenticación de ejemplo.

Dado que la autenticación se realiza en la infraestructura de inicio de sesión legítima de Microsoft, los usuarios experimentan un inicio de sesión auténtico en lugar de una página falsa para robar credenciales. El atacante, en cambio, abusa de la sesión autenticada o los tokens resultantes.

La factura que nunca existió

El mecanismo puede comenzar con algo tan cotidiano como una factura.

Imaginemos recibir un correo aparentemente enviado por PayPal. El mensaje informa de un supuesto cargo por cientos de dólares y advierte que la transacción está a punto de procesarse. Para cancelarla, el usuario debe comunicarse con el número indicado.

No hay necesariamente un enlace que revisar. No hay un archivo que descargar. Incluso puede que el correo contenga muy poco texto.

Lo que sí existe es una historia cuidadosamente construida para provocar una reacción inmediata: “alguien está utilizando mi cuenta y tengo que solucionarlo ahora”.

Ese es precisamente el objetivo.

Las campañas analizadas arrojan los siguiente: los atacantes utilizaron facturas falsas, renovaciones de servicios, imágenes incrustadas, mensajes HTML diseñados para parecer comunicaciones legítimas e incluso invitaciones de Google Calendar para presentar cargos ficticios y dirigir a las víctimas hacia números telefónicos controlados por los estafadores.

La creatividad está en el pretexto; el objetivo es siempre el mismo: conseguir que la víctima llame voluntariamente.

Cuando el atacante consigue que seas tú quien inicia el contacto

Aquí está una de las diferencias fundamentales respecto al phishing tradicional.

En un ataque convencional, el delincuente intenta llevar a la víctima hacia una acción específica: hacer clic, iniciar sesión, abrir un archivo o introducir información.

Con el callback phishing, el atacante intenta conseguir algo psicológicamente más poderoso: que la propia víctima crea que está buscando ayuda.

Una vez realizada la llamada, la interacción cambia por completo. El estafador puede hacerse pasar por un representante de soporte, un departamento de facturación o un especialista de seguridad. Puede confirmar algunos datos obtenidos previamente y utilizar esa información para generar credibilidad.

A partir de ahí, la conversación puede escalar hacia solicitudes mucho más peligrosas: proporcionar información personal o financiera, acceder a una cuenta, instalar una herramienta de acceso remoto o realizar determinadas acciones mientras el supuesto agente de soporte guía a la víctima.

El correo electrónico, entonces, no era el objetivo final, era solo la puerta de entrada.

Hoy ese escenario está cambiando.

Cuando los ciberdelincuentes ponen su atención en una infraestructura crítica, las consecuencias pueden salir rápidamente del mundo digital y convertirse en un problema para toda una comunidad. Un sistema comprometido ya no representa únicamente archivos inaccesibles o pérdidas económicas. Puede afectar el suministro de agua, la generación de energía, los procesos industriales o servicios esenciales de los que dependen miles de personas.

Las recientes amenazas dirigidas contra sistemas de agua y tecnologías de control industrial vuelven a poner este riesgo sobre la mesa. Una presunta campaña cibernética iraní que habría afectado sistemas hídricos en distintos estados de Estados Unidos, junto con nuevas advertencias sobre amenazas dirigidas a controladores lógicos programables “PLC” utilizados en entornos industriales, demuestran que la infraestructura crítica continúa siendo un objetivo atractivo.

Y hay un elemento que vuelve este escenario todavía más preocupante: la tecnología que controla muchos de estos servicios fueron diseñados en una época muy diferente.

El correo que ves no siempre es todo lo que contiene

Aquí es donde aparece una técnica conocida como text salting, una estrategia que aprovecha una característica fundamental de los correos electrónicos: lo que el usuario observa en pantalla no necesariamente representa todo lo que existe dentro del mensaje.

Un atacante puede construir un correo que, para una persona, parece completamente normal. Puede mostrar una promoción, una notificación de una cuenta, una supuesta recompensa o cualquier otro mensaje diseñado para provocar una acción. Sin embargo, dentro del código HTML puede incorporar grandes cantidades de texto adicional que permanecen ocultas para el destinatario. Ese contenido puede utilizar palabras y frases aparentemente inocentes con el objetivo de modificar la interpretación que realizan los sistemas automatizados.

La diferencia puede parecer pequeña, pero tiene implicaciones importantes. El usuario ve un mensaje; el sistema de seguridad analiza una estructura mucho más compleja. Si esa estructura está deliberadamente manipulada, el atacante puede intentar alterar las señales que utiliza una herramienta para determinar si el correo es legítimo o malicioso.

El concepto no es completamente nuevo. Durante años, los atacantes han utilizado diferentes técnicas de ofuscación para esconder contenido, modificar patrones o dificultar el trabajo de los filtros. Lo que cambia ahora es el escenario en el que se utilizan. Cuando los sistemas de defensa incorporan inteligencia artificial y modelos capaces de interpretar lenguaje, los atacantes tienen un nuevo objetivo: influir en la información que recibe el modelo para intentar influir en su decisión.

El correo que ves no siempre es todo lo que contiene

Aquí es donde aparece una técnica conocida como text salting, una estrategia que aprovecha una característica fundamental de los correos electrónicos: lo que el usuario observa en pantalla no necesariamente representa todo lo que existe dentro del mensaje.

Un atacante puede construir un correo que, para una persona, parece completamente normal. Puede mostrar una promoción, una notificación de una cuenta, una supuesta recompensa o cualquier otro mensaje diseñado para provocar una acción. Sin embargo, dentro del código HTML puede incorporar grandes cantidades de texto adicional que permanecen ocultas para el destinatario. Ese contenido puede utilizar palabras y frases aparentemente inocentes con el objetivo de modificar la interpretación que realizan los sistemas automatizados.

La diferencia puede parecer pequeña, pero tiene implicaciones importantes. El usuario ve un mensaje; el sistema de seguridad analiza una estructura mucho más compleja. Si esa estructura está deliberadamente manipulada, el atacante puede intentar alterar las señales que utiliza una herramienta para determinar si el correo es legítimo o malicioso.

El concepto no es completamente nuevo. Durante años, los atacantes han utilizado diferentes técnicas de ofuscación para esconder contenido, modificar patrones o dificultar el trabajo de los filtros. Lo que cambia ahora es el escenario en el que se utilizan. Cuando los sistemas de defensa incorporan inteligencia artificial y modelos capaces de interpretar lenguaje, los atacantes tienen un nuevo objetivo: influir en la información que recibe el modelo para intentar influir en su decisión.

El phishing no siempre llega a tu bandeja de entrada

Durante años, las organizaciones han construido defensas alrededor del correo electrónico: filtros antispam, análisis de URLs, detección de archivos maliciosos, reputación de dominios y múltiples capas de protección.

El problema es que los atacantes también observan cómo funcionan esas defensas.

Por eso buscan nuevos caminos.

El formato .ics corresponde a iCalendar, un estándar utilizado para intercambiar información de eventos entre plataformas como Outlook, Google Calendar, Apple Calendar y otros servicios.

En apariencia, es simplemente un archivo que dice:

“Tienes una reunión el próximo martes a las 10:00.”

Pero un evento de calendario puede contener mucho más que una fecha y una hora.

Puede incluir:

• Nombre y descripción del evento.

• Información del organizador.

• Ubicación.

• URLs.

• Imágenes.

• Archivos adjuntos.

• Contenido HTML.

• Campos personalizados.

• Instrucciones para el participante.

Y precisamente ahí está el problema.

¿Plataforma centralizada?

Forg365 proporciona a los operadores una plataforma centralizada para crear campañas de phishing, obtener credenciales y datos de sesión, y gestionar las actividades posteriores a la vulneración de la seguridad. El servicio admite ataques de phishing mediante código de dispositivo y ataques AiTM, e incluye una extensión para navegador, ForgCookie, que puede secuestrar sesiones activas de SSO de Microsoft para mantener el acceso a las cuentas comprometidas.

Ataque a Microsoft 365

Forg365 integra varias técnicas avanzadas de ataque a Microsoft 365 en un servicio de suscripción, lo que reduce significativamente los conocimientos técnicos necesarios para llevar a cabo sofisticadas campañas de vulneración de cuentas. Al aprovecharse de los flujos de autenticación legítimos de Microsoft, los atacantes pueden capturar tokens de sesión y obtener acceso sin depender únicamente de contraseñas robadas.

Dado que estos eventos de autenticación suelen parecer legítimos, los controles de seguridad tradicionales pueden tener dificultades para distinguir la actividad maliciosa del comportamiento normal del usuario. La capacidad de la plataforma para secuestrar y reutilizar sesiones autenticadas también permite a los atacantes eludir la autenticación multifactor y mantener el acceso durante períodos prolongados.

¿Qué puedes hacer para reducir el riesgo?

Tras lograr una intrusión exitosa, los ciberdelincuentes pueden realizar ataques de suplantación de identidad por correo electrónico (BEC), robar datos confidenciales, apoderarse de cuentas de usuario y enviar comunicaciones fraudulentas desde identidades de confianza. Los atacantes también pueden establecer acceso persistente a buzones de correo y recursos de Microsoft 365, lo que les permite seguir operando incluso después de que se hayan cambiado las credenciales.

La información más valiosa no siempre es la más evidente

• Capacite a los usuarios para que reconozcan las solicitudes de autenticación sospechosas, verifiquen las solicitudes de inicio de sesión inesperadas a través de canales de confianza y eviten introducir códigos de inicio de sesión recibidos por correo electrónico, chat o invitaciones a reuniones.
• Recuerde a los usuarios que traten con precaución los mensajes urgentes o inesperados, incluso cuando parezcan provenir de contactos de confianza, proveedores o personal de TI.
• Restrinja o desactive la autenticación mediante código de dispositivo de Microsoft en Entra ID cuando no sea necesaria.
• Implemente la autenticación multifactor (MFA) resistente al phishing, como las claves de acceso FIDO2/WebAuthn.
• Utilice políticas de acceso condicional para limitar el acceso a dispositivos compatibles y ubicaciones de confianza.
• Finalice las sesiones activas, revoque los tokens de actualización y elimine los permisos OAuth no autorizados tras una posible vulneración de la seguridad.
• Elimine las reglas de buzón no autorizadas, los dispositivos registrados, los autenticadores y otros mecanismos de persistencia identificados durante una investigación.