Azure Monitor es un servicio legítimo de Microsoft que vigila tus recursos en la nube y te envía un correo cuando algo necesita atención. Precisamente por eso, actores maliciosos han pasado los últimos meses convirtiéndolo en su propio sistema de distribución de phishing, uno en el que el mensaje realmente proviene de los servidores de correo de Microsoft, realmente supera cada verificación de autenticación que un servidor receptor puede ejecutar, y realmente termina con un número de teléfono conectado a un estafador en lugar de un enlace que un filtro pueda marcar.
Qué se supone que hacen las alertas de Azure Monitor
Azure Monitor permite que cualquier propietario de una suscripción cree una regla de alerta que vigila una condición, una métrica que cruza un umbral, el estado de un recurso que cambia, un presupuesto que se excede, y dispara una notificación cuando se cumple esa condición. La notificación se gestiona mediante un grupo de acciones, una lista de destinatarios y canales a los que debe llegar la alerta, que puede incluir una dirección de correo escrita directamente por quien configuró la regla. Cuando la alerta se dispara, la propia infraestructura de Azure Monitor genera y envía el correo. El remitente es genuinamente [email protected], porque genuinamente es Azure Monitor quien lo envía.
Convertir una alerta de facturación en una estafa telefónica
El abuso no requiere comprometer a Microsoft, a tu organización, ni la cuenta de nadie. Un atacante solo necesita una suscripción de Azure, incluida una gratuita o de prueba creada por él mismo, con acceso suficiente para construir una regla de alerta y su grupo de acciones. Investigadores de IRONSCALES documentaron un caso en el que el atacante creó un grupo de recursos llamado pay-cbb33c4ab1 y configuró una alerta de métrica cuyo campo de descripción, normalmente reservado para texto operativo, se rellenó en su lugar con lenguaje fraudulento de facturación. El atacante luego añadió la dirección de correo del objetivo como destinatario en el grupo de acciones y disparó la alerta.
Lo que llega a la bandeja de entrada es una notificación real de Azure Monitor, con el formato con el que Azure Monitor realmente formatea sus notificaciones, enviada desde la dirección desde la que Azure Monitor realmente envía. Lo único controlado por el atacante es el texto que hay dentro.
La factura de 459,90 dólares que facturación nunca envió
El mensaje que capturó IRONSCALES afirmaba un ID de transacción PP456-887A-22B, un cargo de 459,90 dólares vinculado a un descriptor de comercio “Windows Defender”, y un encabezado que decía “MICROSOFT CORPORATION BILLING AND ACCOUNT SECURITY NOTICE”. Nada de eso forma parte de la plantilla estándar de alertas de Azure, y precisamente así fue como se marcó el mensaje, no por SPF, DKIM ni DMARC, que se aprobaron sin problema, sino por detección de comportamiento que notó que las alertas de Azure Monitor normalmente no hablan de facturación en absoluto. El mensaje no llevaba ningún enlace. Llevaba dos números de teléfono, +1 (812) 266-1890 y +1 (812) 266-1510, ninguno de los cuales aparece en ninguna página oficial de soporte de Microsoft. Eso es phishing telefónico, a veces llamado TOAD, entrega de ataque orientada a teléfono, y está diseñado deliberadamente para no darle nada que escanear a un analizador de enlaces.
Por qué sigue funcionando meses después
Investigadores de Trustwave SpiderLabs documentaron por primera vez una versión activa de esta campaña en marzo de 2026, rastreando reglas de alerta de Azure Monitor creadas por atacantes con señuelos de facturas falsas y pagos no autorizados, con víctimas añadidas directamente al grupo de acciones vinculado a la regla maliciosa. Triskele Labs, en una investigación dirigida por el analista Adam Skupien, llegó a la misma conclusión de forma independiente y publicó una solución concreta: enrutar el correo de alertas de Azure Monitor solo hacia buzones o grupos operativos designados, y ponerlo en cuarentena para todos los demás. Meses después, siguen llegando reportes del mismo patrón, porque la brecha subyacente que lo hace posible, una plataforma en la nube que entregará con gusto texto escrito por un atacante a cualquiera que el titular de la cuenta incluya como destinatario, no se ha cerrado a nivel de plataforma.
Por qué DMARC no tiene nada que decir aquí
DMARC, junto con SPF y DKIM, responde a una sola pregunta: si el dominio en el encabezado From del mensaje está autorizado para enviarlo. Cuando Azure Monitor envía una alerta desde [email protected], la respuesta es inequívocamente sí, porque es la propia infraestructura de Microsoft la que la envía. DMARC no tiene ningún mecanismo para preguntar quién configuró la regla de alerta, qué cuenta la creó, o si el texto del campo de descripción es una nota operativa legítima o una factura fabricada. La autenticación verifica el conducto. Nunca fue diseñada para inspeccionar lo que un remitente legítimo deja que un atacante vierta a través de él.
Qué significa esto para tu programa
Enruta el correo de Azure Monitor por un canal dedicado y monitoreado. Si tu organización usa alertas de Azure Monitor, restringe qué buzones pueden recibirlas y aplica un escrutinio adicional, en lugar de dejar que cualquier dirección que el titular de la cuenta escriba en un grupo de acciones llegue directamente a una bandeja de entrada.
Capacita a los usuarios para desconfiar de los números de teléfono tanto como de los enlaces. El phishing telefónico existe precisamente porque las organizaciones pasaron años entrenando a la gente para pasar el cursor sobre los enlaces y verificar los dominios. Un mensaje sin ningún enlace y con un número de teléfono en su lugar debería levantar la misma sospecha, no menos.
Conoce cómo se ven realmente tus alertas legítimas. La plantilla estándar de notificación de Azure Monitor no incluye estados de cuenta, IDs de transacción ni lenguaje urgente de seguridad de cuenta. Una desviación de la plantilla normal es una señal más fuerte que la dirección de envío, ya que la dirección de envío será correcta todas las veces.
No esperes que la aplicación de DMARC detecte esto. Una política estricta con p=reject en tu propio dominio protege contra alguien que te suplante. No tiene ningún efecto sobre un mensaje que es genuinamente de Microsoft, con contenido que Microsoft nunca escribió.
Impulsa la detección basada en comportamiento y contenido, no solo el filtrado basado en autenticación. La única razón por la que esta campaña se detecta es que algunos defensores están observando lo que dice una alerta en relación con lo que dicen las alertas normalmente, no solo de dónde vino.
La conclusión
Cada capa de autenticación de correo hizo exactamente lo que fue diseñada para hacer en cada uno de estos mensajes, confirmó que Azure Monitor los envió, porque Azure Monitor lo hizo. El fraude vive por completo en un campo de texto que un servicio en la nube legítimo formateará, firmará y entregará en nombre de un atacante, siempre que el atacante pueda crear aunque sea una suscripción gratuita. Eso no es una falla en SPF, DKIM ni DMARC. Es un recordatorio de que autenticar a un remitente y verificar el contenido que ese remitente elige entregar siempre fueron dos problemas separados, y una plataforma tan grande como Azure seguirá produciendo nuevas formas de recordárnoslo.
Excello Mail te da visibilidad continua sobre tus reportes DMARC, para que puedas ver exactamente qué fuentes se están autenticando bajo tu dominio, incluso mientras los atacantes encuentran nuevas formas de hacer que una plataforma legítima transporte contenido fraudulento en su nombre. Regístrate gratis en Excello Mail y respalda con monitoreo real la capa de autenticación que sí controlas.