Monthly Threat Report de julio de 2026

Introducción

El Informe mensual de amenazas de Hornetsecurity by Proofpoint ofrece cada mes información sobre las tendencias de seguridad en M365, las amenazas por correo electrónico y los acontecimientos actuales del sector de la ciberseguridad. Esta edición se centra en los hechos ocurridos durante junio de 2026. Al tratarse de una edición de noticias y análisis, el informe de este mes da prioridad a un estudio detallado de las amenazas emergentes y de la investigación del sector, en lugar de incluir apartados con datos estadísticos.

Un único tema conecta gran parte de lo que abordamos este mes: la inteligencia artificial ya participa de forma activa en ambos lados de la seguridad. Los equipos de investigación documentaron la primera operación de ransomware ejecutada de principio a fin por un agente de IA autónomo; Microsoft publicó el Patch Tuesday más amplio de la historia del programa, cuyo aumento de volumen se atribuyó en parte al descubrimiento de vulnerabilidades asistido por IA; y nuestro Threat Intelligence Lab siguió un kit de phishing que suplantaba una marca y estaba diseñado para secuestrar cuentas a gran escala. Cerramos el informe con una visión general de la especificación DMARC de nueva generación, que llega en un momento oportuno, cuando siguen aumentando la suplantación y las exigencias de autenticación.

Resumen ejecutivo

• Los equipos de investigación documentaron JadePuffer, la primera operación de ransomware de la que se tiene constancia pública y que fue dirigida de principio a fin por un agente autónomo basado en un modelo de lenguaje de gran tamaño (LLM). El agente se encargó del reconocimiento, el robo de credenciales, el movimiento lateral, la escalada de privilegios y el cifrado sin intervención humana. Para obtener acceso inicial, explotó CVE-2025-3248 en Langflow y, durante la intrusión, CVE-2021-29441 en Alibaba Nacos. Cifró 1.342 elementos de configuración de servicios y, en una secuencia documentada, diagnosticó y corrigió un inicio de sesión fallido en 31 segundos.
• El Patch Tuesday de Microsoft de junio corrigió más de 200 vulnerabilidades, la mayor publicación individual en la historia del programa, incluida una vulnerabilidad zero-day de Exchange Server que ya se estaba explotando. CVE-2026-42897 permite que un atacante no autenticado ejecute JavaScript arbitrario en la sesión de Outlook Web Access de la víctima mediante un correo electrónico diseñado específicamente. Afecta a Exchange Server 2016, 2019 y Subscription Edition instalados en local.
• Nuestro Threat Intelligence Lab analizó una campaña de phishing de verificación de Meta dirigida a propietarios y administradores francófonos de páginas de Facebook. El kit aprovecha la credibilidad de las insignias de verificación para obtener no solo credenciales, sino también códigos de autenticación multifactor (MFA) y documentos de identidad. Esto indica que el objetivo es secuestrar por completo la cuenta, y no limitarse a robar credenciales.
• El volumen récord de parches se atribuyó en parte al descubrimiento de vulnerabilidades asistido por IA, la misma clase de capacidad que tratamos el mes pasado al hablar de Project Glasswing de Anthropic. La convergencia entre el descubrimiento acelerado por IA y las intrusiones operadas por IA reduce el tiempo entre el momento en que se conoce un fallo y el momento en que empieza a explotarse.
• El IETF publicó una especificación DMARC de nueva generación (RFC 9989), que sustituye a la RFC 7489 original. La actualización estandariza el descubrimiento del dominio organizativo, aclara la herencia y la alineación de políticas y separa los informes en especificaciones complementarias. Llega mientras los proveedores de correo siguen endureciendo los requisitos de autenticación de remitentes.

Resumen de amenazas

Phishing de verificación de Meta: la confianza en la marca se utiliza como arma para secuestrar cuentas

Nuestro Threat Intelligence Lab identificó y analizó una campaña de phishing que suplanta a Meta para dirigirse a propietarios y administradores francófonos de páginas de Facebook, pequeñas empresas y equipos de marketing. El análisis técnico completo está disponible en el blog de seguridad de Hornetsecurity. La campaña destaca por dos motivos: parte de un pretexto positivo en lugar de una amenaza y va mucho más allá del robo de credenciales, hasta buscar el control total de la cuenta.

La mayoría de las campañas de phishing que suplantan una plataforma empiezan generando miedo, normalmente con un aviso de que una cuenta se ha suspendido o se va a eliminar. Esta campaña invierte ese patrón. El señuelo ofrece algo deseable, la oportunidad de conseguir una insignia de verificación, y lo combina con un plazo moderado (al pedir que se “active en 24 horas”). La confianza, la recompensa y una ligera sensación de urgencia se unen en un pretexto que a una persona ocupada que administra una página le resulta más difícil descartar.

Cadena de ataque

La campaña sigue un flujo de trabajo estructurado en varias etapas:

Etapa 1: el atacante distribuye correos de phishing a través de la plataforma AppSheet de Google. Aprovecha la reputación de envío de un servicio legítimo de Google para mejorar la entregabilidad y eludir los filtros básicos de reputación.

Etapa 2: quienes hacen clic son redirigidos a través del dominio sw[.]run a una interfaz falsa de Meta Accounts Centre alojada en la infraestructura del atacante, en finn2[.]xyz.

Etapa 3: la página de destino solicita la información de forma progresiva, en lugar de pedirla toda de una vez. Solicita, por este orden, datos de la página, información personal, credenciales de Facebook, códigos MFA y documentos de identidad. Este enfoque por etapas imita un proceso legítimo de verificación y reduce la probabilidad de que la víctima abandone el proceso.

Etapa 4: los datos recopilados se cifran en el lado del cliente mediante claves Advanced Encryption Standard (AES) integradas en el código y se almacenan temporalmente en el localStorage del navegador, con las claves __ck_clv1 a __ck_clv6. Después, los perfiles cifrados de las víctimas se exfiltran a un endpoint del backend en /api/authentication. El kit también consulta servicios externos de IP y geolocalización, a través de apip[.]cc, para enriquecer cada registro de víctima.

El kit incluye compatibilidad de configuración con doce idiomas: inglés, alemán, francés, español, italiano, neerlandés, portugués, ruso, chino, vietnamita, japonés y coreano. Esto indica que la operación se diseñó para reutilizarse en regiones muy distintas de los objetivos francófonos que observamos.

Indicadores de compromiso (IOC)

Infraestructura controlada por el atacante: – hxxps://sw[.]run (redirect) - hxxps://finn2[.]xyz (fake Meta Accounts Centre)

Entrega y enriquecimiento: – Phishing emails delivered via Google AppSheet – Victim enrichment via apip[.]cc

Artefactos en el host: – Claves de almacenamiento temporal en localStorage de __ck_clv1 a __ck_clv6 – Endpoint de exfiltración /api/authentication

Por qué es importante

La recopilación de códigos MFA y documentos de identidad es el detalle que distingue esta campaña del phishing habitual de credenciales. Robar una contraseña proporciona al atacante un factor. Robar la contraseña, un código MFA válido y un documento oficial de identidad le da todo lo necesario para tomar el control de la cuenta, superar verificaciones adicionales y, en muchos casos, completar más adelante el proceso de recuperación de la plataforma. Para una empresa que gestiona la relación con su clientela, la publicidad y la presencia de marca mediante una página de Facebook, perder esa página supone un impacto operativo y reputacional directo.

El uso de un pretexto positivo basado en una recompensa también es relevante para la formación de concienciación. Durante años se ha enseñado a desconfiar de las amenazas y de la urgencia. Una oferta de insignia de verificación no activa esas alarmas. La lección útil es más sencilla y sirve para cualquier plataforma: las notificaciones legítimas no piden introducir una contraseña, un código MFA ni una foto del documento de identidad desde un enlace incluido en un correo. El estado de verificación debe comprobarse directamente en la plataforma oficial, mediante una URL guardada en favoritos o la aplicación móvil, nunca desde un enlace recibido por correo.

Principales incidentes y acontecimientos del sector

JadePuffer: el primer ataque de ransomware ejecutado por completo por un agente de IA

El 4 de julio, Bleeping Computer informó sobre JadePuffer y lo describió como la primera operación de ransomware registrada que fue ejecutada de principio a fin por un agente LLM, en lugar de por una persona. La información se basaba en una investigación publicada el 1 de julio por el equipo Threat Research de Sysdig. Infosecurity Magazine cubrió de forma independiente los mismos hallazgos. Las publicaciones utilizan el término «actor de amenazas agéntico» (ATA) para esta clase de adversario: en lugar de que una persona opere con un conjunto de herramientas, es el propio agente de IA quien lleva a cabo la intrusión.

La diferencia no es una cuestión de marketing. Durante la intrusión, el agente lo hizo todo por sí mismo: reconoció el entorno, obtuvo credenciales, se desplazó a sistemas cercanos, estableció persistencia, escaló privilegios y, al final, cifró los datos. Se adaptó a los fallos en tiempo real, de una forma que recuerda a una persona que va resolviendo obstáculos durante un ataque.

Cadena de ataque

Etapa 1: la intrusión comenzó con CVE-2025-3248, un fallo de Langflow, un conocido framework de código abierto para crear aplicaciones LLM, que permite a un atacante no autenticado ejecutar código arbitrario. El agente utilizó este punto de apoyo como canal de entrega para toda la operación y envió por él las cargas útiles posteriores.

Etapa 2: una vez dentro, el agente cartografió el host y buscó secretos. Entre sus objetivos estaban las claves API de proveedores de LLM, las credenciales de proveedores cloud y los accesos a bases de datos. Exportó la base de datos PostgreSQL utilizada por Langflow y después accedió a un almacén de objetos MinIO cercano para extraer archivos de configuración y de entorno.

Etapa 3: para mantener el acceso, el agente programó una tarea cron en el host de Langflow que se comunicaba con la infraestructura del atacante cada 30 minutos.

Etapa 4: desde allí, el agente se desplazó a un servidor de producción que alojaba una base de datos MySQL y Alibaba Nacos (Naming and Configuration Service). La instancia de Nacos era vulnerable a CVE-2021-29441, un bypass de autenticación que el agente utilizó para crear una cuenta de administrador bajo su control.

Etapa 5: en la fase final, el agente utilizó contra la víctima su propia base de datos. Ejecutó la función AES_ENCRYPT() de MySQL sobre los 1.342 elementos de configuración de servicios almacenados en Nacos, eliminó las tablas originales de configuración e historial y dejó la exigencia de pago en una nueva tabla de rescate.

La prueba más sólida de que no había ninguna persona al teclado aparece en un intervalo de 31 segundos durante la toma de control de Nacos. El agente se encontró con un inicio de sesión de administrador fallido y consiguió hacerlo funcionar de nuevo en aproximadamente medio minuto. Las publicaciones también señalan que el agente dejó comentarios continuos sobre sus propios objetivos dentro de las cargas útiles y explicó qué pretendía conseguir en cada paso. Las personas que operan ataques no suelen anotar así comandos desechables de una sola línea.

La propia nota de rescate revela el problema. La dirección de Bitcoin incluida es la dirección de ejemplo que aparece en la documentación para desarrolladores de Bitcoin y que, al parecer, el agente reprodujo a partir de sus datos de entrenamiento. Cualquier víctima que hubiera pagado habría enviado los fondos a una dirección que el atacante no controlaba. La clave de cifrado es otro callejón sin salida: el agente la generó de forma aleatoria y no la guardó ni la exfiltró, por lo que los datos de configuración cifrados no pueden recuperarse, se pague o no.

¿Por qué es tan importante?

JadePuffer es la señal que muchas personas de la comunidad de seguridad estaban esperando. El entorno atacado era una pila de IA y datos autogestionada, con acceso administrativo expuesto a Internet y credenciales predeterminadas sin rotar. Es decir, un objetivo que una persona atacante competente también habría comprometido. Lo que cambió fue quién realizó el trabajo. La principal conclusión de las publicaciones es que las herramientas agénticas reducen la barrera para ejecutar un ataque grave: una operación como esta ya no exige experiencia en ransomware, sino solo un agente dirigido contra infraestructura expuesta.

Esto conecta directamente con una tendencia que tratamos el mes pasado. En nuestro informe de junio sobre Project Glasswing de Anthropic, señalamos que la primera generación de vulnerabilidades descubiertas por IA que apareciera en explotación activa, en lugar de pasar por una divulgación coordinada, marcaría el momento en que la vertiente ofensiva de la seguridad con IA habría alcanzado el mismo nivel. Un agente autónomo que encadena dos vulnerabilidades conocidas para crear una operación de extorsión funcional es una señal relacionada. Ambas capacidades, el descubrimiento acelerado por IA y la intrusión operada por IA, acortan el tiempo entre el momento en que se conoce un fallo y el momento en que se utiliza contra infraestructura expuesta.

Las conclusiones defensivas son convencionales, y esa es precisamente la cuestión. Todo lo que explotó JadePuffer tenía una solución sencilla: aplicar parches a fallos conocidos como CVE-2025-3248, rotar las credenciales y las claves de firma predeterminadas y mantener las interfaces administrativas fuera de Internet. Las herramientas agénticas no cambian la lista de comprobación, sino el ritmo. Las configuraciones incorrectas que antes podían permanecer sin detectar hasta que una persona atacante las encontraba ahora se descubren y explotan con la velocidad y la constancia de una máquina.

Patch Tuesday de Microsoft de junio: publicación récord y vulnerabilidad zero-day de Exchange explotada activamente

El Patch Tuesday de Microsoft del 9 de junio fue el mayor de la historia del programa. Bleeping Computer informó de que la publicación corregía 200 vulnerabilidades de Microsoft, mientras que The Hacker News y Dark Reading contabilizaron un récord de 206, incluidas algunas que no pertenecían a Microsoft. Las publicaciones coinciden en lo esencial: fue un mes récord, con más de 30 vulnerabilidades calificadas como críticas, y el aumento del volumen se atribuyó en parte al descubrimiento de vulnerabilidades asistido por IA.

CVE-2026-42897 afecta a Exchange instalado en local

Como esta publicación trata mucha información de seguridad relacionada con M365, conviene destacar esta CVE. Es posible que algunas personas vean información sobre CVE-2026-42897 y teman lo peor, pero la vulnerabilidad solo afecta a las versiones de Exchange instaladas en local. Exchange Online NO está afectado.

CVE-2026-42897 es una vulnerabilidad de suplantación de Exchange Server que se está explotando activamente. Se trata de un fallo de cross-site scripting (XSS) que permite a un atacante remoto no autenticado ejecutar JavaScript arbitrario en la sesión de Outlook Web Access de la víctima. Para explotarlo, basta con enviar un correo diseñado específicamente y que la persona destinataria lo abra en Outlook Web Access bajo determinadas condiciones de interacción. Los productos afectados son Exchange Server 2016, Exchange Server 2019 y Exchange Server Subscription Edition instalados en local.

La cronología merece atención, porque la explotación comenzó antes de que existiera un parche. CISA añadió CVE-2026-42897 a su catálogo Known Exploited Vulnerabilities el 15 de mayo de 2026 y ordenó a los organismos de la Federal Civilian Executive Branch que aplicaran medidas de mitigación. Esa misma semana, The Hacker News informó de que Microsoft estaba ofreciendo una mitigación temporal mediante Exchange Emergency Mitigation Service (EEMS) mientras preparaba una corrección permanente. Microsoft publicó esa corrección el 9 de junio. Hay un detalle importante para las versiones antiguas: las actualizaciones de junio para Exchange Server 2016 y Exchange Server 2019 solo están disponibles para las organizaciones inscritas en el periodo 2 del programa Extended Security Update (ESU), mientras que Exchange Server Subscription Edition recibe la actualización directamente. De nuevo, las organizaciones que utilizan Exchange Online alojado no son el objetivo; se trata de una vulnerabilidad del producto Exchange Server instalado en local y del tipo de fallo en sistemas de mensajería expuestos a Internet que los afiliados de ransomware han utilizado repetidamente.

Otras correcciones destacadas

Además del fallo de Exchange, la publicación incluyó varias vulnerabilidades zero-day divulgadas públicamente que destacaron tanto Bleeping Computer como The Hacker News:

• CVE-2026-45586: fallo de elevación de privilegios en Windows Collaborative Translation Framework (CTFMON) que puede conceder privilegios SYSTEM.
• CVE-2026-49160: vulnerabilidad de denegación de servicio en Windows HTTP.sys, descrita como un ataque “HTTP/2 Bomb”, en el que pequeñas solicitudes manipuladas obligan al servidor a reservar una cantidad de memoria desproporcionada.
• CVE-2026-50507: bypass de una función de seguridad de BitLocker.

Bleeping Computer también informó de varias vulnerabilidades críticas de ejecución remota de código que afectan a Microsoft Office, Outlook, Word y Excel, las superficies del lado del cliente más relevantes para las organizaciones centradas en M365. Como pueden activarse mediante documentos maliciosos enviados por correo, deben situarse en el mismo nivel de prioridad que la corrección de Exchange en cualquier organización cuyo principal riesgo sea el correo entrante.

Por qué es importante

Este mes destacan dos aspectos. El primero es la vulnerabilidad zero-day de Exchange que se está explotando activamente y que, desde cualquier punto de vista, exige aplicar el parche con la máxima prioridad. Un atacante no autenticado que pueda ejecutar JavaScript en la sesión autenticada de correo web de una víctima queda bien situado para leer mensajes, manipular la interfaz y avanzar hacia un mayor compromiso de la cuenta. Las organizaciones que no puedan aplicar el parche de inmediato deben confirmar que las mitigaciones de EEMS están activas y tratarlo como un cambio de emergencia.

El segundo aspecto es el propio volumen récord de parches y su causa. Tanto The Hacker News como Dark Reading relacionan el aumento del número de parches con el descubrimiento de vulnerabilidades asistido por IA, la misma clase de capacidad que estaba detrás de los resultados de Project Glasswing que tratamos en junio. Es la cara defensiva de la misma moneda que JadePuffer representa en el lado atacante. Descubrir más vulnerabilidades genera más parches, lo cual es positivo, pero también amplía la ventana de exposición de las organizaciones cuyo ritmo de actualización no puede seguir el volumen de correcciones críticas que se publica cada mes. La velocidad de aplicación de parches, sobre todo en sistemas expuestos a Internet, se está convirtiendo en la variable que determina de forma más directa el nivel de exposición.

El IETF publica DMARC de nueva generación (RFC 9989)

El avance más importante del periodo en autenticación de correo es la llegada de una especificación DMARC de nueva generación. Domain-based Message Authentication, Reporting, and Conformance (DMARC) es la capa de políticas que indica a los servidores de correo receptores qué deben hacer cuando un mensaje no supera las comprobaciones de alineación de SPF y DKIM. Desde la especificación original de 2015, DMARC ha regulado la autenticación de remitentes. El IETF ha publicado ahora una especificación DMARC actualizada, denominada RFC 9989, que sustituye a la RFC 7489 original.

Proofpoint ha publicado un resumen de los cambios en Next generation DMARC: what’s changing and why it matters, escrito por Craig Temple el 11 de junio, junto con una serie más detallada de varias partes sobre el descubrimiento de dominios y políticas y la preparación para la aplicación. Lo que sigue es una visión general, no una guía completa. Quienes planifiquen una migración deben basarse en esas publicaciones y en la propia RFC.

Según el resumen de Proofpoint, la actualización debe entenderse como una década de mejoras operativas, no como una reinvención. Los cambios principales se agrupan en tres áreas:

• Descubrimiento estandarizado del dominio organizativo. RFC 9989 sustituye la dependencia de comportamientos de consulta incoherentes y específicos de cada proveedor por un método estándar para determinar el límite organizativo de un dominio. Esto afecta directamente a la forma en que los subdominios heredan políticas de sus dominios principales y cierra brechas que los atacantes han utilizado para eludir protecciones contra la suplantación aplicadas de forma desigual.
• Alineación más clara y tratamiento del correo indirecto. La especificación refuerza la lógica de alineación, sobre todo en la diferencia entre el tratamiento relajado y el estricto, y estandariza el manejo de flujos de correo indirectos, como el reenvío y las listas de distribución, que durante años han provocado falsos fallos.
• Informes separados en especificaciones complementarias. Los informes agregados (RUA) y los informes de fallos (RUF) se han separado de la especificación principal y pasan a documentos propios, de modo que puedan evolucionar de forma independiente. Los informes incorporan nuevo contexto relacionado con RFC 9989, incluidos campos para el método de descubrimiento y el estado de prueba, y los selectores DKIM pasan a ser obligatorios cuando se notifican resultados DKIM.

Por qué es importante

El momento de la publicación es lo más relevante. Durante los dos últimos años, los principales proveedores de correo han elevado de forma constante los requisitos de autenticación de remitentes y han empujado a quienes gestionan dominios hacia políticas de aplicación efectiva. RFC 9989 acelera ese cambio al eliminar ambigüedades históricas. Como resultado, los receptores interpretarán las políticas de forma más coherente y los fallos de autenticación serán más visibles y dependerán menos de las particularidades de implementación de cada proveedor.

Para la defensa, es un avance claramente positivo frente al tipo de suplantación tratado antes en este informe. El phishing que suplanta marcas o utiliza insignias de verificación funciona, en parte, porque una aplicación desigual de la autenticación deja margen a dominios parecidos o falsificados. Una evaluación DMARC más estricta y estandarizada reduce ese margen. El coste práctico es que las organizaciones con una infraestructura de envío extensa o mal inventariada pueden ver cómo los mensajes legítimos se marcan con más agresividad durante la transición si la alineación no está bien configurada. El trabajo que toca hacer ahora es poco llamativo, pero conocido: inventariar todas las fuentes de envío, validar la alineación con las nuevas reglas de descubrimiento y avanzar hacia una política de aplicación antes de que los receptores terminen de adoptar el estándar. Una solución de confianza para gestionar DMARC puede facilitar este proceso.

Previsiones para los próximos meses

• Los actores de amenazas agénticos pasarán de la prueba de concepto a las herramientas de uso habitual. JadePuffer demuestra que un agente de IA puede encadenar vulnerabilidades conocidas hasta completar una operación de extorsión. Esperamos que la actividad posterior se centre en frameworks de aplicaciones expuestos a Internet, herramientas de IA y datos, almacenes de configuración e interfaces administrativas de bases de datos accesibles desde el exterior, ya que son objetivos que un operador automatizado puede rastrear a gran escala. La economía favorece el volumen, por lo que cabe esperar más intentos contra más objetivos, en lugar de intrusiones individuales más sofisticadas.
• El descubrimiento de vulnerabilidades asistido por IA seguirá aumentando el volumen de parches, y la velocidad de parcheado separará a las organizaciones resilientes de las expuestas. Es poco probable que el récord del Patch Tuesday de junio sea una excepción. A medida que el descubrimiento crezca más rápido que la corrección, el periodo entre la divulgación y la explotación se convertirá en la variable decisiva, sobre todo para los sistemas expuestos a Internet.
• Exchange Server instalado en local seguirá siendo un objetivo prioritario. Con CVE-2026-42897 en explotación activa y un largo historial de fallos de Exchange que atraen al ransomware, las organizaciones que no hayan terminado de migrar desde Exchange instalado en local, o que no puedan aplicar parches con rapidez, seguirán apareciendo en informes de incidentes durante la segunda mitad de 2026.
• Los señuelos de verificación de marca se extenderán más allá de Meta y del robo de credenciales. El modelo de secuestro de cuentas analizado este mes, que obtiene códigos MFA y documentos de identidad además de contraseñas, puede adaptarse a cualquier plataforma que ofrezca una insignia de verificación o confianza. Es previsible que el pretexto se traslade a marcas de redes sociales, servicios financieros y plataformas de compraventa.
• La adopción de DMARC RFC 9989 será desigual durante la transición. A medida que los receptores implementen las nuevas reglas de descubrimiento del dominio organizativo y de alineación según sus propios calendarios, las organizaciones con inventarios incompletos de fuentes de envío deben prever problemas intermitentes de entregabilidad. Los atacantes buscarán dominios en los que difieran las interpretaciones antiguas y nuevas.

Recomendaciones del mes

• Refuerza y haz inventario de las aplicaciones y herramientas de IA expuestas a Internet. Aplica el parche de CVE-2025-3248 en Langflow, rota las credenciales y las claves de firma predeterminadas, incluidas las claves JWT predeterminadas de Nacos y las credenciales predeterminadas de MinIO, y limita las interfaces administrativas de bases de datos y configuración a redes conocidas. Los atacantes agénticos enumeran primero estas superficies, y los controles que detienen a una persona atacante también detienen a un agente.
• Aplica ahora las actualizaciones de Microsoft de junio y da prioridad a la vulnerabilidad zero-day de Exchange Server que se está explotando. Trata CVE-2026-42897 como un cambio de emergencia en cualquier implementación local de Exchange Server 2016, 2019 o Subscription Edition y confirma que las mitigaciones de Exchange Emergency Mitigation Service (EEMS) están activas cuando no sea posible actualizar de inmediato. En las organizaciones cuyo principal riesgo sea el correo entrante, da la misma prioridad a las correcciones críticas de ejecución remota de código de Office, Outlook, Word y Excel.
• Forma a las personas usuarias para que reconozcan señuelos basados en recompensas e insignias de verificación, no solo amenazas. La campaña de Meta que analizamos empieza con una oferta, no con una advertencia, y solicita códigos MFA y documentos de identidad. Refuerza mediante formación de concienciación en seguridad que las plataformas legítimas nunca piden contraseñas, códigos MFA ni documentos de identidad desde un enlace recibido por correo y que el estado de verificación siempre debe comprobarse directamente en la plataforma oficial.
• Vuelve a validar tu configuración de DMARC antes de la adopción de RFC 9989. Haz inventario de todas las fuentes de envío legítimas, confirma la alineación de SPF y DKIM con las nuevas reglas de descubrimiento del dominio organizativo, actualiza los informes para recoger los nuevos campos de RFC 9989 y avanza hacia una política de aplicación (p=reject) antes de que los receptores terminen de desplegar el estándar. Una evaluación DMARC coherente y estandarizada es una de las defensas estructurales más eficaces contra la suplantación de marcas tratada en este informe.
• Integra escenarios de ataque agéntico en la priorización de parches y la gestión de la exposición. Da por hecho que el intervalo entre la divulgación pública y la explotación activa de fallos expuestos a Internet seguirá reduciéndose. Mantén un inventario exacto de la superficie de ataque externa, vincula la prioridad de los parches a la exposición real y no solo a la puntuación de gravedad, y practica la aplicación rápida de parches de emergencia en sistemas expuestos a Internet.

---

Acerca de Hornetsecurity

Hornetsecurity es un proveedor líder mundial de soluciones de seguridad, cumplimiento normativo, backup y concienciación sobre seguridad de última generación, basadas en la nube y que ayuda a empresas y organizaciones de todos los tamaños en todo el mundo. Su producto estrella, 365 Total Protection, es la solución de seguridad en la nube para Microsoft 365 más completa del mercado. Impulsada por la innovación y la excelencia en ciberseguridad, Hornetsecurity está construyendo un futuro digital más seguro y una cultura de seguridad sostenible gracias a su galardonado portfolio. Hornetsecurity opera en más de 120 países a través de su red de distribución internacional de más de 12.000 partners y MSPs. Sus servicios premium son utilizados por más de 125.000 clientes. Para más información, visite hornetsecurity.com