Panorama: el dato, no el canal#
El capítulo anterior siguió la comunicación: cómo se caza un implante que tiene que hablar con su operador, con las señales de forma que sobreviven al cifrado. Este sigue el dato: qué se está yendo, cuánto, por dónde, y —lo que resulta ser la pregunta más productiva— qué pasó antes de que se fuera. Son dos ejes del mismo plano saliente y conviene no confundirlos, porque llevan a telemetrías distintas y a controles distintos. Un canal de C2 puede estar activo durante meses moviendo kilobytes; una exfiltración puede consumarse en diez minutos por un canal que nunca antes se usó y que nunca volverá a usarse.
La tesis tiene dos mitades. La primera: la exfiltración se detecta por el canal y el volumen, no por el contenido, porque el contenido va cifrado casi siempre y porque inspeccionarlo es caro, invasivo y con frecuencia legalmente restringido. La segunda, que ordena la parte final: el estegoanálisis es un problema estadístico y no de firmas, con un límite honesto que conviene enunciar antes de desarrollarlo —funciona contra la incrustación ingenua y pierde contra el cifrado previo—.
Y hay un corolario que atraviesa todo el capítulo y que vale la pena adelantar, porque reordena dónde conviene
poner el esfuerzo: el mejor punto de detección de una fuga no es la salida, sino la preparación. Cuando los
datos ya están cruzando el borde, quedan pocos segundos y pocas opciones. En cambio la fase previa —reunir los
archivos, apilarlos en un directorio temporal, comprimirlos— ocurre dentro del host, es visible para el
sensor de endpoint y es profundamente anómala: los usuarios normales no comprimen cuatrocientos documentos en
AppData un jueves a la tarde.
Este capítulo cierra el último hilo de red del bloque rojo, el de la esteganografía y los canales encubiertos (3.12), cuya tesis —que la ocultación gana contra la inspección de contenido y no contra la telemetría de ejecución— es exactamente lo que aquí se desarrolla desde el lado defensivo.
flowchart TD
A["Acceso ya obtenido
(insider o intruso)"] --> B["Descubrimiento
búsquedas sensibles · repositorios raros"]
B --> C["Recolección
acceso/descarga masiva"]
C --> D["STAGING local
Temp · AppData · Escritorio"]
D --> E["Compresión / cifrado
ArchiveCreated"]
E --> F{"Salida"}
F -->|"nube personal"| G["CASB / proxy"]
F -->|"webmail"| H["Proxy / DLP"]
F -->|"DNS"| I["Resolver corporativo"]
F -->|"SaaS nativo
(sharing link)"| J["⚠ NO cruza la red
solo audit logs de la nube"]
F -->|"API scraping"| K["Gateway + antifraude"]
G -.->|"bloqueado →"| L["REPLIEGUE
= señal de intencionalidad"]
H -.-> L
L --> M["Borrado de evidencia"]
D -.->|"mejor punto
de detección"| N["EDR: local, anómalo, temprano"]La anatomía de una fuga#
Casi todas las exfiltraciones documentadas recorren la misma secuencia, con independencia de si el actor es un intruso externo o un empleado. Reconocerla permite construir detección en cada eslabón en lugar de apostar todo al último.
Descubrimiento. Antes de llevarse algo hay que encontrarlo. En entornos de colaboración esto deja rastro explícito: consultas de búsqueda por términos sensibles —auditoría, pagos, credenciales, datos de clientes— y acceso a repositorios que la persona no toca habitualmente. Es una señal temprana y muy barata de vigilar.
Recolección. Descarga o acceso masivo a los archivos localizados. En la nube aparece como una ráfaga de eventos de acceso y descarga; en el endpoint, como lectura intensiva.
Staging. Los archivos se concentran en un directorio local, típicamente Temp, AppData o el escritorio.
Este es el eslabón que conviene priorizar. No cruza ninguna frontera de red, así que ningún control perimetral lo
ve, pero el sensor de endpoint sí —y el patrón «muchos archivos escritos en poco tiempo en una ruta temporal por
un proceso que no es un instalador» tiene muy pocos análogos legítimos—.
Compresión y cifrado. El paquete se arma. Aquí hay un detalle que se subestima: el archivo comprimido con contraseña es a la vez la derrota del DLP y la señal que lo delata, y volveré sobre eso más abajo.
Salida. El intento de sacarlo, por alguno de los canales de la sección siguiente.
Repliegue. Si el primer canal se bloquea, el actor prueba otro. En el caso documentado de amenaza interna, el usuario intenta primero una nube personal, es interceptado por el intermediario de acceso a la nube, y inmediatamente reintenta por un servicio de correo web. Ese reintento es forensemente valioso: un usuario que tropieza con una política corporativa por error se detiene y pregunta; el que persiste por una vía alternativa está demostrando intención. Un bloqueo de DLP no es el final de un incidente, es el comienzo de una investigación.
Borrado de evidencia. Eliminar la copia local, limpiar el historial. Es una señal tardía pero, como se verá, prácticamente irrefutable.
Los canales de salida, por dificultad creciente#
No todos los canales cuestan lo mismo de detectar, y ordenarlos ayuda a decidir dónde invertir.
Carga a servicios web y nubes personales. El caso más común y el más manejable: un intermediario de acceso a la nube (CASB) o el proxy ven el destino y el volumen. La detección se apoya en la distinción entre servicios sancionados y no sancionados, más el volumen saliente. Es también donde el DLP tiene su mejor oportunidad.
Correo web personal. Similar, con la complicación de que muchas organizaciones no pueden bloquearlo en bloque. Suele aparecer como canal de repliegue, tal como muestra el caso anterior.
DNS. Ya desarrollado en 5.7 desde el eje del canal; visto desde el dato, lo que importa es que es lentísimo —la fragmentación en consultas impone un techo de ancho de banda muy bajo—, lo que lo vuelve apto para robar credenciales o documentos pequeños e inviable para volúmenes grandes sin producir una anomalía volumétrica insostenible.
Medios físicos. El USB sigue existiendo y su telemetría es de endpoint, no de red. La instalación de un dispositivo de almacenamiento queda registrada y es un eslabón que muchos programas de detección olvidan.
Interfaces programáticas. Extracción por API, tratada más abajo, donde el «volumen» hay que medirlo en registros entregados y no en bytes.
Compartición nativa de la nube. Y aquí está el caso incómodo, que merece su propia sección.
Exfiltración que no cruza el perímetro#
El escenario que más desordena las suposiciones heredadas es el de la nube, porque el dato puede irse sin que un solo paquete salga de la red corporativa.
El caso documentado empieza con un secreto expuesto —un token de API o secreto de cliente filtrado en un archivo, un repositorio o una variable de integración—. El atacante lo valida desde una IP inusual mediante un inicio de sesión no interactivo de una identidad de servicio, y con eso obtiene acceso programático al entorno. No hubo phishing, no hubo malware, no hay endpoint comprometido: hay una credencial válida usada por quien no debía. Es la misma lección que 5.3 fijó y que conviene repetir porque se olvida —que una autenticación tenga éxito no implica que sea legítima—, con el agravante de que una identidad de servicio no tiene MFA que oponer ni usuario que sospeche.
Lo que sigue es enumeración metódica a través de la API: contexto de la organización, usuarios, pertenencia a grupos y roles asignados —para mapear qué permisos tiene el token robado—, y después el recorrido sistemático del almacenamiento: sitios, unidades, carpetas. Esa secuencia deja una señal volumétrica y estructural muy distinguible: una aplicación legítima llama a un conjunto acotado y estable de rutas propias de su función, mientras que un script de descubrimiento recorre el árbol. Después vienen las búsquedas por términos sensibles y el acceso masivo a los archivos encontrados.
Y entonces la exfiltración: en lugar de descargar y subir a otro lado —lo que cruzaría el perímetro y encontraría al proxy—, el atacante crea enlaces de compartición externa sobre los documentos que le interesan. El dato no se mueve; se vuelve accesible desde afuera. Ningún control de red interviene porque no hay tráfico saliente que inspeccionar. La única telemetría que registra el hecho son los registros de auditoría del propio servicio en la nube: los eventos de creación de enlaces de compartición y de adición a enlaces seguros. Como cierre, el atacante añade credenciales propias al registro de la aplicación abusada, de modo que revocar la sesión no alcanza —hay que limpiar los artefactos de identidad, que es persistencia a nivel de aplicación y no de host—.
Scraping por API: cuando el volumen no se mide en bytes#
Una variante emparentada extrae datos sin comprometer nada: abusa de la lógica de la aplicación.
El caso documentado arranca con credential stuffing —reutilización de pares filtrados de brechas previas, el material que 2.6 describió— hasta encontrar cuentas válidas. Con el token obtenido, el atacante lo reutiliza desde múltiples direcciones, lo que evade las inspecciones centradas en el momento del inicio de sesión: la autenticación fue una sola y legítima, y todo lo problemático ocurre después. Luego mapea los endpoints y llega al núcleo del ataque: enumerar secuencialmente identificadores de clientes. Si la aplicación no valida que el objeto solicitado pertenezca a la identidad autenticada, el atacante recorre perfiles ajenos manteniendo una sesión perfectamente válida. Es un fallo de autorización, no de autenticación.
Dos cosas hacen a este caso instructivo para la detección.
La primera es qué se mide. El volumen en bytes puede ser modesto mientras el daño es enorme: lo relevante es la cantidad de registros únicos entregados y la discrepancia entre la identidad autenticada y los objetos solicitados. Esa discrepancia es la señal limpia —una consulta donde el usuario autenticado pide el identificador de otro cliente no requiere modelos, requiere que alguien haya pensado en registrarla—.
La segunda es la evasión de límites de tasa. Los umbrales estáticos son fáciles de eludir: el atacante rota tokens, direcciones y redes autónomas, y baja la cadencia hasta un patrón low-and-slow que nunca dispara el límite. Contra eso, el umbral por sesión no sirve; hay que agregar por entidad de datos —cuántos clientes distintos fueron consultados en total, por quien sea— y correlacionar la telemetría de la pasarela con la auditoría de la base de datos y el motor antifraude. Es el mismo principio que 5.7 aplicó al jitter: cuando el adversario aplana la señal en una dimensión, hay que medir en otra.
El insider: el escenario sin indicadores#
El caso más difícil de todos es aquel donde no hay nada que se pueda llamar compromiso. El actor usa sus propias credenciales, desde su equipo administrado, dentro de su horario, ejerciendo accesos que le fueron legítimamente concedidos. No hay malware que analizar, ni dominio que bloquear, ni hash que buscar: no existen IOC. Todo el peso recae sobre el comportamiento, que es la razón por la cual el análisis de comportamiento de usuarios y entidades (UEBA) —introducido en 5.6 como apoyo— pasa aquí a ser el mecanismo primario y no un complemento.
La secuencia documentada es la anatomía general con matices propios. Inicio de sesión válido y sin nada anómalo. Acceso a repositorios ajenos a la función habitual —primera desviación—. Búsquedas por términos sensibles. Descarga masiva que dispara umbrales estadísticos. Concentración local y compresión. Intento de subida a nube personal, bloqueado. Repliegue inmediato a correo web. Borrado de la copia local y del historial de navegación. Y, ya fracasado todo, un intento de acceso desde un dispositivo no administrado.
Vale detenerse en las dos señales de mayor valor probatorio, que son las tardías. La persistencia ante el bloqueo —probar un segundo canal inmediatamente después de que el primero falle— distingue el error del acto deliberado. Y el borrado de evidencia es, en palabras del propio análisis, una señal tardía pero irrefutable: nadie limpia el historial y borra el archivo comprimido que acaba de armar por casualidad.
DLP: para qué sirve y dónde se rompe#
La prevención de pérdida de datos (Data Loss Prevention) es el control específico para esto, y conviene tratarlo con precisión porque se lo suele comprar esperando más de lo que puede dar.
Funciona identificando información sensible —por patrón, como números de tarjeta o identificadores fiscales; por diccionario; por huella digital de documentos previamente clasificados; o por etiqueta aplicada al archivo— y aplicando una política cuando esa información intenta salir por un canal vigilado. Su valor real es alto en el caso mayoritario, que es el accidente o la negligencia: el empleado que adjunta el archivo equivocado, el que sube un documento a una nube personal por comodidad. En ese terreno el DLP previene incidentes todos los días.
Sus límites son tres y ninguno es un defecto de implementación. El primero: no protege lo que no fue clasificado, y la clasificación es un trabajo organizativo previo, lento y perpetuamente incompleto. El segundo: solo ve los canales donde está desplegado, de modo que su cobertura tiene exactamente la forma del inventario de canales que alguien se acordó de cubrir. El tercero y decisivo: se derrota cifrando. Un archivo comprimido con contraseña, o cifrado antes de salir, es un bloque opaco donde ningún patrón coincide. El adversario que sabe que hay DLP simplemente cifra primero.
Pero ese mismo movimiento produce la señal que lo compensa, y es un buen ejemplo del principio general del capítulo. Si el contenido es indescifrable, hay que dejar de mirar el contenido y mirar la estructura: un archivo cifrado o comprimido con contraseña, creado hace minutos, saliendo hacia un destino externo, es anómalo en sí mismo con independencia de lo que contenga. La detección madura no intenta leerlo; alerta sobre la forma. Es la misma inversión que 5.7 hizo con el tráfico cifrado.
Por eso el DLP rinde de verdad cuando se lo correlaciona en lugar de operarlo como control aislado: el agente del endpoint que ve la creación del archivo comprimido, el CASB que ve el intento de subida, y el SIEM que une ambos con la descarga masiva que los precedió. Ninguna de las tres alertas por separado justifica una respuesta; las tres juntas son la historia completa que 5.3 y 5.6 ya habían enunciado como criterio.
Estegoanálisis: un problema estadístico#
Queda el último hilo, el que 3.12 dejó abierto. La esteganografía esconde información dentro de un portador legítimo —una imagen, un audio, un documento— de modo que el portador siga pareciendo normal. Su tesis ofensiva, que 3.12 estableció, es que gana contra la inspección de contenido: ni el antivirus estático ni el DLP detectan lo que no distinguen del ruido de una fotografía. Este capítulo desarrolla la contraparte, sin repetir el catálogo de técnicas de ocultación que aquel ya recorrió.
El punto de partida es que la incrustación deja huella estadística. Los datos naturales no son aleatorios: en una imagen, los valores de píxeles vecinos están correlacionados y la distribución de los bits menos significativos tiene una estructura característica del sensor y de la compresión que la produjo. Escribir información en esos bits altera esa estructura de manera medible, aunque el resultado sea visualmente idéntico al original. El estegoanálisis explota esa alteración.
Las familias de métodos van de lo específico a lo general. El análisis de chi-cuadrado detecta la sustitución del bit menos significativo aprovechando que esa operación tiende a igualar las frecuencias de los pares de valores adyacentes, algo que no ocurre en imágenes naturales. El análisis RS estima la tasa de incrustación midiendo cómo responden grupos de píxeles a operaciones de volteo, y es más sensible que el anterior. Los métodos basados en modelos de características —del tipo SPAM y sus sucesores— extraen cientos de estadísticos de las dependencias entre píxeles vecinos y entrenan un clasificador sobre ellos; son los que mejor rinden y también los que exigen un corpus de entrenamiento representativo. En el terreno práctico, herramientas de análisis masivo aplican estas pruebas sobre lotes de imágenes, los inspectores por formato buscan datos en las estructuras donde no deberían estar, y las reglas de coincidencia detectan las firmas fijas que muchas implementaciones dejan.
Ahora el límite honesto, que es lo más importante de esta sección. El estegoanálisis estadístico funciona contra la incrustación ingenua y se degrada rápido frente a tres cosas. Frente a la baja tasa de incrustación: esconder unos pocos kilobytes en una imagen grande produce una desviación tan pequeña que se confunde con la variabilidad natural. Frente a la incrustación adaptativa, que elige las zonas de textura compleja donde la alteración se camufla. Y sobre todo frente al cifrado previo: si el mensaje se cifró antes de incrustarlo, lo que se escribe en los bits menos significativos es indistinguible de ruido aleatorio, y varias de las pruebas clásicas —que buscan la firma de un patrón— pierden su asidero.
De ahí sale la conclusión operativa, que es incómoda pero clarificadora y refuerza exactamente lo que 3.12 ya había dicho: el estegoanálisis no es viable como control de perímetro. Analizar estadísticamente cada imagen que entra y sale de una organización es computacionalmente caro y produce una tasa de falsos positivos inmanejable. Sirve como herramienta forense —sobre un conjunto acotado de archivos, en una investigación concreta, con una hipótesis previa— y no como sensor de línea.
El plano que sí rinde es el conductual, y es el mismo argumento que sostiene todo el capítulo anterior: la esteganografía protege el archivo en reposo, pero para que el contenido oculto haga algo, alguien tiene que extraerlo y ejecutarlo. Un proceso de PowerShell que lee los píxeles de una imagen y reconstruye un bloque de código deja el registro de bloques de script que 5.2 describió; el proceso que descarga una imagen desde un servicio legítimo y acto seguido inyecta código en otro proceso deja la telemetría que 5.8 trabaja. La ocultación derrota al análisis del portador y no derrota al análisis de lo que ocurre cuando el portador se usa.
Postura#
- Ingerir los registros de auditoría de las plataformas SaaS. Sin eso, la exfiltración nativa de la nube es invisible: no hay tráfico que inspeccionar. Es la brecha de cobertura más grande y más frecuente.
- Detectar en el staging, no solo en la salida. Reglas de endpoint para creación masiva de archivos en rutas temporales y para creación de archivos comprimidos por procesos que no son instaladores. Es temprano, es local y es específico.
- Alertar sobre la forma cuando el contenido es opaco: archivo cifrado o protegido con contraseña, recién creado, saliendo hacia un destino externo.
- Tratar el bloqueo de DLP como el comienzo de una investigación, no como un incidente resuelto. Y vigilar específicamente el repliegue a un segundo canal, que es la señal de intencionalidad.
- Medir el volumen en la unidad correcta: bytes para las transferencias de archivos, registros únicos para las interfaces programáticas, consultas para el plano DNS.
- Validar la propiedad de los objetos en cada llamada de API y agregar los límites por entidad de datos y no solo por sesión, para que el patrón lento y distribuido no pase por debajo.
- UEBA con línea base por usuario para el escenario de amenaza interna, con el procedimiento forense y la coordinación con recursos humanos definidos antes de necesitarlos.
- Estegoanálisis como herramienta forense acotada, nunca como control de perímetro, y detección conductual para lo que la esteganografía no puede evitar: la extracción y la ejecución.
Con esto queda cerrado el hilo de 3.12 y, con él, el plano de red del bloque rojo en su totalidad. Restan dos superficies para completar P5, y ambas son de host: la detección de persistencia en Linux (5.10) y la detección en runtime de contenedores (5.11).
Referencias#
blue-dfir/effective-threat-investigation/cap-11— comunicaciones salientes: desbalance de bytes por fase y predominio de POST y CONNECT como firma de exfiltración consumada.blue-dfir/incident-playbook/cap-03— playbook de compromiso de token de API en la nube: inicio no interactivo de identidad de servicio, enumeración por API, búsqueda sensible, acceso masivo, enlaces de compartición externa y persistencia por credenciales añadidas a la aplicación.blue-dfir/incident-playbook/cap-04— playbook de credential stuffing contra API: replay de token desde múltiples IP, abuso de lógica de negocio por enumeración de identificadores, evasión de límites de tasa con patrón lento y distribuido.blue-dfir/incident-playbook/cap-08— DNS tunneling como canal de exfiltración: staging, compresión y fragmentación en consultas.blue-dfir/incident-playbook/cap-10— playbook de amenaza interna: UEBA como mecanismo primario, acceso a repositorios infrecuentes, descarga masiva, staging y compresión, subida bloqueada a nube personal, repliegue a correo web, borrado de evidencia y preservación forense previa a la confrontación.- Estegoanálisis: síntesis propia sobre la base de 3.12 (chi-cuadrado, análisis RS, modelos de características).
- MITRE ATT&CK — T1074 (Data Staged); T1560 (Archive Collected Data); T1530 (Data from Cloud Storage); T1213 (Data from Information Repositories); T1567 (Exfiltration Over Web Service) y .002 (Exfiltration to Cloud Storage); T1048 (Exfiltration Over Alternative Protocol) y .003; T1020 (Automated Exfiltration); T1052 (Exfiltration Over Physical Medium); T1001.002 (Steganography); T1027.003 (Steganography como ocultación); T1070.004 (File Deletion); T1098.001 (Additional Cloud Credentials). Mitigaciones M1057 (Data Loss Prevention), M1037 (Filter Network Traffic), M1018 (User Account Management), M1047 (Audit).