← Other Blogs
Phishing
GenAI and security
Social engineering

Suplantación de identidad por invitación al calendario: cómo un ataque a Google Calendar eludió todos los controles perimetrales

← Otros blogs

Suplantación de identidad por invitación al calendario: cómo un ataque a Google Calendar eludió todos los controles perimetrales

El 17 de marzo, un atacante envió una invitación a Google Calendar por un cargo de 399,77 dólares que no era real. No había ningún enlace en el que hacer clic ni ningún archivo adjunto en el que hacer estallar, y DKIM fue aprobado. La única parte del ataque que importaba era el número de teléfono. He aquí por qué fallaron todos los controles perimetrales y dónde vive realmente la defensa.
Phishing
GenAI and security
Social engineering
Enrique Holgado

L; SECAR

El 17 de marzo de 2026, un atacante registró un dominio nuevo, abrió una cuenta de Google Workspace y envió una invitación de Google Calendar a un empleado de una empresa tecnológica de tamaño mediano. En la invitación se describía un cargo por uso de software de 399,77 dólares y se pedía al destinatario que llamara a un número gratuito para impugnarlo. No había ningún enlace en el que hacer clic ni ningún archivo adjunto que abrir, y el DKIM se aprobó porque Google firmó el mensaje. Se trata de la suplantación de identidad mediante invitaciones de calendario en su forma más resumida, y elude todos los niveles del sistema moderno de defensa del correo electrónico. La única persona que lo ve es la persona que lee la invitación.

Introducción

El ataque se produjo un martes por la tarde y, de un vistazo, se parecía a cualquier otra invitación de Google Calendar que el destinatario hubiera recibido esa semana. Un cargo de suscripción para un producto llamado «CoreDefense Plus». Un número de referencia. Un número gratuito al que llamar si el cargo no fue autorizado. Todos los enlaces del correo electrónico se dirigían a calendar.google.com. El archivo adjunto .ics no tenía ninguna carga ejecutable. El DKIM se aprobó sin errores porque, de hecho, el mensaje estaba firmado por Google.

El único indicador de compromiso era un número de teléfono incluido en la descripción de la invitación.

Esta es la suplantación de identidad por invitación al calendario de 2026, documentada por IRONSCALES el 6 de abril, y merece la atención de todos los CISO. No porque la suplantación de identidad basada en calendarios sea algo nuevo (Cofense lo documentó por primera vez en 2019), sino porque esta versión ha reducido el ataque a su esencia irreductible: un señuelo sin carga útil, que pasa a través de una infraestructura legítima y está diseñado para que la víctima pase del canal a una llamada telefónica en la que ninguna herramienta de seguridad pueda seguirla.

El mecanismo técnico importa. También lo es la conclusión: cuando la carga útil es un número de teléfono, la seguridad del correo electrónico es estructuralmente ciega y la única defensa eficaz es la conductual.

Qué es realmente el phishing con invitaciones de calendario

La suplantación de identidad por invitación de calendario es un ataque de ingeniería social que utiliza una invitación de calendario, normalmente un archivo.ics o una invitación nativa de Google o Microsoft Calendar, como mecanismo de entrega de un señuelo de suplantación de identidad. La carga útil puede adoptar tres formas diferentes.

El primero es un enlace malicioso incrustado en la descripción de la invitación o en el campo de ubicación. Esta es la variante original, documentada por Cofense ya en 2019, y que sigue siendo común en la actualidad.

El segundo es un código QR dentro del archivo adjunto .ics. ProArch documentó esta variante en marzo de 2026: un atacante oculta un código QR en un evento del calendario, el usuario obtiene una vista previa del archivo adjunto en Outlook y agrega la entrada del calendario sin que el archivo se descargue nunca. Al escanear el código QR, se accede a un proxy del tipo «adversario intermedio», que captura los tokens de sesión y elude la MFA.

La tercera es la variante que estamos discutiendo aquí: un señuelo de devolución de llamada sin carga útil. Sin enlace. Sin archivos adjuntos con contenido activo. Solo un número de teléfono en el cuerpo de una invitación de calendario, presentado en un contexto (un cargo, una renovación de una suscripción, una alerta de seguridad) lo suficientemente urgente como para provocar una llamada.

El caso IRONSCALES se encuentra en la tercera categoría y es la variante más difícil de detectar para la seguridad de correo electrónico tradicional.

Objetivo de fragmento destacado

La suplantación de identidad por invitación de calendario es un ataque de suplantación de identidad que utiliza una invitación de calendario, normalmente un archivo.ics o una invitación de Google o Microsoft Calendar, como mecanismo de entrega. La carga útil puede consistir en un enlace malintencionado, un código QR incrustado o, en las variantes sin carga útil, un número de teléfono diseñado para hacer que se devuelva la llamada a un centro de llamadas controlado por un atacante.

Por qué su sistema de seguridad de correo electrónico no lo detecta

El ataque IRONSCALES es un caso de prueba útil porque nos permite recorrer cada capa de una defensa de correo electrónico empresarial estándar y preguntarnos, honestamente, qué estaba comprobando cada capa y por qué cada una dejó pasar el mensaje.

Filtrado de URL. No había ninguna URL malintencionada que filtrar. Todos los enlaces de la invitación llevan a calendar.google.com, que es un dominio legítimo de Google que ningún motor de reputación detectará jamás. La reputación de las URL consiste en mantener un conjunto de dominios que se sabe que son incorrectos y en el análisis de los nuevos dominios en busca de señales de reputación. Cuando solo hay enlaces a Google, no hay nada que evaluar.

Sandboxing y detonación de accesorios. El archivo.ics no contenía ninguna carga ejecutable. Era un evento de calendario estándar con campos de texto. Los motores de sandboxing están diseñados para explotar el contenido activo, los scripts, los objetos incrustados y los enlaces a descargas maliciosas y observar el comportamiento en tiempo de ejecución. Una invitación de calendario estática basada en texto no produce ningún comportamiento malintencionado observable porque no hay nada que ejecutar.

Autenticación de correo electrónico (DKIM, SPF, DMARC). Estos son los tres protocolos que confirman que un correo electrónico proviene realmente del dominio del que afirma provenir. El mensaje se autenticó de forma limpia en los tres. El DKIM, que firma el mensaje con la clave criptográfica del remitente, se aprobó porque Google lo firmó desde la propia infraestructura de Google. El SPF, que comprueba que el servidor remitente está autorizado para el dominio, no devolvió ninguno porque el dominio del atacante (scoolsd [.] com, registrado esa misma mañana) no tenía ningún registro SPF publicado, pero la alineación del DMARC no falla cuando falta el SPF cuando se aprueba el DKIM. Desde el punto de vista de la autenticación del correo electrónico, el mensaje era legítimo. Técnicamente, lo era: lo enviaba Google Workspace, que el atacante controlaba.

Pasarelas de correo electrónico seguras (SEGs). La mayoría de los SEGs analizan el contenido del cuerpo del correo electrónico y los archivos adjuntos en busca de patrones maliciosos. Los investigadores de Check Point han documentado que los correos electrónicos de suplantación de identidad basados en calendarios suelen pasar por alto los códigos DKIM, SPF y DMARC porque provienen de servicios legítimos de Google, y que la mayoría de los SEG no inspeccionan minuciosamente los archivos adjuntos del calendario porque el formato.ics no es un formato de archivo tradicionalmente utilizado como arma. El punto ciego es estructural, no un error de configuración.

Análisis de contenido conductual. Aquí es donde algunas plataformas marcan el mensaje. El motor Themis de IRONSCALES asignó una puntuación de confianza del 66% basándose en el dominio recién registrado, la ausencia de una política de protección solar y los patrones de contenido coherentes con la ingeniería social basada en la urgencia financiera. Esa es la respuesta correcta. Pero fíjese en lo que lo marcó: no la carga útil (porque no había ninguna carga útil), sino el contexto en torno al mensaje. Antigüedad del dominio. Anomalías de autenticación. Patrones lingüísticos. Son señales que el resto de la pila ignora.

El resultado incómodo es que, para las cuatro capas clásicas de defensa del correo electrónico, este ataque es invisible.

El patrón de suplantación de identidad por devolución de llamadas que lo sustenta

El incidente de Google Calendar es un vector de entrega dentro de una categoría de ataque más amplia denominada suplantación de identidad por llamada, también conocida como TOAD (entrega de ataques orientados al teléfono). La característica que lo define es que el ataque hace que la víctima pase de un correo electrónico o una invitación a una llamada de voz, donde la ingeniería social se lleva a cabo en tiempo real y no deja ningún rastro digital que las herramientas de seguridad puedan inspeccionar.

Esta categoría ha crecido rápidamente. Trustwave SpiderLabs registró un aumento del 140% en las campañas de suplantación de identidad con devolución de llamadas entre julio y septiembre de 2024 (Trustwave SpiderLabs, octubre de 2024). El informe del FBI sobre la delincuencia en Internet de 2024 atribuye más de 2 900 millones de dólares en pérdidas registradas en EE. UU. al uso indebido del correo electrónico empresarial y al fraude relacionado, y se señala que la ingeniería social basada en el teléfono es un factor importante e infravalorado (IC3 del FBI, 2024).

El patrón común en todas las variantes de suplantación de identidad con devolución de llamadas, ya sea que el señuelo llegue por correo electrónico, SMS o mediante una invitación de calendario, es que el ataque está estructurado para dirigir a la víctima a una llamada telefónica antes de que cualquier defensa técnica tenga la oportunidad de intervenir. Este también es el motivo Los atacantes impulsados por la IA ahora secuencian varios canales — un correo electrónico que establece el contexto, una llamada de voz que crea urgencia, para hacer que la ingeniería social trabaje más que cualquier canal por sí solo.

Cómo defenderse contra la suplantación de identidad por invitación al calendario

Hay dos niveles de defensa y no son igualmente efectivos contra la variante de carga cero.

Controles técnicos

Proporcionan una mitigación parcial y deben configurarse de todos modos.

En entornos de Microsoft 365, desactive el procesamiento automático de calendarios para que las convocatorias de reunión entrantes no se acepten automáticamente ni se coloquen provisionalmente en los calendarios de los usuarios. Las entradas del calendario suelen permanecer en los calendarios de los usuarios incluso después de denunciar y eliminar el correo electrónico de suplantación de identidad original, lo que da a los atacantes una segunda oportunidad días después, cuando el usuario vuelve a visitar el evento. Eliminar el artefacto del calendario cuando se elimina el correo electrónico cierra esa brecha.

En Exchange, las reglas de flujo de correo pueden detectar los archivos adjuntos.ics externos y distribuirlos para su revisión. Aplíquelo con cuidado y con listas de permitidos, ya que las invitaciones legítimas a reuniones externas utilizan el mismo formato de archivo.

En Google Workspace, la configuración del calendario se puede ajustar para rechazar las invitaciones de remitentes que no estén en la lista de contactos del usuario o para suprimir la adición automática de eventos por parte de remitentes desconocidos.

Estos controles reducen la superficie de ataque. No la eliminan. Ninguno de ellos ve el número de teléfono.

Controles de comportamiento

Cuando la carga útil es un número de teléfono, la única capa que evalúa la intención es la persona que lee la invitación. Esa es la capa en la que debe operar la defensa.

La defensa conductual eficaz contra la suplantación de identidad por llamada tiene tres componentes.

La primera es la simulación realista. Los empleados deben enfrentarse a situaciones de suplantación de identidad basadas en calendarios y con devolución de llamadas en un entorno controlado antes de encontrarse con ellas de manera espontánea. La simulación debe reproducir el patrón estructural del ataque: una acusación desconocida, un remitente con apariencia nueva, un número de teléfono presentado como mecanismo de disputa, la urgencia vinculada a una decisión financiera.

El segundo es el entrenamiento de reconocimiento de patrones vinculado a las señales específicas de esta clase de ataque. No se trata de una formación genérica para detectar el correo electrónico de suplantación de identidad, sino de instrucciones sobre patrones específicos: los proveedores con los que la organización no tiene ninguna relación, las invitaciones de remitentes externos para realizar transacciones en el calendario, los números de teléfono están escritos en el lenguaje de las disputas financieras y los cargos por urgencia están sujetos a plazos. Estas señales son las que utiliza el ataque IRONSCALES, y se pueden repetir en toda la categoría.

La tercera es la infraestructura de informes que gestiona los eventos del calendario, no solo los correos electrónicos. Si el único flujo de trabajo para denunciar casos de suplantación de identidad que tiene su organización es un botón de Outlook que marca los correos electrónicos, no se denunciará ningún evento malintencionado que aparezca en el calendario de un usuario después de eliminar el correo electrónico. La capacidad de denunciar tiene que extenderse a la propia superficie del calendario.

Así es como se ve la defensa conductual como un control de seguridad que soporta cargas: simulación, reconocimiento de patrones, infraestructura de informes, todo ello dirigido a la clase de ataque específica. Sin esta capa, la variante sin carga útil de la suplantación de identidad mediante invitaciones al calendario llega al calendario del usuario sin ningún tipo de defensa entre este y la llamada telefónica.

La incómoda conclusión

La autenticación confirma el origen. No confirma la intención.

Cuando un atacante envía un señuelo a través de la infraestructura legítima de Google, cada control perimetral se convierte en una señal de confianza para el ataque, más que en una defensa contra él. La firma DKIM no dice «esto es seguro». Dice «esto viene de Google». En el caso de una invitación de calendario enviada desde una cuenta de Google Workspace que el atacante registró una hora antes, ambas afirmaciones son válidas al mismo tiempo.

La única capa del conjunto de seguridad que puede evaluar la intención es la persona que lee la invitación. Esa es la capa en la que opera Zepo.

Así que esta es la pregunta que vale la pena plantearse: cuando el próximo ataque sin carga útil llegue a uno de los calendarios de sus empleados, ¿en qué consiste realmente su defensa?

Escrito por:
Enrique Holgado
Contenido
Actúa ahora antes de que lo hagan los atacantes
Unifique las simulaciones de deepfake, la formación personalizada y el análisis de riesgos en una única plataforma que cree una defensa mensurable.
Hable con un experto

Anticípate antes de que ataquen.