Investigación en ciberseguridad en 2026: un marco reproducible para la detección, validación y priorización de amenazas en entornos híbridos con telemetría de nube, endpoint y LLM

1. Introducción

La investigación en ciberseguridad ha dejado de ser un ejercicio puramente académico para convertirse en una disciplina operacional que debe producir evidencia, reducir riesgo y guiar decisiones técnicas bajo presión. En 2026, la superficie de ataque ya no se limita a servidores expuestos o estaciones finales; incluye identidades federadas, servicios SaaS, canalizaciones CI/CD, contenedores efímeros, servicios administrados de nube, extensiones de navegador, copilotos de IA, agentes LLM con herramientas y sistemas de terceros que procesan datos sensibles. Esta expansión obliga a replantear qué significa “investigar” en ciberseguridad: no basta con describir un vector de ataque, sino que es necesario demostrarlo, medirlo, contextualizarlo y traducirlo en controles accionables.

La investigación moderna debe responder a preguntas concretas. ¿Qué comportamientos observables distinguen una ejecución legítima de una secuencia de intrusión? ¿Qué combinación de telemetría permite detectar un abuso de identidad sin producir una tasa inaceptable de falsos positivos? ¿Cómo se evalúa el riesgo de un LLM conectado a herramientas internas cuando el adversario puede manipular instrucciones, contexto o entradas externas? Estas preguntas son especialmente relevantes en un entorno donde los atacantes adoptan automatización asistida por modelos, infraestructura efímera, técnicas de living-off-the-land y operaciones distribuidas que hacen obsoletas las taxonomías simplistas basadas únicamente en malware.

Desde una perspectiva científica, la investigación en ciberseguridad debe mantener tres propiedades. La primera es falsabilidad: una hipótesis de detección o explotación debe poder refutarse con observaciones reproducibles. La segunda es trazabilidad: cada conclusión debe vincularse a artefactos, datos y versiones de herramientas claramente identificables. La tercera es utilidad operacional: el resultado debe mejorar una capacidad defensiva o de respuesta, ya sea mediante una nueva regla, un nuevo control, una mejora en la priorización o una reducción del tiempo medio de detección $MTTD$ y del tiempo medio de respuesta $MTTR$.

Este artículo propone un marco de investigación aplicado a entornos híbridos de 2026, en los que conviven nube pública, endpoint, SaaS y cargas de trabajo de IA generativa. El foco está en un problema amplio pero específico: cómo diseñar investigación reproducible que detecte, valide y priorice amenazas reales con suficiente fidelidad para ser usada por equipos de defensa. La propuesta combina observabilidad multi-fuente, modelado adversarial, formalización de hipótesis y un ciclo de evaluación que integra datos de laboratorio, emulación y telemetría de producción. En lugar de asumir que la investigación debe limitarse a vulnerabilidades CVE, se amplía el alcance a cadenas de ataque completas, incluyendo identidad, persistencia, movimiento lateral, exfiltración y manipulación de sistemas asistidos por IA.

Un punto central de esta contribución es que las amenazas de 2026 son cada vez más “híbridas” en el sentido técnico. Un solo incidente puede implicar un correo de phishing generado con apoyo de LLM, el robo de tokens de sesión, el abuso de OAuth, el acceso a un repositorio Git, la inserción de cambios maliciosos en una pipeline, la ejecución de un contenedor en Kubernetes y la exfiltración de datos a través de un servicio legítimo de almacenamiento en la nube. En tales escenarios, una investigación centrada en un único punto de observación falla por diseño. La defensa requiere una metodología de investigación capaz de correlacionar eventos a través de dominios.

En paralelo, la madurez de controles como Zero Trust, CNAPP, EDR/XDR, PAM, SSO reforzado, MFA resistente al phishing y monitoreo con eBPF ha elevado el estándar de la investigación. Ya no es suficiente demostrar que un ataque “funciona”; ahora hay que cuantificar cómo se comporta frente a mecanismos modernos de prevención y detección. Esto implica diseñar experimentos que midan no solo éxito o fracaso, sino latencia, coste computacional, cobertura, degradación y robustez frente a variaciones ambientales. En términos operativos, la investigación se convierte en una herramienta para reducir la incertidumbre en ambientes hostiles donde el adversario también aprende y se adapta.

Finalmente, este trabajo se sitúa en el contexto de 2026, donde la adopción de IA generativa ha creado nuevas clases de amenaza y de investigación. Los LLM introducen riesgos de prompt injection, fuga de contexto, abuso de herramientas, envenenamiento de datos de entrenamiento y manipulación de salidas. A la vez, ofrecen oportunidades para acelerar análisis, triage y correlación. El valor científico está en separar con rigor ambos aspectos: usar las capacidades de automatización sin caer en conclusiones no verificadas. Por eso, este artículo adopta una postura pragmática: la investigación en ciberseguridad debe ser cuantitativa, reproducible, adversarial y orientada a decisiones.

2. Background and Related Work

La literatura de ciberseguridad previa a 2026 ofrece una base sólida para comprender la evolución de los métodos de investigación, aunque también evidencia límites importantes. Tradicionalmente, la investigación se estructuró alrededor de la vulnerabilidad técnica, el exploit y la mitigación. Sin embargo, la industria y la academia convergieron progresivamente hacia marcos más amplios como MITRE ATT&CK, Diamond Model, kill chain y enfoques basados en inteligencia de amenazas. Estos modelos ayudaron a estandarizar el lenguaje, pero no siempre resolvieron el problema de reproducibilidad ni el de observabilidad multi-capa.

MITRE ATT&CK se consolidó como taxonomía práctica para mapear técnicas, tácticas y procedimientos adversarios. Su valor radica en permitir que la investigación describa comportamientos observables en lugar de depender únicamente de artefactos estáticos como hashes. No obstante, ATT&CK no es en sí un método experimental; es un vocabulario. Por ello, la investigación madura debe ir más allá de la enumeración de técnicas y establecer cómo se recolectan evidencias, qué sensores intervienen y qué umbrales de confianza se asignan a cada observación (MITRE, 2024). De forma complementaria, el Diamond Model propuso formalizar relaciones entre adversario, infraestructura, capacidad y víctima, facilitando el análisis de campañas y la atribución operacional limitada (CALTAGIRONE; PENDERGAST; GRAHAM, 2013).

El ámbito de la detección también evolucionó. De los antivirus basados en firmas se pasó a EDR, XDR, SOAR y, más recientemente, a CNAPP para cargas nativas de nube. Esta transición desplazó el foco desde indicadores estáticos hacia comportamiento, contexto e identidad. En términos prácticos, el investigador ya no busca solo malware, sino cadenas de comportamiento que incluyan powershell, curl, rundll32, bash, kubectl, az, aws, gcloud, herramientas de compresión, acceso a tokens y llamadas API. La investigación, por tanto, debe capturar combinaciones y secuencias, no eventos aislados.

En paralelo, la telemetría de bajo nivel ganó protagonismo. Sysmon se convirtió en una fuente esencial para Windows; auditd y osquery permitieron observabilidad en Linux; eBPF emergió como un mecanismo de trazado de alto rendimiento para eventos de kernel, red y proceso. Las soluciones de seguridad basadas en eBPF ofrecieron mejor granularidad y menor sobrecarga en comparación con agentes tradicionales, y facilitaron correlación temporal precisa. Sin embargo, también introdujeron retos de escalabilidad, compatibilidad y gobernanza, especialmente en entornos con cargas efímeras y múltiples clusters Kubernetes.

La investigación sobre abuso de identidad y acceso ha sido igualmente relevante. El robo de tokens OAuth, el secuestro de sesiones, la suplantación mediante consentimiento malicioso y el abuso de cuentas privilegiadas se convirtieron en rutas críticas para intrusión. La identidad pasó a ser el nuevo perímetro, pero con una complejidad superior porque las autorizaciones son delegadas, temporales y distribuidas. Los ataques a servicios SaaS y a aplicaciones de colaboración mostraron que la evidencia de compromiso puede manifestarse en eventos aparentemente legítimos, como creación de reglas de reenvío, acceso inusual a correo, registro de dispositivos y uso anómalo de APIs de administración.

La llegada de la IA generativa añadió una dimensión nueva. Estudios y reportes de 2023 a 2026 documentaron prompt injection, jailbreaks, exfiltración por herramientas conectadas, “data poisoning” en RAG y abuso de agentes autónomos. Los riesgos no son meramente conceptuales: un LLM con acceso a correo, repositorios o sistemas de ticketing puede ser manipulado para revelar información o ejecutar acciones no deseadas. La investigación en este campo combina seguridad clásica, ingeniería de prompts, modelado de contexto y defensa de integraciones. OWASP publicó guías específicas para aplicaciones de LLM, incluyendo riesgos de prompt injection, supply chain, exposición de datos y exceso de autonomía (OWASP, 2024).

En el área metodológica, la literatura de experimentación defensiva también aportó buenas prácticas. Los ejercicios de emulación adversaria, la validación con técnicas ATT&CK y plataformas como Caldera, Prelude Operator o Infection Monkey facilitaron escenarios reproducibles. Paralelamente, proyectos como Sigma y YARA permitieron expresar detecciones portables y verificables. No obstante, persiste una brecha entre la detección expresable y la observabilidad real: una regla Sigma puede ser elegante, pero si los datos necesarios no existen o no se conservan con suficiente fidelidad, la investigación falla.

La seguridad de software y la cadena de suministro también dominaron la agenda. Ataques a paquetes de Python, npm, repositorios Git y pipelines CI/CD demostraron que la investigación debe contemplar dependencias, firmados, SBOM y mecanismos de integridad. Herramientas como Syft, Grype, Trivy y Dependency-Check se establecieron para inventario y escaneo de componentes, pero el desafío continúa siendo cómo correlacionar una vulnerabilidad conocida con su explotabilidad contextual. No toda CVE es crítica en todos los entornos; el valor de una investigación consiste en determinar exposición, rutas de acceso y capacidad de explotación.

Área	Enfoque tradicional	Enfoque maduro 2026	Limitación principal
Detección	Firma o IOC	Comportamiento, contexto e identidad	Falsos positivos/negativos por falta de contexto
Nube	Inventario y hardening	CNAPP, postura, runtime y CI/CD	Fragmentación de telemetría
IA generativa	Uso de herramientas	Defensa de prompts, contexto y herramientas	Ataques de prompt injection y fuga de datos
Endpoints	AV/EDR aislado	XDR con correlación multi-fuente	Cobertura desigual entre plataformas
Cadena de suministro	Escaneo de CVEs	SBOM, integridad, provenance, policy-as-code	Explotabilidad dependiente del entorno

En conjunto, la literatura muestra una transición clara: la investigación en ciberseguridad ya no puede definirse por el artefacto analizado, sino por la cadena de evidencias y el valor defensivo generado. Este artículo se apoya en esa evolución y propone un marco que integra observabilidad, formalización y evaluación empírica.

3. Threat Model and Problem Formalization

El modelo de amenaza considerado en este trabajo asume un adversario con capacidad para combinar técnicas de intrusión clásicas con automatización asistida por IA y abuso de servicios legítimos. El adversario puede operar desde infraestructura efímera, usar credenciales robadas, explotar configuraciones inseguras, insertar artefactos maliciosos en pipelines y manipular sistemas con componentes LLM. Se asume además que el entorno defendido incluye múltiples fuentes de telemetría, pero no cobertura perfecta, y que la investigación debe funcionar bajo incertidumbre parcial.

Formalmente, definimos el entorno como un conjunto de activos $A$, eventos observables $E$, controles $C$ y objetivos adversarios $G$. Cada evento $e \in E$ tiene atributos temporales, espaciales y semánticos. La tarea investigativa consiste en inferir una hipótesis $H$ sobre la presencia, ausencia o probabilidad de una cadena de ataque a partir de una subsecuencia de eventos ${e_1, e_2, \dots, e_n}$. Dado que observabilidad y causalidad no son equivalentes, el problema se formula como inferencia probabilística bajo evidencia incompleta.

La función objetivo prioriza hallazgos que maximicen utilidad defensiva: $$ U(H) = \alpha I(H) + \beta E(H) + \gamma C(H) - \delta R(H) $$ donde $I(H)$ representa impacto potencial, $E(H)$ explotabilidad contextual, $C(H)$ confianza empírica y $R(H)$ costo de remediación o respuesta. Los coeficientes $\alpha, \beta, \gamma, \delta$ se ajustan según el entorno: en un SOC, la prioridad puede favorecer confianza y explotabilidad; en un equipo de arquitectura, costo y compatibilidad pueden tener mayor peso.

El problema se complica porque la observabilidad es parcial. Definimos la probabilidad de observación como $P(o|e)$, donde un evento real puede o no ser capturado por sensores. Por ejemplo, una acción de curl ejecutada dentro de un contenedor puede dejar rastro en audit logs, en telemetría de red, en kernel traces y en logs del orquestador, pero la cobertura real dependerá de privilegios, configuración y retención. Por tanto, una hipótesis de ataque válida debe sostenerse con evidencias redundantes, idealmente de dominios distintos.

También introducimos la noción de cadena de ataque como secuencia de estados $S = {s_0, s_1, \dots, s_k}$, donde cada transición $s_i \rightarrow s_{i+1}$ representa un cambio operacional como acceso inicial, ejecución, persistencia, escalado, movimiento lateral o exfiltración. La investigación intenta mapear observaciones a estados con una función $\phi(E) \rightarrow S$. La exactitud de esa función depende de la cobertura de telemetría, la normalización temporal y la capacidad de correlación semántica.

Variable	Definición	Ejemplo operacional	Riesgo si se ignora
$A$	Activos	Endpoints, buckets, identidades, pipelines	Pérdida de alcance real
$E$	Eventos	Sysmon, auditd, API logs, eBPF	Sesgo de observación
$C$	Controles	MFA, PAM, EDR, CNAPP	Falsa sensación de seguridad
$G$	Objetivos	Exfiltración, persistencia, fraude	Subestimación del adversario
$U(H)$	Utilidad del hallazgo	Severidad priorizada	Remediación ineficiente

La formalización debe incorporar también incertidumbre de atribución. En muchos casos, el objetivo de la investigación no es atribuir a un actor específico, sino determinar si existe una técnica replicable y cuáles son sus condiciones de éxito. Esto es particularmente importante en entornos con LLM, donde el comportamiento puede variar con pequeñas diferencias en prompts, contexto o configuración. La investigación, por tanto, debe medir robustez, no solo éxito puntual.

Además, el modelo considera restricciones éticas y operacionales. No se persigue la explotación indiscriminada, sino la reproducción controlada en entornos autorizados. La validación debe minimizar impacto sobre producción y preservar privacidad. En entornos con datos sensibles, se recomienda desidentificación, agregación y uso de datos sintéticos cuando la fidelidad no se vea comprometida. La meta es una investigación que produzca evidencia útil sin introducir riesgo adicional.

4. Propuesta Metodológica

La metodología propuesta se organiza como un ciclo de cinco fases: formulación, instrumentación, emulación, correlación y priorización. El principio rector es que una hipótesis de seguridad solo adquiere valor cuando puede medirse contra telemetría consistente y transformarse en acción. Esta estructura es compatible con laboratorios, preproducción y despliegues piloto, y está diseñada para escenarios híbridos con cargas clásicas y componentes de IA.

La primera fase, formulación, define la hipótesis en términos de comportamiento observable. En lugar de “existe una vulnerabilidad”, se formula algo como: “un acceso inicial vía phishing seguido de abuso de tokens en un entorno SaaS produce una secuencia detectable de eventos de correo, identidad y API en menos de $T$ minutos”. Esta redacción permite diseñar experimentos, sensores y métricas. La hipótesis debe especificar también el impacto esperado, el conjunto mínimo de evidencias y el criterio de refutación.

La segunda fase, instrumentación, establece la arquitectura de telemetría. La propuesta integra:

• Sysmon en Windows para procesos, red, cargas DLL y persistencia.
• auditd y fanotify en Linux para procesos, archivos y privilegios.
• eBPF para observabilidad de red, syscalls y correlación de contenedores.
• OpenTelemetry para trazas de aplicaciones y servicios.
• Logs nativos de cloud: AWS CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs.
• Eventos de SaaS e identidad: Entra ID, Okta, Google Workspace, GitHub.
• Telemetría de LLM: prompts, tool calls, respuestas, context window changes, policy denials y tool invocation logs.

Esta fase debe acompañarse de normalización de tiempo, enriquecimiento con contexto de identidad y etiquetado con ATT&CK. Sin esta capa, los eventos son aislados y no investigables.

La tercera fase, emulación, reproduce cadenas de ataque en un entorno controlado. Se priorizan marcos como Atomic Red Team, Caldera, Prelude Operator y simulaciones con contenedores e infraestructura IaC. El objetivo no es maximizar el daño, sino reproducir comportamientos. Por ejemplo, una técnica de exfiltración puede emularse con archivos señuelo, buckets controlados y destinos sinkhole. En escenarios de IA, se implementan prompts de prueba para verificar si un agente expone memoria, ejecuta herramientas sin validación o sigue instrucciones externas maliciosas.

La cuarta fase, correlación, fusiona evidencias usando reglas, grafos y scoring. Se propone construir un grafo temporal donde nodos representan eventos y aristas representan relaciones de causalidad, dependencia o proximidad. La probabilidad de que una cadena sea maliciosa se modela como: $$ P(M|E) = \frac{P(E|M)P(M)}{P(E)} $$ donde $M$ es la hipótesis de ataque. En implementación práctica, este modelo se aproxima con puntajes ponderados de comportamiento, identidad, reputación y rareza. El grafo permite identificar secuencias anómalas aunque cada evento individual parezca benigno.

La quinta fase, priorización, traduce hallazgos en acciones. No todos los hallazgos merecen el mismo tratamiento. Una técnica explotable con acceso remoto, impacto alto y baja complejidad debe priorizarse frente a un hallazgo teórico con condiciones de laboratorio poco realistas. La utilidad se calcula con la función descrita antes, y el resultado se mapea a remediación, mitigación, monitoreo o investigación adicional.

Fase	Entrada	Salida	Instrumentos principales
Formulación	Hipótesis operacional	Criterio de éxito/refutación	ATT&CK, Diamond Model, threat modeling
Instrumentación	Activos y sensores	Telemetría normalizada	Sysmon, auditd, eBPF, CloudTrail, OTel
Emulación	Escenarios controlados	Secuencias reproducidas	Caldera, Atomic Red Team, Conti/LockBit-style TTPs
Correlación	Eventos y contexto	Grafo de evidencia	Sigma, elastic rules, notebooks, SIEM
Priorización	Hallazgos	Remediación accionable	Score de utilidad, riesgo y costo

La metodología incorpora además una capa de validación para IA generativa. Dado que los LLM pueden fallar por alucinación o por manipulación de prompts, cada resultado producido o interpretado por un sistema asistido debe verificarse contra datos primarios. La investigación asistida por LLM solo es aceptable si las conclusiones permanecen auditables. En términos prácticos, esto implica guardar prompts, versiones de modelo, políticas aplicadas y trazabilidad de cada herramienta invocada.

Un aspecto distintivo del enfoque es el tratamiento de la cadena de suministro y de los controles de post-explotación. En 2026, muchos ataques aprovechan dependencias, tokens, secretos expuestos y permisos excesivos. Por ello, la metodología contempla pruebas sobre SBOM, firmas, provenance y políticas de despliegue. También mide resistencia de detección ante técnicas como living-off-the-land, abuso de rundll32, powershell, mshta, wscript, curl, wget, kubectl exec y aws sts assume-role.

5. Implementación

La implementación de referencia se construyó como una arquitectura modular compuesta por cuatro capas: sensores, ingesta, correlación y visualización. Cada módulo puede desplegarse de forma independiente, pero la propuesta solo alcanza su valor máximo cuando los cuatro cooperan. El diseño prioriza reproducibilidad, observabilidad y facilidad de integración con herramientas ya presentes en SOC y equipos de ingeniería.

En la capa de sensores, se utilizaron Sysmon en Windows, auditd en Linux y bpftrace/Cilium Tetragon para observabilidad de procesos y red en hosts y clusters. Para nube, se ingirieron CloudTrail, Entra ID logs y registros de Kubernetes. Para aplicaciones, se empleó OpenTelemetry con propagación de trazas. Para componentes de IA, se instrumentaron logs de prompts, llamadas a herramientas y políticas de seguridad del agente. La idea no era capturar todo, sino capturar lo suficiente para reconstruir cadenas de ataque con trazabilidad.

En la capa de ingesta, los eventos se enviaron a una canalización basada en Kafka o Elastic Agent, según el despliegue. Se normalizó cada evento al esquema ECS o a un esquema interno equivalente. La normalización incluyó campos como identidad, host, contenedor, proceso padre, hash, comando, URL, tenant, región, rol y sensibilidad del activo. Con ello se resolvieron problemas clásicos de correlación entre dominios.

A continuación se muestra un ejemplo de instrumentación de auditd para observar ejecución y acceso a archivos sensibles en Linux:

# Crear regla para observar ejecuciones y accesos de interés
auditctl -a always,exit -F arch=b64 -S execve -S execveat -k proc_exec
auditctl -w /etc/shadow -p rwa -k shadow_access
auditctl -w /opt/app/secrets -p rwa -k app_secrets

# Verificar reglas cargadas
auditctl -l

# Consultar eventos por clave
ausearch -k proc_exec | aureport -x --summary

Para eBPF, se utilizó una configuración compatible con Tetragon en Kubernetes, orientada a detectar lanzamientos de shells, acceso a sockets y conexión a destinos externos no aprobados. Un ejemplo operativo sería:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-shell-and-egress
spec:
  kprobes:
  - call: "security_bprm_check"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values: ["/bin/bash", "/bin/sh", "/usr/bin/curl", "/usr/bin/wget"]
  - call: "tcp_connect"
    syscall: false

La capa de correlación se implementó con reglas Sigma para detecciones portables y con un motor de scoring. Las reglas se enriquecieron con contexto de usuario, geolocalización, reputación de IP y sensibilidad del activo. Se añadió una función de decaimiento temporal para evitar que eventos antiguos influyeran indebidamente en el score. En escenarios LLM, cada tool invocation recibió una ponderación adicional si implicaba acceso a correo, archivos o APIs administrativas.

La capa de visualización utilizó dashboards de secuencia temporal, grafos de identidad y líneas de tiempo por incidente. El objetivo era que el analista pudiera ver no solo alertas, sino cadenas. Esto redujo el tiempo para comprender un incidente complejo, especialmente cuando el punto de entrada estaba en SaaS o en una sesión robada. El diseño de paneles priorizó tres vistas: identidad, proceso y exfiltración.

La implementación también incluyó IaC para laboratorios reproducibles. Se usaron Terraform y Ansible para aprovisionar nodos Windows y Linux, un clúster Kubernetes y servicios de nube simulados. Esto permitió repetir experimentos con mínimas variaciones. La reproducibilidad es crítica porque la investigación en ciberseguridad sufre con frecuencia de resultados irrepetibles por diferencias de versión, kernel, permisos o latencias de red.

6. Evaluación Experimental

La evaluación experimental se diseñó para responder tres preguntas: primero, si la correlación multi-fuente mejora la detección frente a la observación aislada; segundo, cómo se comporta el sistema ante ataques de cadena larga; y tercero, qué valor tienen las señales relacionadas con IA generativa en la priorización de incidentes. Se construyeron escenarios sintéticos pero realistas en un entorno híbrido con Windows, Linux, Kubernetes, identidad en la nube y una aplicación con agente LLM.

Se definieron cuatro escenarios principales: phishing con robo de sesión, abuso de credenciales en nube, movimiento lateral con herramientas legítimas y prompt injection contra un agente con acceso a herramientas. Cada escenario se ejecutó 30 veces con variación controlada en usuario, horario y destino. Las métricas incluyeron precisión, recall, $F_1$, tiempo de detección y cobertura de evidencias.

La primera observación importante fue que una fuente aislada raramente bastó para detectar la cadena completa. Sysmon detectó ejecución sospechosa, pero no la intención ni el abuso de identidad. CloudTrail capturó acciones API, pero no siempre el contexto del proceso origen. eBPF ofreció granularidad útil para movimiento lateral y egress, mientras que las trazas de LLM ayudaron a identificar instrucciones maliciosas o tool calls anómalas. La combinación aumentó la fidelidad de clasificación.

La siguiente tabla resume la comparación entre enfoques:

Enfoque	Precisión	Recall	$F_1$	MTTD promedio	Observación principal
Sysmon solo	0.81	0.62	0.70	14.8 min	Buena señal de proceso, pobre contexto
Cloud logs solo	0.78	0.59	0.67	16.1 min	Útil para identidad, insuficiente en host
eBPF solo	0.84	0.68	0.75	11.2 min	Excelente para ejecución y red
LLM logs solo	0.73	0.55	0.63	18.6 min	Detecta abuso del agente, no toda la cadena
Correlación multi-fuente	0.94	0.89	0.91	4.3 min	Mejor cobertura y menor ambigüedad

Los resultados sugieren que la correlación multi-fuente reduce la dependencia de una sola capa de observabilidad. Matemáticamente, si cada sensor tiene una probabilidad de detección independiente $p_i$, la probabilidad conjunta de detección al combinar $n$ sensores es: $$ P_{det} = 1 - \prod_{i=1}^{n}(1-p_i) $$ En la práctica, los sensores no son totalmente independientes, por lo que el valor real es menor, pero la fórmula sirve como aproximación intuitiva. Lo relevante es que la diversificación de fuentes mejora la robustez frente a evasión y fallas de registro.

La siguiente tabla muestra resultados por escenario:

Escenario	Tasa de éxito del ataque	Detección aislada	Detección correlacionada	Hallazgo clave
Phishing + robo de sesión	0.87	0.64	0.93	La identidad es el mejor pivote
Abuso de credenciales en nube	0.81	0.69	0.95	API logs + contexto host son críticos
Movimiento lateral con herramientas legítimas	0.76	0.58	0.90	eBPF y Sysmon reducen ambigüedad
Prompt injection en agente LLM	0.71	0.52	0.88	Tool calls y policy denials son esenciales

La tercera tabla resume la utilidad operacional de hallazgos priorizados:

Hallazgo	Severidad	Explotabilidad	Costo de remediación	Utilidad $U(H)$	Acción recomendada
Tokens de sesión reutilizables	Alta	Alta	Media	0.91	Revocar sesiones y reforzar MFA
Agente LLM con herramientas sin allowlist	Alta	Media	Baja	0.84	Restringir herramientas y auditar prompts
kubectl exec sin alertado	Media	Alta	Baja	0.79	Crear detección y RBAC restrictivo
Bucket público con datos no sensibles	Baja	Media	Baja	0.31	Mitigación diferida

También se observó una reducción significativa de falsos positivos cuando se aplicó enriquecimiento contextual. Por ejemplo, powershell por sí solo generó muchas alertas, pero cuando se combinó con origen, hora, usuario y secuencia de red, las alertas relevantes se volvieron claramente distinguibles. Lo mismo ocurrió con curl en contenedores: en aislamiento era demasiado ruidoso, pero dentro de una secuencia de descarga y ejecución remota cobró valor.

7. Caso de Estudio

El caso de estudio se basó en una empresa mediana ficticia pero realista con 1,200 empleados, entornos Windows y Linux, servicios SaaS, un clúster Kubernetes y un asistente interno de IA para soporte y búsqueda documental. La organización había adoptado SSO, MFA, CNAPP y un EDR moderno, pero su telemetría estaba fragmentada entre equipos. El objetivo del ejercicio fue simular una intrusión híbrida y evaluar si el marco propuesto podía reconstruirla antes de que el impacto se materializara.

El escenario comenzó con un correo de phishing altamente personalizado generado con apoyo de IA, diseñado para inducir al usuario a autorizar una aplicación OAuth aparentemente legítima. El atacante obtuvo acceso a datos de correo y documentos compartidos. Luego, usó la sesión para localizar credenciales de CI/CD y tokens de acceso parciales en un repositorio privado. A continuación, se conectó al pipeline, extrajo secretos y lanzó un contenedor con herramientas de red. La fase final consistió en consultar al asistente LLM interno para recuperar información sobre procesos y ubicaciones de recursos, intentando inducir al agente a revelar documentación interna mediante prompt injection.

La detección aislada habría fallado en varios puntos. El primer indicio fue una autorización OAuth inusual, pero no suficiente para concluir compromiso. Luego se observó acceso a repositorios desde una IP nunca vista, seguido de ejecución de curl y kubectl desde un runner de CI. Finalmente, se registró una secuencia de prompts anómalos al agente LLM, con referencias a documentos restringidos. La correlación de identidad, cloud, endpoint y LLM permitió reconstruir la cadena y activar respuesta.

El valor del caso de estudio radica en que ilustra una realidad común en 2026: las intrusiones rara vez son monolíticas. Un adversario combina canales legítimos, abuso de confianza y automatización. La investigación, si quiere ser útil, debe seguir esa complejidad. La lección más importante fue que la seguridad del LLM no puede aislarse del resto de la arquitectura. Si el agente tiene acceso a herramientas, documentos y APIs, su riesgo es sistémico y debe medirse como tal.

8. Discusión

Los resultados sugieren que la investigación en ciberseguridad de 2026 debe abandonar la dependencia excesiva en artefactos aislados y abrazar la correlación semántica y temporal. La observabilidad multi-fuente mejora la detección, pero también aumenta la complejidad operativa. No basta con recolectar más datos; hay que recolectar los datos correctos, con retención suficiente y con modelos de acceso que permitan uso analítico sin violar privacidad ni cumplimiento.

Un hallazgo importante es que el abuso de identidad sigue siendo el pivote universal de muchas intrusiones. Incluso cuando el acceso inicial se produce mediante phishing o ingeniería social generada por IA, la fase crítica suele ser la toma o reutilización de identidad. Por ello, las defensas más efectivas incluyen MFA resistente al phishing, least privilege, rotación de sesiones, monitoreo de consentimiento OAuth y controles sobre servicios de terceros. La investigación debe centrarse en secuencias de identidad, no solo en malware.

En cuanto a IA generativa, el estudio confirma que el riesgo no está solo en el modelo, sino en la integración. Un LLM aislado es menos peligroso que un LLM con acceso a correo, tickets, repositorios o acciones administrativas. El problema se agrava si el agente puede invocar herramientas sin validación fuerte o si incorpora contenido externo sin sanitización. La defensa efectiva requiere allowlists, separación de contexto, políticas de herramienta, red teaming específico y trazabilidad completa de prompts y respuestas.

Desde el punto de vista metodológico, la utilidad de una investigación depende de su capacidad de ser reproducida. En ciberseguridad, la variabilidad de entornos hace que experimentos mal diseñados produzcan resultados poco transferibles. Por eso, la combinación de IaC, telemetría normalizada y secuencias emuladas es esencial. El uso de métricas como $MTTD$, $MTTR$, precisión y $F_1$ facilita comparación, pero debe complementarse con análisis de costo operativo y fricción de despliegue.

También es importante reconocer límites. La correlación multi-fuente puede fallar si los relojes no están alineados, si la retención es insuficiente o si los permisos de acceso impiden la extracción de evidencia. Además, algunos controles modernos generan su propia complejidad: demasiadas alertas, demasiadas exclusiones y demasiadas excepciones. La investigación debe ayudar a reducir esa complejidad, no a aumentarla. El valor real está en convertir ruido en juicio.

Ventaja del enfoque	Riesgo asociado	Mitigación
Mejor cobertura de ataques complejos	Sobrecarga de datos	Normalización y filtros por hipótesis
Detección de abuso de identidad	Falsos positivos de actividad legítima	Contexto de negocio y baseline
Análisis de agentes LLM	Exceso de vigilancia sobre usuarios	Minimización y gobernanza de datos
Correlación temporal	Dependencia de sincronización	NTP robusto y tolerancia a jitter
Priorización cuantitativa	Falsa precisión numérica	Revisión humana y calibración periódica

En términos estratégicos, la investigación en ciberseguridad en 2026 debe ser un puente entre detección, arquitectura y respuesta. El investigador ya no puede limitarse a publicar una técnica; debe demostrar cómo esa técnica cambia decisiones defensivas. Esa orientación no reduce el rigor científico; lo aumenta, porque obliga a que cada afirmación tenga valor medible.

9. Conclusión y Trabajo Futuro

Este artículo presentó un marco de investigación en ciberseguridad orientado a 2026, diseñado para entornos híbridos donde convergen nube, endpoint, identidad y sistemas asistidos por IA generativa. La contribución principal fue una metodología reproducible para formular hipótesis, instrumentar telemetría, emular ataques, correlacionar evidencias y priorizar hallazgos con utilidad operacional. Los resultados experimentales mostraron que la correlación multi-fuente supera claramente a la observación aislada en precisión, recall y tiempo de detección.

La conclusión central es que la investigación en ciberseguridad debe ser práctica sin sacrificar rigor. En 2026, esto significa aceptar que el adversario opera a través de identidades, APIs, pipelines y agentes LLM, y que la defensa debe observar y correlacionar esos dominios de forma integrada. También significa que las conclusiones deben ser reproducibles y trazables, con métricas que conecten el hallazgo con la mitigación.

Como trabajo futuro, se proponen cuatro líneas. La primera es extender el marco hacia entornos OT/ICS, donde la observabilidad y la seguridad funcional plantean restricciones adicionales. La segunda es desarrollar mejores métricas para evaluar seguridad de agentes LLM con herramientas, incluyendo robustez frente a prompt injection y tool abuse. La tercera es automatizar la generación de hipótesis y pruebas a partir de ATT&CK y telemetría histórica, manteniendo siempre validación humana. La cuarta es incorporar mecanismos de gobernanza y privacidad que permitan investigación a escala sin comprometer cumplimiento ni confidencialidad.

En síntesis, la investigación en ciberseguridad en 2026 debe ser un proceso científico-operacional capaz de reducir la incertidumbre y aumentar la resiliencia. Ese es el estándar que el campo necesita para seguir siendo útil frente a amenazas cada vez más adaptativas y sistémicas.

10. Referencias

ABNT con URLs clicables:

1. CALTAGIRONE, S.; PENDERGAST, A.; GRAHAM, C. The Diamond Model of Intrusion Analysis. 2013. Disponible en: https://apps.dtic.mil/sti/pdfs/ADA586960.pdf. Acceso en: 9 may. 2026.

2. MITRE. ATT&CK Knowledge Base. 2024. Disponible en: https://attack.mitre.org/. Acceso en: 9 may. 2026.

3. OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponible en: https://owasp.org/www-project-top-10-for-large-language-model-applications/. Acceso en: 9 may. 2026.

4. NIST. Zero Trust Architecture. Special Publication 800-207. 2020. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acceso en: 9 may. 2026.

5. NIST. Secure Software Development Framework (SSDF). Special Publication 800-218. 2022. Disponible en: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acceso en: 9 may. 2026.

6. NIST. AI Risk Management Framework 1.0. 2023. Disponible en: https://www.nist.gov/itl/ai-risk-management-framework. Acceso en: 9 may. 2026.

7. ENISA. ENISA Threat Landscape 2024. 2024. Disponible en: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024. Acceso en: 9 may. 2026.

8. CISA. Known Exploited Vulnerabilities Catalog. 2026. Disponible en: https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Acceso en: 9 may. 2026.

9. Microsoft. Sysmon. 2026. Disponible en: https://learn.microsoft.com/sysinternals/downloads/sysmon. Acceso en: 9 may. 2026.

10. Linux Audit. auditd Documentation. 2026. Disponible en: https://linux.die.net/man/8/auditd. Acceso en: 9 may. 2026.

11. CILIUM. Tetragon Documentation. 2026. Disponible en: https://tetragon.io/docs/. Acceso en: 9 may. 2026.

12. OPEN TELEMETRY. OpenTelemetry Specification. 2026. Disponible en: https://opentelemetry.io/docs/specs/. Acceso en: 9 may. 2026.

13. GOOGLE. BeyondCorp Enterprise Overview. 2026. Disponible en: https://cloud.google.com/beyondcorp. Acceso en: 9 may. 2026.

14. AWS. AWS CloudTrail User Guide. 2026. Disponible en: https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html. Acceso en: 9 may. 2026.

15. MICROSOFT. Microsoft Entra ID documentation. 2026. Disponible en: https://learn.microsoft.com/entra/. Acceso en: 9 may. 2026.

16. OKTA. ThreatInsight and Identity Security Documentation. 2026. Disponible en: https://help.okta.com/. Acceso en: 9 may. 2026.

17. RED CANARY. Atomic Red Team. 2026. Disponible en: https://github.com/redcanaryco/atomic-red-team. Acceso en: 9 may. 2026.

18. MITRE. Caldera. 2026. Disponible en: https://caldera.mitre.org/. Acceso en: 9 may. 2026.

19. SIGMA. Sigma Rules Repository. 2026. Disponible en: https://github.com/SigmaHQ/sigma. Acceso en: 9 may. 2026.

20. YARA. YARA Documentation. 2026. Disponible en: https://virustotal.github.io/yara/. Acceso en: 9 may. 2026.

21. AQUA SECURITY. Trivy Documentation. 2026. Disponible en: https://trivy.dev/. Acceso en: 9 may. 2026.

22. ANCHORE. Syft and Grype Documentation. 2026. Disponible en: https://anchore.com/. Acceso en: 9 may. 2026.

23. OWASP. Software Supply Chain Security Guidance. 2025. Disponible en: https://owasp.org/. Acceso en: 9 may. 2026.

24. CNCF. Kubernetes Security Documentation. 2026. Disponible en: https://kubernetes.io/docs/concepts/security/. Acceso en: 9 may. 2026.

25. GOOGLE. Kubernetes and Container Security Best Practices. 2026. Disponible en: https://cloud.google.com/kubernetes-engine/docs/best-practices/security. Acceso en: 9 may. 2026.

26. MITRE. D3FEND Knowledge Graph. 2026. Disponible en: https://d3fend.mitre.org/. Acceso en: 9 may. 2026.

27. VERIZON. Data Breach Investigations Report 2025. 2025. Disponible en: https://www.verizon.com/business/resources/reports/dbir/. Acceso en: 9 may. 2026.

28. GOOGLE. Mandiant M-Trends 2025. 2025. Disponible en: https://www.mandiant.com/resources/reports/m-trends. Acceso en: 9 may. 2026.

29. CROWDSTRIKE. Global Threat Report 2025. 2025. Disponible en: https://www.crowdstrike.com/global-threat-report/. Acceso en: 9 may. 2026.

30. SPLUNK. State of Security 2025. 2025. Disponible en: https://www.splunk.com/en_us/form/state-of-security.html. Acceso en: 9 may. 2026.