Análisis Cloud : detección de atacantes que utilizan credenciales válidas

cloud más graves de los últimos dos años no comenzaron con malware. Comenzaron con un inicio de sesión. Los atacantes accedieron con credenciales válidas o tokens OAuth autorizados, realizaron llamadas correctamente formadas a interfaces de programación de aplicaciones (API) legítimas y no dejaron ningún rastro anómalo que pudiera detectarse mediante una firma. Esa realidad es a lo que responde el análisis cloud . Esta guía define el término con precisión, explica cómo funciona el proceso de análisis, repasa dos casos emblemáticos de brechas de seguridad para mostrar por qué las firmas dejan de detectar amenazas y describe la práctica en Amazon Web Services (AWS), Azure y Google Cloud incluyendo los aspectos económicos de la telemetría y la alineación de marcos de trabajo que la mayoría de las explicaciones omiten.

¿Qué es el análisis cloud ?

El análisis Cloud consiste en aplicar técnicas de detección a la telemetría cloud —registros de auditoría del plano de control, eventos relacionados con identidades y tokens, patrones de llamadas a la API y datos sobre cargas de trabajo y flujos— con el fin de detectar el comportamiento de los atacantes. Se diferencia de la inteligencia cloud , de cualquier producto concreto de gestión de información y eventos de seguridad (SIEM) y de las comprobaciones de la postura cloud en reposo que realiza la gestión de la postura cloud (CSPM).

Cada término relacionado responde a una pregunta diferente. La práctica más amplia que AWS define como «análisis de seguridad» —la recopilación y el análisis de datos de seguridad para detectar amenazas— se convierte en «análisis cloud cuando la propia telemetría es cloud y los comportamientos objeto de análisis pertenecen a identidades y API, en lugar de a terminales. Esta disciplina funciona como la capa de detección cloud , junto con los controles de prevención y de postura de seguridad. No se trata, en absoluto, de análisis empresarial, aunque ambos compartan flujos de datos.

Los datos de 2026 explican por qué esta disciplina se ha consolidado como una disciplina independiente. En los proyectos de respuesta a incidentes y detección gestionada de amenazas llevados a cabo por Mandiant durante el segundo semestre de 2025 —una visión independiente de la plataforma sobre las principales intrusiones cloud en el software como servicio (SaaS)—, el robo de identidad estuvo detrás del 83 % de los casos, los atacantes se centraron en los datos en el 73 % de ellos y la explotación de vulnerabilidades solo representó el 2 % (Threat Horizons, primer semestre de 2026). Hay que tener en cuenta el alcance de estas cifras: se refieren a las intrusiones investigadas, no a todas las alertas de todos los clientes.

El panorama general de las filtraciones se presenta diferente, y las etiquetas de la población son importantes. El Informe de Investigaciones sobre Filtraciones de Datos (DBIR) de Verizon de 2026 reveló que en el 31 % de las filtraciones se explotaron vulnerabilidades —superando el robo de credenciales por primera vez en 19 años—, mientras que la participación de terceros ascendió al 48 %, lo que supone un aumento del 60 % respecto al año anterior (Verizon DBIR 2026). M-Trends 2026, otro conjunto de datos que abarca todos los entornos, situó la mediana global del tiempo de permanencia en 2025 en 14 días, frente a los 11 anteriores, y reveló que los exploits fueron el principal vector por sexto año consecutivo, con un 32 % (M-Trends 2026). Leídos en conjunto, estos datos apuntan a una conclusión precisa: en todas las violaciones de seguridad, los exploits ocupan el primer lugar, pero en las principales intrusiones cloud en SaaS, el abuso de identidad es el factor dominante. El abuso de identidad es precisamente lo que las firmas de superficie no pueden detectar.

Análisis Cloud frente a cloud , SIEM y CSPM

Esta es la aclaración que la mayoría de las explicaciones pasan por alto, y que cambia lo que compras y desarrollas. Cloud responde a preguntas de negocio —uso, ingresos, comportamiento de los productos— a través de flujos de inteligencia empresarial. Un SIEM es un producto y una arquitectura, un entorno en el que se puede ejecutar contenido de detección. El CSPM evalúa la configuración en reposo —depósitos públicos, roles con permisos excesivos— antes de que aparezca ningún atacante. El análisis Cloud detecta el comportamiento activo de los atacantes en cloud a medida que se produce. La tabla siguiente distingue entre los cuatro conceptos.

Cuatro conceptos que a menudo se confunden: el análisis cloud detecta comportamientos, cloud sirve de base para las decisiones empresariales, un sistema SIEM agrega registros y el CSPM comprueba el estado de seguridad de los datos en reposo.

Cómo funciona el análisis cloud

El análisis Cloud transforma los grandes volúmenes de datos cloud en detecciones priorizadas y basadas en el comportamiento. El proceso es coherente entre los distintos proveedores, incluso cuando los nombres de los registros difieren, y se resume en cinco etapas:

1. Recopila datos de cloud de distintos proveedores, cuentas y cargas de trabajo.
2. Normalizar y enriquecer los eventos con información sobre identidades, activos y amenazas.
3. Comportamiento normal de referencia para cada identidad, tanto humana como no humana.
4. Correlacionar eventos y aplicar análisis de comportamiento en todas las fuentes.
5. Avisar de las desviaciones significativas y priorizarlas en función del riesgo.

‍

‍

La materia prima es la telemetría cloud. Los registros de auditoría del plano de control —AWS CloudTrail, Google Cloud Logs y los registros de inicio de sesión y de auditoría de Entra ID— registran cada acción de gestión y cada llamada a la API en un entorno. Los eventos de identidad y tokens recogen las autenticaciones, las concesiones de permisos y los consentimientos. Los patrones de llamadas a la API muestran lo que hace realmente cada identidad, mientras que los datos de cargas de trabajo y de flujos de red muestran cómo se mueven los datos. La arquitectura de referencia de Google describe la secuencia operativa para hacerlo correctamente —activar los registros adecuados, enviarlos a un destino de análisis y, a continuación, analizarlos allí— en su guía sobre análisis de registros de seguridad.

Es importante hacer hincapié en la normalización, ya que cloud no se ponen de acuerdo en cuanto a los esquemas. Un mismo evento conceptual —una identidad que asume privilegios elevados— se presenta de forma completamente diferente en CloudTrail, en los registros de auditoría de Entra ID y en los registros Cloud de Google Cloud . El enriquecimiento, por su parte, añade la información que falta en los eventos sin procesar, como la criticidad de los activos, la titularidad de la identidad y el contexto de inteligencia sobre amenazas.

Lo que hace que esta disciplina sea cloud es la naturaleza de los recursos. Cloud es efímera, está basada en API y se centra en la identidad: las cargas de trabajo duran unos minutos, cada acción es una llamada a la API y la identidad constituye el perímetro efectivo. Por lo tanto, la señal de detección es una desviación en el comportamiento respecto a una línea de referencia aprendida, no una carga útil malformada. Por eso el análisis del comportamiento de usuarios y entidades (UEBA) ocupa un lugar central en esta práctica, y por eso la detección de anomalías en la red extiende esa misma lógica de establecimiento de líneas de referencia al tráfico que se mueve entre las cargas de trabajo.

Las dos últimas etapas son aquellas en las que el análisis demuestra su utilidad desde el punto de vista operativo. La correlación une eventos aislados —un nuevo inicio de sesión, un cambio de permisos, un pico en las lecturas de datos— en una única narrativa de ataque, y la priorización clasifica esa narrativa frente a todo lo demás que compite por la atención. Si se hace bien, esto es el antídoto contra la fatiga de alertas. También es lo que influye en las dos métricas con las que se evalúa a la mayoría de los centros de operaciones de seguridad (SOC): el tiempo medio de detección (MTTD) y el tiempo medio de respuesta (MTTR), ya que los analistas parten de una lista breve y ordenada en lugar de un flujo de eventos sin filtrar.

Por qué falla la detección basada en firmas en la cloud

Cuando un atacante se autentica con credenciales válidas sustraídas o con un token autorizado, el análisis de comportamiento suele ser la única vía de detección que queda. Las firmas coinciden con elementos conocidos como maliciosos malware , cargas útiles de exploits, dominios maliciosos—. Un inicio de sesión correcto a través de una API autorizada no genera ninguno de ellos. No hay autenticación fallida, ni se descarga ningún archivo binario, ni hay tráfico de exploits que inspeccionar. Este es el punto ciego común en las herramientas basadas únicamente en firmas y en las implementaciones de SIEM basadas únicamente en reglas.

‍

La campaña de 2024 dirigida contra los entornos de los clientes de Snowflake, identificada como UNC5537, es el caso de referencia (análisis de UNC5537 de Google Threat Intelligence). Los atacantes utilizaron credenciales robadas por malware de robo de información —el 79,7 % de ellas habían sido expuestas anteriormente y algunas llevaban cuatro años sin cambiarse— contra cuentas que carecían de autenticación multifactorial (MFA) y de listas de permitidos de red. Se notificó a unas 165 organizaciones. No se explotó ninguna vulnerabilidad y ningún malware la plataforma. Todas las acciones de los atacantes consistieron en consultas autenticadas y bien formadas.

Esto dejaba a los defensores con tres tipos de señales, todas ellas de comportamiento: movimientos imposibles entre sesiones de inicio de sesión, aplicaciones cliente y huellas digitales desconocidas, y volúmenes de consultas muy por encima de los valores de referencia de una cuenta. El análisis de comportamiento basado en esos valores de referencia, combinado con el análisis de identidad que evalúa cómo se autentica normalmente cada cuenta, es la respuesta de la ingeniería de detección, junto con las medidas preventivas básicas de las que carecían las víctimas.

El incidente de Salesloft Drift de 2025, registrado con el número UNC6395, amplió la lección de las contraseñas a los tokens (análisis de UNC6395 de Google Threat Intelligence). Los atacantes se hicieron con tokens OAuth de la integración de Drift y los utilizaron para ejecutar consultas SOQL (Salesforce Object Query Language) bien formadas en numerosas instancias de clientes de Salesforce; el informe principal solo menciona «numerosas». Ninguna solicitud individual presentaba errores de formato. Las señales reveladoras fueron de carácter agregado y conductual: el volumen de llamadas a la API, la estructura de las consultas y las desviaciones del agente de usuario respecto a la línea de base establecida para la integración. Por eso los programas de detección y respuesta ante amenazas de identidad (ITDR) tratan las integraciones no humanas como identidades de primer orden.

Esta tendencia ha continuado en 2026 siguiendo dos vías distintas. Los informes de julio de 2026 pusieron de manifiesto una ola de abusos de OAuth que se prolongó durante todo un año y que estaba relacionada con el ecosistema de extorsión de ShinyHunters (The Hacker News). Por otra parte, unaphishing independientephishing guió a las víctimas para que registraran claves de acceso controladas por los atacantes en Entra ID, convirtiendo así un control phishing en un punto de apoyo duradero (Help Net Security). Operaciones diferentes, mismo problema de detección: artefactos de identidad válidos (tokens, cookies de sesión, claves de acceso) que accionan API legítimas.

Las vulnerabilidades siguen produciéndose en la cloud con una matización importante. Según la propia telemetría Cloud la plataforma Cloud Google Cloud —una muestra distinta de los datos de los proyectos de Mandiant—, la ejecución remota de código (RCE) aumentó como vector de entrada, pasando del 2,9 % en el primer semestre de 2025 al 13,6 % en el segundo semestre (Threat Horizons, primer semestre de 2026).

Cuando se produce la explotación, la creación de herramientas de ataque va por delante de la difusión de las firmas. React2Shell (CVE-2025-55182) es una vulnerabilidad de ejecución remota de código (RCE) previa a la autenticación en React Server Components, calificada con un 10,0 —la puntuación máxima— en el Sistema Común de Puntuación de Vulnerabilidades (CVSS) (aviso de seguridad de React). Se estaba explotando activamente en las aproximadamente 48 horas siguientes a su divulgación: la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) la añadió al catálogo de vulnerabilidades explotadas conocidas el 5 de diciembre de 2025, dos días después del aviso, citando pruebas de explotación activa (alerta de la CISA). El análisis de comportamiento también cubre parte de esa brecha: una carga de trabajo que de repente genera un criptominero rompe su línea de base antes de que se distribuya una firma.

Casos de uso y técnicas de análisis Cloud

El mismo núcleo analítico da soporte a una serie de casos de uso, cada uno de los cuales plantea una pregunta sobre el comportamiento que ninguna firma puede responder. Los analistas del SOC utilizan estas detecciones para la clasificación de incidencias, los cazadores de amenazas para la comprobación de hipótesis y los equipos de cumplimiento normativo como prueba de la cobertura de la supervisión. El resultado es una detección más temprana, menos falsos positivos e investigaciones más breves. Todos ellos se basan en la fase de establecimiento de valores de referencia del proceso.

• Establecimiento de valores de referencia de comportamiento para las identidades humanas. Los modelos de tipo UEBA aprenden la ubicación geográfica habitual, el horario y los clientes desde los que suele iniciar sesión cada usuario, y a continuación señalan los desplazamientos imposibles, los accesos fuera del horario habitual y las aplicaciones que se detectan por primera vez.
• Detección de anomalías en la actividad de la API. La evaluación del volumen de llamadas, la composición de las llamadas, la ubicación geográfica y la huella digital del cliente en comparación con los valores de referencia de cada identidad permite detectar a tiempo el robo de tokens y el uso indebido de la automatización.
• Detección de amenazas internas y de fuga de datos. Los picos en el volumen de consultas y los accesos inusuales a los datos ponen de manifiesto las amenazas internas y los robos de datos planificados, mientras que el análisis del tráfico de red confirma cómo se transfirieron realmente los datos.
• Enriquecimiento de la información sobre amenazas. La correlación entre cloud y la información sobre amenazas seleccionada permite identificar un inicio de sesión inusual como una coincidencia con una infraestructura conocida y le asigna la prioridad correspondiente.

Dos de ellos merecen especial atención, ya que constituyen la base de las investigaciones. La detección de la exfiltración en la cloud , en gran medida, un problema de consultas y salida de datos: en la campaña de Snowflake, las señales duraderas fueron los volúmenes y patrones de consultas que se desviaban considerablemente de los valores de referencia de la cuenta. Y el enriquecimiento convierte una anomalía en una decisión: el mismo inicio de sesión obtiene una puntuación diferente cuando su infraestructura de origen ya está vinculada a campañas de «credential stuffing».

Análisis de identidades de máquinas y no humanas

Las cuentas de servicio, las claves API y los tokens OAuth superan ahora con creces el número de personas en la mayoría de cloud . Un análisis elaborado por Tenable en 2026 y publicado por la Cloud Alliance (CSA) sitúa la proporción entre identidades de máquinas e identidades humanas en aproximadamente 100 a 1. El Informe sobre riesgos de seguridad Cloud la IA de Tenable de 2026 reveló, por otra parte, que el 65 % de las organizaciones albergan cloud «fantasma» olvidadas cloud : identidades que nadie gestiona, renueva ni supervisa.

Esos «fantasmas» no son hipotéticos. Las credenciales antiguas, sin renovar, que se escondían tras la campaña UNC5537 encajaban exactamente en esa categoría. Las identidades no humanas tampoco se comportan en absoluto como las personas —sin horario laboral, sin desplazamientos y con patrones de llamadas muy regulares—, por lo que necesitan sus propios parámetros de referencia, independientes de la UEBA humana. Una cuenta de servicio que, de repente, se autentica de forma interactiva, amplía su ámbito de actuación o consulta un nuevo conjunto de datos es una de las detecciones de mayor importancia que genera el análisis cloud .

Análisis Cloud frente a SIEM y categorías afines

Un SIEM es el entorno en el que se pueden ejecutar los análisis; el análisis cloud es la capacidad de detección de comportamientos que se ejecuta en él. Son complementarios, no competidores. La confusión en este ámbito sale cara: los equipos acaban comprando un segundo producto que no necesitaban o dan por sentado que su sistema de agregación de registros ya detecta cloud . La tabla siguiente establece los límites, incluyendo las categorías de plataformas adyacentes con las que se encuentran los compradores.

El análisis Cloud es una funcionalidad, mientras que SIEM, CDR y CNAPP son los productos y plataformas en los que se ejecuta o que lo incorporan.

Las plataformas SIEM siguen siendo la columna vertebral de la agregación, la correlación y el cumplimiento normativo para muchos equipos, y ahí radica precisamente la clave: la cuestión del producto es independiente de la cuestión de las capacidades. Las plataformas Cloud y respuestaCloud (CDR) responden directamente a la cuestión de la capacidad, al combinar análisis de comportamiento cloud con acciones de respuesta para aquellos equipos que desean que se gestione por ellos el contenido de detección. La relación práctica suele pasar por el coste: los equipos utilizan cloud para decidir qué datos de telemetría deben incorporarse al SIEM y cuáles deben dirigirse a un almacenamiento más económico, una disyuntiva que se cuantifica en la siguiente sección.

Las siglas que aparecen a continuación describen el alcance, no la competencia. Una plataforma de protección de aplicaciones cloud(CNAPP) integra la protección de la postura y de las cargas de trabajo a lo largo de todo el ciclo de vida de la aplicación. El CSPM evalúa la configuración en reposo, una plataforma de protección cloud (CWPP) protege la capa de computación y la gestión de derechos cloud (CIEM) regula quién puede hacer qué. Ninguna de ellas sustituye a la detección basada en el comportamiento: reducen y delimitan la superficie de ataque que luego supervisa el análisis. Las pruebas de intrusión basadas en la identidad de 2026 —con un 83 % de los principales casos cloud el SaaS sustentados en la identidad en los proyectos de Mandiant (Threat Horizons H1 2026)— explican por qué todas y cada una de estas categorías siguen convergiendo en el comportamiento de la identidad.

El mercado ya se ha pronunciado sobre la cuestión de «capacidad frente a producto». Los productos independientes de análisis cloud se han dejado de comercializar en repetidas ocasiones o se han integrado en plataformas más amplias de detección y evaluación del estado de seguridad. Considera este término como una capacidad que necesitas —ya sea en un SIEM, en un «data lake» de seguridad o en una plataforma CDR— en lugar de como un elemento más del diagrama de arquitectura.

Los aspectos económicos de cloud

La eficacia del análisis Cloud depende en gran medida de la telemetría que uno pueda permitirse conservar. El coste de la ingesta es la principal objeción de los profesionales ante cualquier arquitectura que requiera gran cantidad de telemetría, y es la verdadera razón por la que existen los lagos de datos de seguridad: para separar el almacenamiento económico de la detección selectiva.

El volumen crece más rápido que los presupuestos, y no todos los registros justifican su coste. Los registros de auditoría de acceso a datos son el ejemplo clásico: las directrices de implementación de Google prestan especial atención a la gestión del volumen de registros de auditoría de acceso a datos antes de enviar nada (directrices de análisis de registros de seguridad). La clave está en la selección de la telemetría. Los registros del plano de control y de identidad ofrecen el mayor valor de detección por gigabyte, mientras que los registros detallados del plano de datos solo merecen ser incorporados cuando los activos lo justifican. Esa labor de selección es lo que permite que la supervisióncloud siga siendo sostenible a medida que crecen los entornos.

La clasificación por niveles de retención resuelve el dilema entre la ingesta y la detección. Mantén la telemetría de detección en tiempo real en el nivel «activo», la telemetría de investigación en el nivel «térmico» y la telemetría de búsqueda proactiva en el nivel «frío» —sigue siendo consultable, pero con un precio similar al del almacenamiento de archivo—.

La retención por niveles permite consultar los datos de telemetría de alto valor para la detección de incidencias sin tener que pagar los precios del almacenamiento de acceso frecuente por todo.

La retención no es una simple casilla que hay que marcar para cumplir con la normativa: determina qué datos pueden examinarse en una investigación. Durante la campaña UNC5537, la retención predeterminada de Snowflake proporcionó a los investigadores un periodo de 365 días de actividad de la cuenta en el que realizar la búsqueda (la investigación UNC5537). Las organizaciones con periodos más cortos simplemente disponen de menos historial que reconstruir.

Los parámetros de referencia ponen de manifiesto lo que está en juego. El estudio «El coste de una filtración de datos» del Ponemon Institute situó la media mundial para 2025 en 4,44 millones de dólares, con 241 días para identificar y contener una filtración —cifras para todos los entornos—, y la edición de 2026 está a punto de publicarse (Help Net Security). Los plazos Cloud reflejan la misma urgencia. En el análisis de Push Security sobre cloud del DBIR de 2026 cloud , solo el 23 % de las organizaciones de terceros había subsanado por completo las deficiencias cloud , y la organización media necesitaba ocho meses para resolver el 50 % de los problemas detectados relacionados con contraseñas y configuraciones erróneas de permisos (Push Security).

Implementación de análisis cloud en AWS, Azure y GCP

Los nombres de los parámetros de telemetría varían según el proveedor, pero las cuestiones relacionadas con el comportamiento no cambian. La arquitectura de referencia de Google define las categorías de preguntas que todo entorno debería abordar: anomalías en el inicio de sesión y el acceso, cambios en los permisos, actividad de aprovisionamiento, acceso a los datos y patrones de red (orientaciones sobre el análisis de registros de seguridad). La tabla siguiente relaciona esas preguntas con las fuentes clave de cada proveedor.

Las mismas familias de preguntas sobre el comportamiento se aplican a todos los proveedores una vez que la telemetría del plano de control y de identidad está en funcionamiento.

La mayoría de las empresas responden a esas preguntas en varios lugares a la vez. Un programa cloud unifica los esquemas de registros de los proveedores en una única capa analítica, de modo que se aplica una única lógica de referencia en todas partes. Sin embargo, el análisis en profundidad específico de cada proveedor sigue siendo útil: la detección de amenazas de AWS, por ejemplo, superpone los eventos de datos de CloudTrail y los registros de flujo sobre el plano de gestión para detectar lo que los registros a nivel de cuenta pasan por alto.

Los contenedores amplían la superficiecloud . Los registros de auditoría y los eventos de tiempo de ejecución de Kubernetes tienen el mismo aspecto independientemente del lugar donde se ejecute el clúster, lo que convierte a la telemetría de seguridad de Kubernetes en un elemento unificador natural y permite extender los mismos criterios de referencia a las arquitecturas cloud híbrida, en las que las cargas de trabajo abarcan centros de datos y nubes.

Supervisa el propio proveedor de identidad (IdP), no solo las cargas de trabajo que hay detrás de él. CVE-2026-40379, una vulnerabilidad de suplantación de identidad detectada en 2026 en Entra ID, recibió una puntuación de 9,3 por parte de su Autoridad de Numeración CVE (CNA) y de 7,5 por parte del Instituto Nacional de Estándares y Tecnología (NIST) (registro NVD). Cuando el IdP es el objetivo, su propia telemetría de inicio de sesión y auditoría se convierte en la superficie de detección.

Correspondencias con MITRE ATT&CK y los marcos de cumplimiento normativo

MITRE ATT&CK , publicada el 28 de abril de 2026, reestructuró la forma en que se modela la evasión. La antigua táctica «Defense Evasion» se retiró y se dividió en «Stealth» (0005) y Deterioro de la defensa (0112) — este último se refiere a los adversarios que burlan los mecanismos de seguridad, las canalizaciones y las herramientas, de modo que los defensores no puedan ver ni confiar en lo que está sucediendo. El cloud de ATT&CK en cloud abarca 12 tácticas en cuatro plataformas —suite ofimática, proveedor de identidad, SaaS e IaaS (infraestructura como servicio)— y ofrece a los ingenieros de detección un vocabulario común para referirse a los comportamientos que se describen en esta guía.

Un punto de partida desde cloud de ATT&CK v19 hasta las detecciones basadas en el comportamiento que puede ofrecer el análisis cloud .

El mapeo de cumplimiento surge de forma natural. Dentro del Marco de Ciberseguridad (CSF) 2.0 del NIST, publicado en 2024, esta práctica se enmarca en la función «Detectar» —una de las seis del marco— bajo las categorías DE.CM y DE.AE (NIST). La Matriz Cloud (CSA Cloud Matrix) v4, con 197 controles repartidos en 17 dominios, recoge los requisitos equivalentes en su dominio de Registro y Supervisión (LOG) (CSA CCM).

La NIS2 (Directiva (UE) 2022/2555) exige, en virtud de su artículo 23, una alerta temprana en un plazo de 24 horas desde que se tenga conocimiento de un incidente significativo, una notificación del incidente en un plazo de 72 horas y un informe final en el plazo de un mes. La DORA (Reglamento (UE) 2022/2554) es de aplicación a las entidades financieras de la UE desde el 17 de enero de 2025; unos plazos de notificación tan ajustados otorgan una importancia especial a la rapidez de detección.

Enfoques modernos del análisis de cloud

El sector está convergiendo en tres tendencias. La detección se está centrando en la identidad, ya que es ahí donde apuntan las pruebas verificadas: la identidad estuvo detrás del 83 % de las principales intrusiones cloud en SaaS según los datos de los proyectos de Mandiant del segundo semestre de 2025 (Threat Horizons, primer semestre de 2026). Las herramientas de análisis independientes siguen consolidándose en plataformas, desde paquetes de contenido alojados en SIEM hasta plataformas cloud y respuestacloud . Además, la clasificación y la búsqueda asistidas por IA se están convirtiendo en la norma, ya que los equipos reducidos no pueden reconstruir manualmente el comportamiento entre diferentes superficies a cloud .

Para los compradores, hay tres criterios que distinguen las plataformas duraderas de los paneles de control. Busca una visibilidad unificada en entornos cloud, identidad y SaaS. Insiste en que las detecciones basadas en el comportamiento sigan funcionando incluso después del robo de credenciales: esa es la prueba de detección y respuesta ante amenazas de identidad. Y da prioridad a la calidad de las señales frente al volumen de alertas, midiendo lo que un equipo reducido puede investigar realmente.

Cómo Vectra AI el análisis de cloud

Vectra AI el análisis cloud desde una perspectiva que parte de la base de que el sistema ya ha sido comprometido. Cada vez es más frecuente que los atacantes utilicen identidades válidas, por lo que la metodología da prioridad a la claridad de las señales de ataque en la red, las identidades, cloud y el SaaS, poniendo de relieve el comportamiento que revela la presencia de un atacante activo, en lugar de las firmas que el uso indebido de credenciales válidas nunca activa. En la práctica, esto significa establecer una línea de base para cada identidad, tanto humana como de máquina, unir las desviaciones en todas las superficies en una única narrativa de ataque y dar mayor relevancia a las pocas señales que indican una progresión real frente al volumen bruto de alertas.

Conclusión

El análisis Cloud se ha ganado su propio nombre porque la cloud lo que los sistemas de detección deben identificar. Los atacantes que acceden con credenciales y tokens válidos eluden por completo las firmas: las brechas más destacadas de 2024 y 2025 no generaron malware, ni vulnerabilidades explotadas, ni intentos fallidos de inicio de sesión, sino únicamente un comportamiento que se desviaba de la línea de base. La respuesta es una disciplina, no un producto aislado. Recopila la telemetría relevante del plano de control, la identidad, las API y las cargas de trabajo. Establece una línea de base para cada identidad, tanto humana como de máquina. Clasifica la retención por niveles para que la búsqueda de amenazas siga siendo asequible. Asigna las detecciones a la cloud de ATT&CK v19 y a los marcos de trabajo que reconocen los auditores. Los equipos que traten el análisis cloud como una capacidad —independientemente de dónde se ejecute— seguirán detectando a los atacantes que sus firmas nunca detectan.

‍