Entradas de blog etiquetadas con ' #ransomware '

¿Cuál es la amenaza?

ConnectWise Cloud Backup utiliza una identidad de aplicación de Microsoft 365 para acceder a los datos de los clientes y realizar copias de seguridad. Según investigadores de seguridad y ConnectWise, los atacantes comprometieron las credenciales vinculadas a esta aplicación y las utilizaron para obtener tokens de autenticación en los entornos de Microsoft 365 de clientes y socios.

Los permisos actuales de la aplicación podrían permitir a los atacantes acceder a los datos del buzón, archivos, contenido de Teams e información del directorio. Dado que el acceso está vinculado a la aplicación y no a una cuenta de usuario, cambiar la contraseña por sí solo podría no eliminar el riesgo.

¿Por qué es digno de mención?

Este incidente es relevante porque involucra una aplicación de terceros de confianza con acceso previo a entornos de Microsoft 365. Los atacantes podrían usar esos permisos para obtener tokens de Microsoft Graph y acceder a datos en los inquilinos afectados.

El monitoreo de seguridad ha detectado inicios de sesión no autorizados vinculados a credenciales comprometidas en múltiples entornos de clientes y socios. Este incidente pone de manifiesto los riesgos asociados con identidades de aplicaciones comprometidas e integraciones en la nube de confianza.

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

Las organizaciones que utilizan ConnectWise Cloud Backup podrían sufrir accesos no autorizados a los datos de Microsoft 365, dependiendo de los permisos otorgados a la aplicación. Los datos expuestos podrían incluir mensajes de correo electrónico, archivos adjuntos, archivos de OneDrive y SharePoint, datos de Teams e información de directorio.

Dado que la vulnerabilidad implica el acceso a través de la aplicación, los atacantes podrían mantener el acceso incluso después de que los administradores cambien las contraseñas de los usuarios. En el peor de los casos, las organizaciones podrían sufrir la filtración de datos, la exposición de comunicaciones confidenciales y otras actividades maliciosas a través de los permisos delegados de la aplicación.

¿Cuáles son las recomendaciones?

1. Deshabilitar el acceso a la aplicación ConnectWise Cloud Backup

En el Centro de administración de Microsoft Entra, localice la aplicación SkyKick / ConnectWise Cloud Backup (ID de aplicación: 506e08f9-6e9a-4da4-942b-a099a03644ae) y deshabilite el acceso de inicio de sesión de usuario. No elimine la aplicación.

2. Revisar la actividad de inicio de sesión del principal de servicio

Revisar los registros de inicio de sesión del principal de servicio para el ID de aplicación afectado e investigar la actividad originada desde las siguientes direcciones IP: "144.172.64.128, 144.172.64[.]99, 144.172.64[.]60", o asociada con agentes de usuario de Python como "Python-urllib/3.12 y python-requests/2.31".

3. Investigue la actividad basada en aplicaciones.

Revise la actividad de las aplicaciones y los servicios de Microsoft 365 en busca de indicios de acceso no autorizado. No se fíe únicamente de los registros de inicio de sesión interactivos de los usuarios.

4. Revocar el acceso no autorizado

Si se detecta actividad sospechosa, revoque las sesiones y tokens activos y elimine los permisos o consentimientos no autorizados asociados con la aplicación afectada.

5. Implemente el bloqueo de red cuando sea apropiado.

Considere bloquear las direcciones IP "144.172.64.128, 144.172.64[.]99 y 144.172.64[.]60" como medida de seguridad adicional. Sin embargo, el bloqueo de red por sí solo podría no impedir la autenticación entre nubes.

Servicio XDR

Qilin: cuando el ransomware se convierte en un negocio organizado

Para comprender la relevancia de esta investigación, primero hay que entender qué representa Qilin.

A diferencia de un atacante que opera de manera aislada, Qilin funciona bajo el modelo de ransomware como servicio. Este esquema permite que los responsables de una plataforma criminal pongan herramientas e infraestructura a disposición de afiliados que ejecutan ataques contra diferentes organizaciones. Las ganancias se distribuyen de acuerdo con los acuerdos establecidos dentro de la operación.

En la práctica, se trata de un ecosistema criminal que busca crecer, atraer colaboradores y multiplicar sus oportunidades de extorsión.

Durante 2025, Qilin consolidó su presencia entre las principales operaciones de ransomware. Su actividad se extendió a organizaciones de distintos sectores y países, mientras que su infraestructura evolucionó para ofrecer más capacidades a sus afiliados.

La operación también habría ampliado sus servicios con herramientas para gestionar negociaciones, facilitar la comunicación con las víctimas y presionar a las organizaciones mediante la amenaza de publicar información robada.

Este último elemento es especialmente importante. El ransomware moderno no consiste únicamente en bloquear archivos. En muchos casos, los atacantes también extraen información confidencial y amenazan con divulgarla si la víctima se niega a pagar.

Así, una misma intrusión puede convertirse en dos mecanismos de presión: interrumpir las operaciones y poner en riesgo la privacidad de los datos.

Pero esta expansión también tiene un costo que los operadores criminales no pueden eliminar fácilmente: cada ataque genera actividad, conexiones y posibles evidencias que, analizadas en conjunto, pueden ayudar a reconstruir lo sucedido.

Un ataque que abrió la puerta a una investigación de 21 meses

En septiembre de 2024, una empresa de logística alemana sufrió un ataque atribuido a la operación Qilin. La información difundida sobre el caso señala que la organización habría pagado una suma cercana a los 100 millones de dólares para recuperarse del incidente y mantener la confidencialidad de sus datos.

La cifra resulta impactante, pero el aspecto más importante de la historia no es únicamente el monto de la extorsión. Es lo que ocurrió después.

Durante la investigación del ataque, las autoridades alemanas encontraron evidencias que describieron como una pequeña pieza de un rompecabezas mucho mayor. A partir de ese punto, la pesquisa se habría extendido más allá del incidente inicial.

La investigación, conocida como Operación ALBUS, buscaba identificar y rastrear a personas vinculadas con el ecosistema de Qilin. Para ello, las autoridades habrían combinado información técnica, análisis financieros y cooperación internacional.

Los detalles completos de la investigación no se han hecho públicos. Por ello, no es posible reconstruir con certeza cada paso ni determinar qué evidencia específica permitió identificar al sospechoso.

No obstante, los informes disponibles apuntan a una conclusión relevante: el trabajo de investigación no se limitó a analizar el ataque contra la empresa alemana. También buscó establecer posibles vínculos entre la actividad criminal, la infraestructura utilizada y las personas que supuestamente participaban en la operación.

El objetivo era pasar de las huellas dejadas por un ataque a la identificación de quienes podrían estar detrás de él.

De un alias digital a un sospechoso bajo custodia

Según los reportes publicados, los investigadores identificaron a un presunto integrante conocido por el alias «Snake», posteriormente identificado como Vladimir K., un ciudadano ruso de 28 años.

Las autoridades alemanas lo vinculan presuntamente con tareas de desarrollo dentro de Qilin y con la obtención de beneficios derivados de las actividades de extorsión. Estos señalamientos forman parte de las acusaciones contra el sospechoso y no deben interpretarse como una declaración de culpabilidad.

La investigación habría permitido seguir sus movimientos hasta conocer un próximo viaje a Japón. La información fue compartida con las autoridades japonesas, que lo detuvieron en un hotel de Osaka el 26 de mayo de 2026.

La detención marcó un momento decisivo: una investigación iniciada a partir de un ataque informático había logrado trasladar sus resultados al terreno físico, donde la cooperación entre países hizo posible localizar al sospechoso.

El caso todavía debía superar otro obstáculo. Una detención internacional no significa que la entrega del sospechoso al país investigador sea automática.

El desafío de llevar el caso de Japón a Alemania

Japón y Alemania no cuentan con un tratado bilateral de extradición. Por ello, las autoridades alemanas tuvieron que recurrir al procedimiento legal aplicable en Japón para solicitar la entrega del detenido.

Entre los aspectos relevantes de este tipo de procedimientos se encuentra el principio de doble incriminación: en términos generales, la conducta por la que se solicita la extradición debe constituir un delito conforme a los marcos legales aplicables de ambos países.

En este caso, las acusaciones descritas incluyen presuntas intrusiones informáticas, cifrado de datos y extorsión relacionada con ransomware.

Tras el procedimiento correspondiente, Vladimir K. fue extraditado a Alemania el 2 de octubre de 2026, de acuerdo con la información publicada sobre el caso.

El resultado representa un avance para la investigación, aunque no implica por sí mismo el desmantelamiento de Qilin. Una operación de ransomware como servicio puede involucrar múltiples afiliados, desarrolladores y operadores distribuidos en diferentes jurisdicciones.

La detención de una persona es una pieza importante, pero no necesariamente el final de la investigación.

La lección que deja el caso Qilin: los ataques no terminan cuando se recuperan los sistemas

La historia de Qilin permite observar dos dimensiones de un incidente de ransomware que a menudo se analizan por separado.

La primera es el impacto inmediato: interrupción de operaciones, pérdida de acceso a información, costos de recuperación y presión económica sobre la organización afectada.

La segunda aparece después del ataque: la investigación técnica, la preservación de evidencias, el análisis de las actividades sospechosas y la posibilidad de que la información recopilada ayude a identificar a los responsables.

Ambas dimensiones están conectadas.

Por eso, la respuesta ante el ransomware no debería centrarse exclusivamente en recuperar los sistemas una vez que ocurre el incidente. También es importante contar con mecanismos que permitan detectar comportamientos sospechosos, relacionar eventos de seguridad y conservar información útil para investigar lo sucedido.

Entre las medidas que pueden contribuir a reducir el impacto de estos ataques se encuentran:

• Detectar antes de que el daño escale. Identificar comportamientos anómalos en los equipos y las cuentas puede ayudar a intervenir antes de que una intrusión se convierta en un incidente de mayor alcance.
• Correlacionar eventos de seguridad. Una alerta aislada puede parecer poco relevante; varias señales relacionadas pueden revelar una actividad maliciosa que requiere atención inmediata.
• Contener la amenaza con rapidez. Aislar los equipos afectados y limitar los accesos comprometidos puede ayudar a frenar la propagación mientras se investiga el incidente.
• Preservar evidencias. Los registros, las alertas y los datos técnicos pueden ser esenciales para comprender cómo comenzó un ataque, qué sistemas afectó y qué acciones se llevaron a cabo.
• Preparar la respuesta antes de una crisis. Disponer de procedimientos definidos, respaldos protegidos y personal capaz de coordinar la investigación reduce la improvisación cuando cada minuto importa.

Ninguna de estas medidas garantiza que una organización nunca será atacada. Sin embargo, pueden mejorar su capacidad para detectar, contener y comprender una amenaza antes de que sus consecuencias sean mucho mayores.

Cuando cada rastro cuenta 

Qilin construyó una operación criminal capaz de aprovechar herramientas especializadas, colaboradores distribuidos y mecanismos de extorsión para ampliar su alcance. Sin embargo, el caso investigado por las autoridades alemanas y japonesas demuestra que la complejidad de estas organizaciones no las vuelve necesariamente imposibles de rastrear.

Un ataque puede parecer rentable para sus responsables en el momento en que reciben un pago. Pero las consecuencias de esa intrusión pueden prolongarse mucho más allá de la recuperación de la víctima.

La investigación de 21 meses recuerda que la ciberseguridad no consiste únicamente en impedir que una amenaza entre en una organización. También implica disponer de la visibilidad, la capacidad de análisis y los mecanismos de respuesta necesarios para actuar cuando algo falla.

Porque, en un entorno donde los atacantes buscan multiplicar sus oportunidades, la capacidad de conectar las señales a tiempo puede marcar la diferencia entre reaccionar ante un incidente y descubrirlo cuando el daño ya está hecho.

En Cobra Networks, la prevención, la detección y la respuesta forman parte de una estrategia integral para ayudar a las organizaciones a enfrentar amenazas cada vez más sofisticadas. Acércate a nuestro equipo para conocer las soluciones de ciberseguridad que pueden ayudarte a fortalecer la protección de tu empresa.

Phishing en tu correo electrónico

Un correo electrónico, dos objetivos.

El phishing tradicional se basa principalmente en la ingeniería social.

El atacante crea un mensaje diseñado para parecer confiable y utiliza diferentes recursos para provocar una acción por parte del destinatario: hacer clic, descargar un archivo, introducir información o seguir determinadas instrucciones.

Pero cuando un asistente de IA comienza a intervenir en el procesamiento de esos mensajes, el correo electrónico deja de ser únicamente una comunicación dirigida a una persona.

También puede convertirse en una entrada de información para un sistema automatizado.

Y eso abre una nueva posibilidad para los atacantes: intentar influir directamente en el comportamiento de la IA.

Las campañas pueden combinar técnicas tradicionales de ingeniería social dirigidas a los usuarios con inyecciones maliciosas de mensajes diseñadas para influir o anular el comportamiento esperado del asistente de IA.

En otras palabras, el mismo correo puede intentar engañar al humano y, al mismo tiempo, manipular a la inteligencia artificial.

Cuando la ingeniería social también apunta a la IA

Una de las características más importantes de este nuevo escenario es que los dos ataques pueden coexistir dentro del mismo mensaje.

Para el usuario, el atacante puede recurrir a técnicas conocidas de ingeniería social. Por ejemplo, utilizar un archivo adjunto protegido con contraseña para intentar generar confianza o dificultar el análisis automático de su contenido.

Pero mientras el usuario observa el correo, el asistente de IA puede estar procesando información completamente diferente.

Si el sistema analiza automáticamente el contenido del mensaje para generar un resumen, determinar su prioridad o ayudar al usuario a gestionar una solicitud, las instrucciones maliciosas incluidas dentro del correo pueden intentar influir en ese procesamiento.

Así, el atacante ya no depende exclusivamente de convencer a una persona.

También puede intentar convencer a la máquina que está ayudando a esa persona.

La IA se convierte en parte de la superficie de ataque

La adopción de asistentes de IA está modificando la manera en que los usuarios interactúan con el correo electrónico.

Un usuario puede recibir cientos de mensajes y apoyarse en la IA para identificar cuáles requieren atención. Puede utilizarla para resumir conversaciones extensas, analizar solicitudes, gestionar invitaciones o facilitar determinadas decisiones empresariales.

Esto aporta eficiencia, pero también significa que los sistemas de IA comienzan a consumir y procesar información procedente directamente de las bandejas de entrada.

Y esa información no siempre es confiable.

Un correo electrónico puede contener contenido diseñado específicamente para influir en el comportamiento del sistema que lo analiza. Por ello, el problema ya no consiste únicamente en determinar si un usuario podría caer en un phishing.

Ahora también es necesario considerar qué puede hacer una IA cuando recibe y procesa ese mismo contenido malicioso.

El nuevo reto para la seguridad del correo

Este cambio obliga a ampliar la perspectiva de protección.

Durante mucho tiempo, la estrategia de seguridad del correo electrónico se ha concentrado en proteger al usuario y detectar mensajes maliciosos antes de que lleguen a su bandeja de entrada.

Esa protección sigue siendo fundamental.

Pero a medida que los asistentes de IA adquieren un papel más importante en la gestión del correo, las organizaciones también deben considerar los sistemas que leen, interpretan y procesan esa información.

La bandeja de entrada deja de ser únicamente un espacio donde una persona recibe mensajes. Puede convertirse también en una fuente de datos para sistemas automatizados con capacidad de analizar información y participar en determinadas acciones.

Por eso, proteger el correo electrónico implica pensar más allá del usuario final.

Proteger al usuario y también a la inteligencia artificial

El phishing está evolucionando porque también está cambiando la forma en que trabajamos con el correo electrónico.

Los atacantes continúan utilizando técnicas de ingeniería social para manipular a las personas, pero ahora pueden intentar aprovechar una segunda capa: los sistemas de IA que procesan los mensajes antes, durante o después de que lleguen al usuario.

El análisis indica que un correo malicioso puede tener más de un objetivo.

Para las organizaciones, esto significa que la seguridad debe contemplar no solo la protección de los usuarios y sus bandejas de entrada, sino también los sistemas de inteligencia artificial que consumen y procesan los datos del correo electrónico.

Porque cuando la IA se convierte en parte de la forma en que gestionamos nuestros mensajes, también puede convertirse en parte de la superficie que debemos proteger.

El phishing ya no busca únicamente que hagas clic. Ahora también puede intentar que tu IA haga lo que el atacante quiere.

Como limitar el riesgo de ser vulnerable

Barracuda Email Gateway Defense ayuda a identificar y bloquear mensajes sospechosos, analizar archivos adjuntos en entornos aislados y aplicar controles en torno a tipos de archivos adjuntos de alto riesgo, incluidos los archivos protegidos con contraseña.

La IA conductual ayuda a identificar intentos de phishing, suplantación de identidad por correo electrónico empresarial y otros ataques que pueden eludir la detección tradicional basada en firmas.

Cuando una cuenta se ve comprometida, el sistema de respuesta automatizada ante amenazas puede contener rápidamente la amenaza eliminando los correos electrónicos maliciosos, deshabilitando el acceso sospechoso y corrigiendo los indicadores de compromiso.

Phishing en tu correo electrónico

MFA.

Durante años, una de las recomendaciones más importantes en ciberseguridad ha sido clara: utiliza autenticación multifactor.

Y sigue siendo un consejo fundamental.

Pero los atacantes están aprendiendo que, en lugar de intentar romper directamente los controles de seguridad, pueden buscar algo mucho más interesante: aprovechar la confianza que existe entre esos controles.

Ese es el concepto detrás de TrustSink, una técnica que pone el foco en Microsoft Entra ID y en los entornos de identidad federada.

En lugar de llevar a la víctima a una página de phishing evidentemente falsa, TrustSink busca insertarse en un flujo de autenticación legítimo mediante un proveedor de autenticación multifactor (MFA) malicioso.

El usuario cree que está iniciando sesión normalmente.

El sistema cree que está trabajando con un proveedor de confianza.

Mientras tanto, el atacante puede estar capturando las credenciales.

TrustSink cambia la pregunta: ¿en quién confías para autenticar a tus usuarios?

La fortaleza de un sistema de identidad federada depende, en gran medida, de las relaciones de confianza que existen dentro de él.

Las organizaciones utilizan proveedores de identidad, mecanismos de autenticación y servicios externos para facilitar el acceso seguro a aplicaciones y recursos corporativos.

TrustSink intenta convertir esa confianza en una oportunidad de ataque.

La técnica introduce un proveedor MFA malicioso dentro del proceso de autenticación. Cuando un usuario inicia sesión a través de un portal legítimo, sus credenciales pueden pasar por ese componente antes de completar el proceso de autenticación.

Esto abre la puerta a la captura de las contraseñas en tiempo real.

Y aquí está la diferencia fundamental frente al phishing tradicional:

el usuario no necesariamente está interactuando con una página falsa.

Está utilizando un flujo de autenticación que parece legítimo.

El problema no es solamente robar una contraseña

Una contraseña comprometida ya representa un riesgo.

Pero cuando esa contraseña pertenece a una identidad corporativa con acceso a Microsoft Entra ID, Microsoft 365, aplicaciones empresariales y recursos en la nube, el impacto potencial puede ser mucho mayor.

Una credencial válida puede convertirse en el punto de partida para:

• Acceder a aplicaciones y servicios corporativos.

• Consultar información confidencial.

• Comprometer otras cuentas.

• Intentar elevar privilegios.

• Realizar movimiento lateral.

• Mantener acceso persistente.

• Preparar ataques posteriores, incluido ransomware.

Por eso, la identidad se ha convertido en uno de los activos más importantes que una organización debe proteger.

Si un atacante controla una identidad legítima, puede intentar comportarse como un usuario legítimo.

Y eso hace que la detección sea mucho más complicada.

Cuando el ataque utiliza la infraestructura legítima

Esta es probablemente la característica más preocupante de TrustSink.

El phishing tradicional intenta engañar al usuario para que abandone el entorno legítimo y entre en una página controlada por el atacante.

TrustSink plantea otro escenario.

El atacante busca aprovechar el propio ecosistema de autenticación y las relaciones de confianza existentes.

Esto puede reducir algunas de las señales que normalmente ayudan a detectar un ataque de phishing.

No necesariamente hay una página con una URL extraña.

No necesariamente existe un correo lleno de errores.

No necesariamente el usuario recibe una alerta evidente.

En cambio, el ataque intenta integrarse en un proceso que la víctima ya reconoce como normal.

La confianza deja de ser únicamente una defensa y se convierte en parte de la superficie de ataque.

MFA sigue siendo importante. Pero MFA no puede tratarse como una solución aislada

TrustSink también deja una lección importante sobre la autenticación multifactor.

MFA continúa siendo uno de los controles más importantes para reducir el riesgo asociado con credenciales robadas. Sin embargo, ningún mecanismo de seguridad debería considerarse una barrera absoluta.

Los atacantes están evolucionando.

Ya no se limitan a intentar obtener una contraseña mediante phishing. También buscan manipular sesiones, robar tokens, explotar procesos de autenticación y abusar de relaciones de confianza.

Por eso, proteger la identidad requiere una estrategia más amplia.

No basta con preguntar “¿el usuario tiene MFA?”.

También debemos preguntar:

¿Quién puede modificar la configuración de autenticación?

¿Qué proveedores externos están autorizados?

¿Qué relaciones de federación existen?

¿Qué cambios se están realizando?

¿Desde dónde se están produciendo las autenticaciones?

¿El comportamiento coincide realmente con el usuario?

Estas preguntas forman parte de una estrategia de seguridad de identidad mucho más robusta.

¿Quién está más expuesto?

El riesgo es especialmente relevante para organizaciones que dependen de Microsoft Entra ID con configuraciones de identidad federada y mantienen relaciones con proveedores externos de identidad o autenticación.

Una gobernanza deficiente puede ampliar considerablemente la superficie de ataque.

Por ejemplo, una organización puede tener dificultades para detectar o controlar:

• Proveedores de identidad externos que ya no deberían tener acceso.

• Configuraciones de federación excesivamente permisivas.

• Usuarios con privilegios para modificar mecanismos de autenticación.

• Cambios inesperados en proveedores MFA.

• Actividad de autenticación anómala.

• Relaciones de confianza que no han sido revisadas recientemente.

El problema es que una configuración que alguna vez fue necesaria puede convertirse, con el tiempo, en una puerta que nadie recuerda que dejó abierta.

¿Cómo reducir el riesgo de TrustSink?

La defensa comienza por recuperar visibilidad sobre quién y qué tiene capacidad para intervenir en los procesos de autenticación.

Barracuda recomienda adoptar varias medidas:

1. Revisar las relaciones de confianza

Audite periódicamente los proveedores de identidad externos y las configuraciones de MFA asociadas a Microsoft Entra ID.

La pregunta no debería ser únicamente “¿funciona?”, sino también “¿sigue siendo necesario y confiable?”

2. Aplicar controles estrictos de acceso

Utilice políticas de acceso condicional para limitar la autenticación proveniente de proveedores no autorizados o que no cumplan los requisitos de seguridad establecidos.

3. Vigilar los cambios en la federación

Habilite registros y alertas avanzadas para detectar modificaciones inesperadas en la configuración de identidad, proveedores de autenticación y relaciones de federación.

Un cambio aparentemente pequeño puede tener consecuencias importantes.

4. Reducir los privilegios administrativos

Limite el número de usuarios capaces de modificar configuraciones de federación o agregar proveedores externos de autenticación.

Cuantas menos identidades puedan cambiar las reglas de confianza, menor será la superficie de ataque.

5. Adoptar un enfoque Zero Trust

No asuma que una identidad, dispositivo o proveedor es confiable simplemente porque ya se encuentra dentro del ecosistema.

La confianza debe evaluarse continuamente antes de conceder acceso a recursos sensibles.

6. Considerar métodos de autenticación resistentes al phishing

Siempre que sea posible, las organizaciones deberían evaluar mecanismos como claves de seguridad FIDO2 o autenticación basada en certificados, reduciendo la dependencia de métodos que puedan ser susceptibles a determinadas técnicas de robo de credenciales.

La nueva batalla por la identidad

TrustSink representa una evolución importante en la forma en que debemos pensar sobre la seguridad de las identidades.

Durante mucho tiempo, la estrategia consistía en proteger las credenciales.

Después, añadimos MFA para protegerlas mejor.

Ahora los atacantes están buscando algo más sofisticado:

atacar el sistema que determina en quién confiamos para autenticar esas identidades.

Ese cambio obliga a las organizaciones a ampliar su perspectiva.

La seguridad de identidad no consiste únicamente en proteger nombres de usuario y contraseñas. También implica proteger las relaciones, configuraciones, proveedores y privilegios que hacen posible la autenticación.

Porque si un atacante consigue robar una contraseña, tenemos un problema.

Pero si consigue que el sistema confíe en él para obtenerla, tenemos un problema mucho mayor.

La lección de TrustSink es clara: en un entorno donde la identidad se ha convertido en el nuevo perímetro, la confianza también debe ser protegida.

Phishing en tu correo electrónico

NetScaler puede convertirse en la puerta de entrada.

¿Qué está ocurriendo con Citrix NetScaler?

Las dos vulnerabilidades afectan a productos utilizados habitualmente para proporcionar acceso remoto y servicios de entrega de aplicaciones.

El riesgo aumenta porque los dispositivos NetScaler suelen encontrarse directamente expuestos a Internet. Si un atacante consigue explotarlos, puede obtener una posición privilegiada desde la cual intentar avanzar hacia otros recursos de la organización.

Las vulnerabilidades identificadas son:

CVE-2026-88771 — CVSS 9.5

Se trata de una vulnerabilidad relacionada con una validación incorrecta de entradas que puede permitir a un atacante no autenticado ejecutar comandos arbitrarios.

En otras palabras, el atacante no necesita contar previamente con credenciales válidas para intentar aprovechar la vulnerabilidad.

CVE-2026-88772 — CVSS 9.5

La segunda vulnerabilidad corresponde a un desbordamiento de memoria que puede provocar ejecución remota de código o una condición de denegación de servicio.

Esta vulnerabilidad está asociada a dispositivos con DTLS habilitado, una configuración especialmente relevante porque DTLS está habilitado de forma predeterminada para los servidores virtuales VPN.

El verdadero riesgo: NetScaler como puente hacia la red interna

Aquí es donde el escenario se vuelve especialmente preocupante.

Los investigadores no solo observaron la explotación de las vulnerabilidades. También identificaron el uso de web shells y herramientas de tunelización.

La tunelización permite redirigir tráfico a través de un dispositivo comprometido. Desde la perspectiva del atacante, esto puede convertir un NetScaler expuesto a Internet en una especie de puente hacia recursos que originalmente no estaban disponibles desde el exterior.

Imaginemos el escenario:

Internet → NetScaler vulnerable → acceso inicial → túnel → red interna

Por eso, limitar el análisis a “¿el servidor fue comprometido?” puede ser insuficiente.

La pregunta debería ser:

“Si este dispositivo fue comprometido, ¿hasta dónde pudo llegar el atacante?”

Una vez conseguido el acceso, los atacantes pueden intentar descubrir sistemas internos, acceder a recursos adicionales, robar credenciales o mantener persistencia dentro del entorno.

Más de 50,000 instancias podrían estar expuestas

El alcance potencial de la campaña también resulta preocupante.

Hasta el 27 de septiembre, Palo Alto Networks había identificado más de 50,277 instancias de NetScaler expuestas a Internet que podrían ser vulnerables.

Además, el Centro Nacional de Ciberseguridad de los Países Bajos (NCSC-NL) informó haber recibido información sobre estas vulnerabilidades a través de un socio europeo y señaló actividad de explotación contra clientes de Citrix en diferentes partes del mundo.

Esto cambia completamente la prioridad.

No estamos ante una vulnerabilidad que simplemente deba añadirse a la próxima ventana de mantenimiento.

Existe evidencia de explotación activa.

Y cuando un dispositivo de acceso remoto está involucrado, el tiempo entre la explotación inicial y el movimiento hacia otros sistemas puede ser crítico.

¿Qué versiones de NetScaler están afectadas?

Las vulnerabilidades afectan a diferentes ramas de NetScaler ADC y NetScaler Gateway:

• NetScaler 14.1

• NetScaler 13.1

• NetScaler 14.1 FIPS

• NetScaler 13.1 FIPS/NDcPP

Un aspecto especialmente importante es que CVE-2026-88771 afecta a todas las implementaciones de NetScaler ADC y NetScaler Gateway y no requiere que se active una función adicional.

En el caso de CVE-2026-88772, el riesgo está asociado a implementaciones con DTLS habilitado. Dado que esta configuración está habilitada de forma predeterminada para servidores virtuales VPN, los entornos NetScaler Gateway deben considerarse especialmente relevantes.

¿Qué deben hacer las organizaciones?

La prioridad parchear cuando antes.

Producto / versión Versión corregida

NetScaler ADC / Gateway 14.1 14.1-73.37 o posterior

NetScaler ADC / Gateway 13.1 13.1-64.23 o posterior

NetScaler ADC 14.1 FIPS 14.1-73.37 FIPS o posterior

NetScaler ADC 13.1 FIPS / NDcPP 13.1-37.279 o posterior

Sin embargo, aplicar el parche no sería el unico paso.

¿Y si el atacante ya estaba dentro antes de instalar el parche?

Antes o durante el proceso de remediación, las organizaciones deberían revisar los avisos de Citrix y buscar indicadores de compromiso relacionados con la explotación.

También es importante investigar:

• Actividad sospechosa en los dispositivos NetScaler.

• Presencia de web shells.

• Herramientas o conexiones de tunelización inesperadas.

• Conexiones anómalas desde NetScaler hacia sistemas internos.

• Cambios no autorizados en configuraciones.

• Credenciales potencialmente expuestas.

• Sesiones activas que pudieran haber sido comprometidas.

• Actividad posterior a la explotación.

Si existe evidencia de compromiso, la respuesta debe ir más allá de actualizar el dispositivo.

Puede ser necesario revisar credenciales, sesiones, accesos privilegiados y actividad lateral dentro de la red.

NetScaler es el objetivo. La organización completa puede ser el premio

Este incidente deja una lección importante para cualquier organización que utilice dispositivos de acceso remoto expuestos a Internet.

El riesgo de una vulnerabilidad crítica no se limita al componente afectado.

Un atacante puede utilizar ese primer punto de entrada para intentar avanzar hacia sistemas que contienen identidades, aplicaciones, información sensible y datos corporativos.

Por eso, la estrategia de defensa debe contemplar dos momentos:

Antes del compromiso: reducir la superficie de ataque, mantener los sistemas actualizados, aplicar controles de acceso y monitorizar los activos expuestos.

Después de una posible explotación: detectar actividad anómala, investigar indicadores de compromiso, proteger credenciales y sesiones, contener el movimiento lateral y responder rápidamente.

La ventana de oportunidad del atacante también es una ventana de oportunidad para defenderse

Las vulnerabilidades CVE-2026-88771 y CVE-2026-88772 demuestran nuevamente por qué los dispositivos expuestos a Internet requieren una atención prioritaria.

Con una puntuación CVSS de 9.5, explotación activa y evidencia de técnicas diseñadas para acceder más allá del dispositivo comprometido, el mensaje para las organizaciones es sencillo:

No basta con saber que existe una vulnerabilidad. Hay que saber si ya fue explotada.

Actualizar NetScaler es un paso fundamental. Pero verificar el entorno, investigar posibles indicios de compromiso y evaluar qué pudo ocurrir después de una intrusión es igual de importante.

Porque cuando el perímetro cae, la verdadera batalla comienza dentro de la red.

Phishing en tu correo electrónico

¿Cuál es la amenaza?

Feral Wolf es un grupo de ransomware con fines lucrativos que ataca a organizaciones explotando sistemas empresariales expuestos, configuraciones débiles y software vulnerable. El grupo lleva a cabo un extenso reconocimiento, establece accesos encubiertos, se esfuerza por ocultar su actividad e implementa el ransomware GenieLocker.

¿Por qué es digno de mención?

El grupo enruta el tráfico de comando y control a través de túneles basados ​​en MQTT, Matrix y RDP para mimetizarse con la actividad legítima, lo que dificulta su detección. Los atacantes también utilizan herramientas y scripts antiforense para borrar registros, historial de línea de comandos y otros elementos clave, lo que puede obstaculizar la respuesta a incidentes y las investigaciones.

Un ataque exitoso puede provocar la vulneración de toda la red, la interrupción de la actividad empresarial, el cifrado de datos, la pérdida de pruebas forenses y prolongados esfuerzos de recuperación.

¿Cuál es la exposicion o riesgo?

El riesgo se deriva de una combinación de vulnerabilidades y prácticas de seguridad deficientes. La vulnerabilidad CVE-2023-22515 proporciona acceso inicial a través de Confluence, mientras que las vulnerabilidades CVE-2021-4034 y CVE-2026-31431 permiten la escalada de privilegios una vez que los atacantes obtienen acceso a un host.

En la actividad reportada, los atacantes también explotaron sistemas 1C: Enterprise con seguridad deficiente y credenciales de base de datos débiles. Esto demuestra que la aplicación de parches por sí sola no es suficiente cuando las interfaces administrativas permanecen expuestas o carecen de autenticación.

¿Cuáles son las recomendaciones?

La seguridad moderna necesita reducir la dependencia de que cada usuario sea capaz de reconocer una amenaza. La capacitación y la concientización siguen siendo importantes, pero una organización no debería dejar toda la responsabilidad en el momento del clic. Por lo que las siguientes recomendaciones permiten mitigar el impacto de la vulnerabilidad:

• Aplique parches o actualice las instancias afectadas de Confluence Server y Data Center, e investigue si existen cuentas o complementos no autorizados.
• Actualizar los núcleos de Linux y los paquetes polkit para solucionar las vulnerabilidades CVE-2021-4034 y CVE-2026-31431.
• En la medida de lo posible, elimine la exposición directa a Internet de Confluence, los gestores de clústeres 1C, las bases de datos y los servicios administrativos.
• Implemente una autenticación sólida para 1C:Enterprise, PostgreSQL y otras interfaces administrativas.
• Revise Docker, PostgreSQL y los controles de aislamiento de host/red para evitar el movimiento de contenedores entre hosts.

Phishing en tu correo electrónico

¿Qué ocurre después de que un ataque de phishing con clave de acceso tenga éxito?

Lo primero que llama la atención en la investigación de Microsoft es que los atacantes no estaban realmente interesados en las claves de acceso. Estas solo eran un señuelo. El verdadero objetivo era acceder a las cuentas de Microsoft 365. Una vez que lo consiguieron, la campaña se diferenció mucho de un ataque de phishing tradicional.

Los atacantes añadieron métodos de autenticación que controlaban. Exploraron el entorno de Microsoft 365. Identificaron información valiosa. Luego comenzaron a recopilarla. En algunos casos, esta actividad se prolongó durante días.

Eso es lo que hace que esta campaña sea importante. El compromiso no fue el evento en sí, sino el comienzo.

¿Por qué los atacantes se centran en la persistencia tras una brecha de seguridad en Microsoft 365?

Aquí es donde las cosas se complican para los defensores. Microsoft observó que los atacantes utilizaban Microsoft Graph, SharePoint, OneDrive, Exchange Online y otros servicios legítimos de Microsoft 365. Ninguna de estas actividades es inusual en sí misma. Los empleados buscan archivos, acceden a SharePoint, leen correos electrónicos y utilizan aplicaciones empresariales. A simple vista, gran parte de la actividad de los atacantes parecía idéntica.

El peligro solo se hizo evidente cuando se conectaron esos eventos. Tras un inicio de sesión exitoso, se realizaron cambios en la autenticación multifactor (MFA). Estos cambios fueron seguidos por un reconocimiento del inquilino. El reconocimiento fue seguido por el acceso al buzón de correo y la recopilación de archivos.

Considerados individualmente, estos eventos parecían normales. Vistos en conjunto, revelaron un ataque que se propagaba a través del entorno.

¿Por qué el robo de identidad se considera un incidente de seguridad en la nube?

Durante años, las conversaciones sobre seguridad del correo electrónico se centraron en evitar que los mensajes maliciosos llegaran a las bandejas de entrada. Eso sigue siendo importante, pero ataques como este ponen de manifiesto un desafío mucho mayor.

Una vez que los atacantes obtienen acceso a una identidad de Microsoft 365, ya no se limitan a atacar el correo electrónico. Su objetivo son las herramientas de colaboración, el almacenamiento en la nube, las comunicaciones internas, los procesos de negocio y el conocimiento organizacional.

En ese punto, te enfrentas a mucho más que un simple ataque de phishing. Te enfrentas a un incidente de seguridad en la nube.

La seguridad se convierte en un problema diferente después de la autenticación.

La investigación de Microsoft refuerza una idea que muchos equipos de seguridad ya observan en la práctica: los controles de identidad robustos siguen siendo esenciales. Tecnologías como las claves de acceso, Microsoft Entra, el acceso condicional, Microsoft Defender y Exchange Online Protection proporcionan una base sólida para proteger los entornos de Microsoft 365.

Pero el desafío cambia tras la autenticación. Las preguntas clave son: ¿Ha comenzado una cuenta comprometida a enviar mensajes sospechosos? ¿Se ha añadido un nuevo método de autenticación? ¿Se está produciendo alguna actividad inusual en el buzón de correo? ¿Ha comenzado alguien a recopilar archivos de SharePoint o OneDrive sin que se den cuenta?

Estas son las señales que suelen aparecer más adelante en el ciclo de vida del ataque. También explican por qué muchas organizaciones están haciendo mayor hincapié en la detección de robo de cuentas, la remediación continua y la seguridad posterior a la entrega , junto con los controles de prevención tradicionales.

El objetivo no es simplemente bloquear las amenazas en la puerta principal. Se trata de comprender qué sucede si una logra entrar.

¿Cómo pueden los equipos de seguridad detectar los ataques posteriores al inicio de sesión?

Quizás la lección más importante de esta campaña es que nadie habría comprendido el ataque analizando un solo evento. Ni el inicio de sesión. Ni el registro de MFA. Ni la actividad del buzón de correo. Ni el acceso a SharePoint. Ni las solicitudes de Microsoft Graph.

Microsoft señaló específicamente que la actividad de Graph debe evaluarse mediante la progresión del comportamiento y la correlación entre eventos, en lugar de solicitudes individuales aisladas. Esta observación es válida mucho más allá de esta campaña. Los ataques modernos rara vez se limitan a un solo lugar. Se propagan a través de identidades, buzones de correo, aplicaciones, servicios en la nube y datos.

El reto consiste en conectar esas señales antes de que el atacante tenga tiempo de lograr su objetivo.

¿Qué deberían aprender las organizaciones de los ataques de phishing con claves de acceso?

Sería fácil leer esta historia y concluir que trata sobre contraseñas. Pero no es así. Las contraseñas siguen siendo una de las tecnologías de autenticación más seguras disponibles.

La lección más importante es que los atacantes siguen buscando maneras de sortear los controles de seguridad explotando algo mucho más difícil de defender que la tecnología: la confianza. Y una vez que entran, suelen ser pacientes.

Para las organizaciones que utilizan Microsoft 365, unos controles de identidad sólidos son solo una parte de la solución. Ataques como este ponen de manifiesto la importancia de detectar rápidamente las cuentas comprometidas, mitigar continuamente las amenazas emergentes y conectar la actividad entre identidades, correo electrónico, servicios en la nube y datos.

Porque el verdadero riesgo no reside en la concesión inicial, sino en todo lo que sucede después.

Filtrado de contenido

La IA está compitiendo por el presupuesto de TI

La adopción de inteligencia artificial requiere inversión. Infraestructura, plataformas, software especializado, procesamiento de datos y nuevas herramientas forman parte de una ecuación que está obligando a muchas organizaciones a redistribuir sus recursos.

De acuerdo con la encuesta, 18 % de los participantes afirmó que su organización ha reasignado parte del presupuesto destinado a software de seguridad para financiar la adopción de IA. A primera vista, podría parecer una señal de presión para los equipos de ciberseguridad. Sin embargo, el comportamiento de otras áreas de TI muestra una diferencia importante.

Mientras el gasto en software de seguridad continúa creciendo, 47 % de los encuestados señaló reducciones en herramientas de operaciones y monitorización de TI, y 46 % reportó recortes en herramientas de productividad y colaboración para financiar iniciativas de IA.

La diferencia también aparece cuando se analiza el personal. Las organizaciones están replanteando sus necesidades en soporte técnico y mesa de ayuda, desarrollo de software, operaciones, infraestructura y administración de TI. En ciberseguridad, en cambio, la reducción prevista es menor: 23 % de los encuestados espera disminuir su plantilla de profesionales de seguridad.

La razón puede encontrarse en un aspecto fundamental: la misma tecnología que permite automatizar tareas también está proporcionando nuevas capacidades a los atacantes.

Cuando los atacantes también tienen IA

La discusión sobre inteligencia artificial suele concentrarse en cuánto trabajo puede automatizar una organización. Sin embargo, existe otra pregunta que resulta igual de importante: ¿qué ocurre cuando esa misma capacidad está disponible para los ciberdelincuentes?

La IA puede ayudar a acelerar la creación de contenido malicioso, automatizar procesos, analizar grandes cantidades de información y adaptar ataques con una velocidad que difícilmente podría alcanzarse mediante procesos completamente manuales.

Esto cambia las reglas del juego. Un atacante no necesariamente necesita reemplazar todas sus herramientas actuales por sistemas de IA; basta con utilizarla para aumentar la velocidad, escala y eficiencia de operaciones que ya realizaba.

Para las empresas, esto significa que detectar una amenaza después de que el daño ocurrió resulta cada vez menos viable. La seguridad necesita evolucionar hacia modelos capaces de analizar grandes volúmenes de eventos, identificar comportamientos anómalos y responder antes de que una amenaza pueda convertirse en un incidente mayor.

Y aquí aparece una de las principales paradojas de la transformación impulsada por IA: la automatización puede reducir determinadas tareas manuales, pero también puede generar más trabajo de seguridad que nunca.

Menos personal no significa necesariamente menos trabajo

La encuesta de ETR muestra que 96% de las organizaciones utiliza IA en algún nivel. Al mismo tiempo, 34 % está limitando el crecimiento futuro de sus plantillas y 20 % afirma estar reduciendo estratégicamente su personal a medida que adopta estas tecnologías.

Sin embargo, la inversión general en TI continúa creciendo. Los encuestados reportaron un incremento interanual de 3.8 % en el gasto de TI, mientras que 72 % afirmó que su organización planea continuar aumentando esa inversión.

Esto plantea una situación interesante. Las empresas pueden estar buscando hacer más con menos personas, pero la tecnología también permite que los equipos existentes asuman tareas que anteriormente simplemente no podían realizar por falta de tiempo o recursos.

En ciberseguridad, esta diferencia es especialmente importante. Una herramienta automatizada puede analizar miles de eventos en cuestión de segundos, pero alguien debe definir qué se considera una amenaza, establecer las reglas de respuesta, investigar los casos complejos y validar que las acciones automatizadas sean las adecuadas.

La IA puede convertirse en un multiplicador de capacidades. No necesariamente en un sustituto absoluto del conocimiento especializado.

El reto es todavía mayor para las pymes

Para las pequeñas y medianas empresas, esta transformación puede representar tanto una oportunidad como un desafío.

Durante años, muchas pymes han tenido dificultades para contratar y retener profesionales especializados en ciberseguridad. Los puestos vacantes podían permanecer abiertos durante meses, mientras las empresas competían por un grupo limitado de especialistas.

La incorporación de IA y automatización puede ayudar a reducir parte de esa presión. Las organizaciones pueden utilizar tecnología para automatizar tareas repetitivas, priorizar alertas y proporcionar mayor visibilidad sobre lo que ocurre en sus entornos.

Pero automatizar no elimina la necesidad de experiencia. Al contrario, cuando las amenazas se vuelven más rápidas y sofisticadas, comprender lo que ocurre detrás de una alerta puede ser todavía más importante.

Para una pyme, la pregunta ya no debería limitarse a cuántas personas necesita incorporar a su equipo de seguridad. También debe considerar cuánto trabajo puede automatizar, qué capacidades necesita mantener internamente y qué funciones puede respaldar mediante servicios especializados.

La nueva ecuación de la ciberseguridad

Todavía es demasiado pronto para determinar exactamente cómo transformará la IA al mercado laboral de ciberseguridad. Lo que sí comienza a quedar claro es que la ecuación no puede reducirse simplemente a "IA = menos personas".

Los atacantes también adoptarán estas tecnologías. Si consiguen utilizarlas para aumentar simultáneamente el volumen y la sofisticación de sus ataques, las organizaciones necesitarán capacidades de defensa capaces de responder a esa misma escala.

Esto podría llevar a un escenario donde humanos y sistemas de IA trabajen conjuntamente: agentes automatizados encargándose de grandes cantidades de eventos y tareas repetitivas, mientras los profesionales especializados supervisan, investigan, toman decisiones y gestionan los casos que requieren contexto y criterio.

El verdadero desafío estará en administrar correctamente ese ecosistema. Porque incluso los sistemas automatizados necesitan supervisión, reglas, objetivos y controles. Una organización no puede asumir que una herramienta será capaz de tomar siempre la decisión correcta simplemente porque utiliza inteligencia artificial.

La ciberseguridad no desaparece: evoluciona

La llegada de la IA está obligando a las empresas a reconsiderar cómo distribuyen sus presupuestos, cómo contratan personal y qué tareas pueden automatizar. Pero la necesidad de proteger la información y las operaciones permanece.

De hecho, a medida que las organizaciones incorporan más inteligencia artificial, también necesitan asegurarse de que sus sistemas, usuarios, aplicaciones y datos estén protegidos frente a nuevas formas de ataque.

La tendencia apunta hacia una ciberseguridad más automatizada, más orientada al análisis continuo y con mayor capacidad de respuesta. El profesional de seguridad no necesariamente desaparecerá; su función tendrá que evolucionar junto con las herramientas que utiliza.

Para las empresas, especialmente las pymes, esto significa que invertir en ciberseguridad no se trata únicamente de aumentar el número de personas o adquirir más herramientas. Se trata de construir una estrategia capaz de combinar tecnología, automatización, inteligencia y experiencia humana.

Porque si la IA permite que las amenazas evolucionen a la velocidad de las máquinas, la defensa también tendrá que aprender a hacerlo.

Filtrado de contenido

¿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.