Una encuesta de SANS revela que las brechas en logs de cloud e identidad impiden detectar atacantes que se mimetizan con actividad legítima.
La mitad de los profesionales de seguridad identifica la calidad o cantidad de datos como la barrera más importante para realizar threat hunting efectivo, según reveló la encuesta SANS 2026 Threat Hunting Survey publicada esta semana. El hallazgo expone una paradoja operativa: mientras las organizaciones acumulan volúmenes crecientes de telemetría, los equipos especializados en caza de amenazas reportan que la falta de visibilidad estructural — no la falta de herramientas — define el techo de su capacidad de detección. El problema se concentra en dos áreas específicas: logs de infraestructura cloud y telemetría de eventos de identidad, precisamente los vectores que los atacantes más sofisticados explotan para operar sin levantar alertas.
Cuando los playbooks funcionan pero los logs no alcanzan
Los equipos que ya cuentan con playbooks de hunting operativos — es decir, procedimientos documentados y probados para buscar indicadores de compromiso — describen los logs disponibles como su límite máximo de capacidad, según la encuesta. Esta declaración marca un cambio de diagnóstico: el problema dejó de ser la falta de metodología o entrenamiento y pasó a ser la ausencia de datos primarios necesarios para ejecutar esa metodología. Un equipo puede tener un playbook detallado para detectar movimiento lateral en Active Directory, pero si la telemetría de autenticación no captura intentos fallidos de Kerberos o no registra cambios en permisos de cuentas de servicio, el playbook se vuelve inoperable.
La brecha se vuelve crítica en entornos cloud, donde la configuración de logging no viene habilitada por defecto en muchos servicios de plataforma. Un bucket de S3 puede estar expuesto públicamente durante semanas sin que quede registro de quién accedió, cuándo y desde dónde, si el propietario no activó explícitamente CloudTrail con las opciones correctas. Lo mismo ocurre con eventos de identidad: muchas organizaciones capturan logins exitosos pero no intentos fallidos, o registran cambios en roles de IAM pero no consultas a políticas de permisos — exactamente el tipo de actividad que un atacante realiza en fase de reconocimiento interno.
El perfil de atacante que las brechas de logs favorecen
Las brechas en logs afectan más contra atacantes que se mezclan con actividad legítima, según los encuestados. Este perfil describe a adversarios que no dependen de malware ruidoso ni exploits de día cero, sino que abusan de credenciales válidas, herramientas nativas del sistema operativo y permisos excesivos ya presentes en el entorno. Son los casos donde un atacante usa PowerShell para enumerar recursos de red, o donde escala privilegios modificando una política de grupo existente en lugar de instalar un rootkit. Estas acciones generan eventos que, vistos de forma aislada, parecen operaciones administrativas rutinarias.
Detectar este tipo de comportamiento requiere correlacionar múltiples fuentes de telemetría a lo largo del tiempo: un login desde una IP nueva, seguido de una consulta inusual a un servidor de base de datos, seguido de una exportación de datos fuera de horario. Si cualquiera de esas tres fuentes de logs tiene brechas — si el firewall no registra conexiones internas, si el servidor de base de datos no audita queries, si el proxy no captura tráfico saliente cifrado — la cadena de detección se rompe. El atacante no necesita evadir controles técnicos sofisticados: simplemente opera en los espacios ciegos que la configuración de logging dejó abiertos.
Por qué cloud e identidad concentran el problema en América Latina
La encuesta identifica las brechas en cloud logging y telemetría de identidad como los problemas más frecuentemente mencionados por los equipos de hunting. Esta combinación tiene implicancias específicas para organizaciones en América Latina, donde la adopción acelerada de servicios cloud en los últimos tres años — impulsada por migraciones forzadas durante la pandemia — no siempre vino acompañada de revisiones de arquitectura de logging. Muchas empresas en Brasil, México y Argentina migraron cargas de trabajo a AWS, Azure o Google Cloud manteniendo las mismas políticas de retención de logs que tenían on-premise, sin considerar que los proveedores cloud no habilitan logging comprehensivo por defecto y que cada servicio requiere configuración individual.
El problema se agrava en sectores regulados como banca y salud, donde las normativas locales exigen trazabilidad de accesos a datos sensibles pero no especifican qué eventos técnicos concretos deben capturarse. Una entidad financiera puede cumplir formalmente con la regulación capturando logins a su aplicación web, pero si no registra llamadas a APIs de backend o cambios en roles de base de datos, un atacante que comprometa una cuenta de servicio puede exfiltrar información sin dejar rastro auditable. La brecha no es técnica — los proveedores cloud ofrecen las capacidades de logging necesarias — sino de configuración y conocimiento: muchos equipos de infraestructura no saben qué eventos habilitar porque no participan en el diseño de casos de uso de detección.
El costo operativo de la telemetría incompleta
Cuando los equipos de threat hunting operan con telemetría incompleta, el impacto no se limita a detecciones fallidas: también aumenta el costo de investigación de cada alerta. Sin logs completos, cada incidente sospechoso requiere análisis forense manual en múltiples sistemas para reconstruir qué pasó, en lugar de poder correlacionar eventos automáticamente desde un SIEM. Un analista puede pasar horas intentando confirmar si un login anómalo fue seguido de acceso a datos sensibles, solo para descubrir que el servidor de aplicaciones no tiene habilitado logging de queries a nivel de usuario.
Esta ineficiencia operativa tiene un costo de oportunidad: el tiempo que el equipo invierte reconstruyendo contexto faltante es tiempo que no dedica a buscar proactivamente otros indicadores de compromiso. En organizaciones con equipos de seguridad pequeños — la norma en empresas medianas de la región — esta limitación puede significar la diferencia entre detectar un atacante en fase de reconocimiento o descubrirlo semanas después, cuando ya exfiltró información. La encuesta no cuantifica este costo, pero la descripción de los logs como «techo de capacidad» sugiere que muchos equipos ya llegaron al límite de lo que pueden hacer con los datos disponibles, independientemente de cuántas horas adicionales inviertan.
Nuestro análisis
El hallazgo de SANS confirma un patrón que venimos observando en incidentes reportados durante 2025 y 2026: la brecha entre capacidad de detección teórica y capacidad de detección real está determinada cada vez más por decisiones de arquitectura de datos tomadas años antes del incidente, no por la sofisticación de las herramientas de análisis disponibles en el momento del ataque. Organizaciones con presupuestos significativos en seguridad y equipos entrenados siguen siendo comprometidas porque nadie revisó qué eventos captura cada servicio cloud cuando se migró la carga de trabajo, o porque la telemetría de identidad se configuró pensando en auditoría de cumplimiento y no en detección de amenazas. Esta desconexión entre quienes diseñan la infraestructura y quienes la defienden no es nueva, pero se volvió más costosa a medida que los atacantes profesionalizaron técnicas de living-off-the-land que dependen precisamente de operar en espacios ciegos de logging.
Lo que la encuesta no responde — y lo que determina si este problema es solucionable a corto plazo — es cuántas de estas brechas de telemetría son técnicas (el proveedor no ofrece la capacidad de logging necesaria) versus cuántas son de configuración o presupuesto (la capacidad existe pero no está habilitada por costo de almacenamiento o falta de conocimiento). Si la mayoría son del segundo tipo, el problema tiene solución mediante revisión de arquitectura y ajuste de políticas. Si son del primer tipo, los equipos de hunting seguirán operando con un techo estructural hasta que los proveedores cloud expandan sus capacidades nativas de telemetría. ¿Cuántos incidentes más van a atribuirse a «atacantes sofisticados» cuando en realidad fueron atacantes comunes operando en brechas de visibilidad que la organización dejó abiertas por diseño?