Modulo 01. Visibilidad de amenazas en endpoint

Objetivo del modulo

Entender que tipo de evidencia puede recopilarse desde el endpoint con Tanium Threat Response y como usarla para formular hipotesis de investigacion solidas.

Resultados esperados

• Identificar evidencia relevante en procesos, archivos, conexiones y persistencia.
• Distinguir visibilidad util de ruido irrelevante.
• Preparar el endpoint para una investigacion ordenada.
• Relacionar artefactos con fases del framework MITRE ATT&CK.

Desarrollo teorico

Tanium Threat Response es el modulo de la plataforma disenado para proporcionar visibilidad de amenazas en endpoints a escala y capacidad de respuesta ante incidentes de seguridad. A diferencia de las soluciones EDR tradicionales que operan de forma autonoma en cada endpoint con reglas predefinidas, Threat Response aprovecha la arquitectura de linear chain de Tanium para ejecutar consultas de investigacion simultaneamente en cientos de miles de endpoints en segundos a traves del puerto TCP 17472. Esta capacidad de hunting a escala es lo que distingue a Tanium en el ecosistema de seguridad: permite verificar si un indicador de compromiso esta presente no solo en un endpoint sospechoso sino en la totalidad del parque gestionado, eliminando la incertidumbre sobre el alcance real de un incidente.

La investigacion de una amenaza en endpoint empieza casi siempre por una pregunta concreta: existe un proceso sospechoso, se ha creado un artefacto inusual, aparece una conexion a un dominio malicioso, hay persistencia en run keys, servicios o tareas programadas, que usuario ejecuto la accion. Threat Response permite obtener esa evidencia con rapidez mediante sensors especializados que recogen datos forenses del endpoint sin necesidad de instalar agentes adicionales, ya que toda la telemetria se obtiene a traves del Tanium Client ya desplegado.

El modulo Threat Response incluye un componente fundamental llamado Recorder, que es el motor de grabacion continua de eventos del endpoint. Recorder captura en tiempo real eventos de creacion y terminacion de procesos, operaciones de fichero (creacion, modificacion, eliminacion, renombrado), conexiones de red salientes y entrantes, modificaciones del registro de Windows, carga de modulos DLL y actividad de DNS. Estos eventos se almacenan en una base de datos local en el endpoint (index database) que permite realizar busquedas historicas. Cuando un analista lanza una investigacion, puede consultar no solo el estado actual del endpoint sino tambien la actividad pasada registrada por Recorder, lo que permite reconstruir la secuencia temporal de un ataque incluso si el proceso malicioso ya no esta activo.

Los artefactos de proceso son la primera capa de visibilidad. Tanium permite consultar procesos en ejecucion con detalle de PID, nombre, ruta completa del binario, linea de comandos, usuario, proceso padre y hash del ejecutable. Las relaciones parent-child son especialmente reveladoras. Un cmd.exe lanzado por winword.exe es una anomalia que merece investigacion inmediata. Un powershell.exe con parametros codificados en Base64 ejecutado por wscript.exe es un patron clasico de ejecucion de malware. Threat Response permite hacer estas consultas a escala: no solo en un endpoint, sino en miles simultaneamente mediante Questions que ejecutan sensors de proceso en todo el Computer Group objetivo.

Los artefactos de persistencia cubren los mecanismos que un atacante utiliza para sobrevivir a reinicios del sistema. Los vectores mas comunes incluyen Run Keys del registro de Windows, servicios de Windows creados o modificados, tareas programadas (Scheduled Tasks), suscripciones WMI Event Consumer, extensiones de navegador, objetos COM hijacked, DLLs de inicio y modificaciones de GPO. Tanium proporciona sensors especificos para consultar cada uno de estos vectores. La practica recomendada es no limitarse a un solo mecanismo de persistencia, porque un atacante sofisticado utiliza multiples puntos como respaldo para garantizar su supervivencia.

Los artefactos de red revelan comunicacion con infraestructura de comando y control (C2). Tanium obtiene conexiones TCP y UDP activas con PID asociado, direccion remota, puerto, estado y proceso responsable. Los patrones sospechosos incluyen beaconing (conexiones periodicas a intervalos regulares hacia una IP o dominio fijo), tuneles DNS (consultas DNS anomalamente frecuentes o con subdominios largos y aleatorios), trafico a puertos no estandar desde procesos que normalmente no generan comunicacion externa, y conexiones a geolocalizaciones inusuales. La correlacion entre conexion y proceso es fundamental: no basta saber que hay trafico hacia una IP sospechosa; hay que saber que proceso lo genera y con que usuario.

Los artefactos de fichero incluyen archivos nuevos, modificados o ubicados en directorios inusuales. Los directorios temporales, carpetas de usuario, rutas de descarga del navegador, cache de aplicaciones y ubicaciones ocultas merecen atencion prioritaria. Tanium permite buscar ficheros por nombre, hash SHA-256 o MD5, ruta, fecha de creacion o modificacion, tamano y atributos. Las Traces de Threat Response permiten definir reglas permanentes que monitorizan automaticamente la aparicion de ficheros con hashes conocidos como maliciosos, lo que convierte la deteccion de IOC en un proceso continuo y no solo reactivo.

Cada tipo de artefacto se mapea a tacticas y tecnicas del framework MITRE ATT&CK, lo que estructura la investigacion y facilita la comunicacion entre equipos. Ejecucion anomala de procesos corresponde a Execution (T1059 Command and Scripting Interpreter, T1204 User Execution). Persistencia en Run Keys corresponde a Persistence (T1547 Boot or Logon Autostart Execution). Conexiones C2 corresponden a Command and Control (T1071 Application Layer Protocol, T1095 Non-Application Layer Protocol, T1572 Protocol Tunneling). Esta relacion no es academica: ayuda a priorizar que buscar segun la fase del ataque que se sospecha y a comunicar hallazgos con vocabulario estandarizado.

El contexto del activo, obtenido de Tanium Asset y de la clasificacion del Computer Group, cambia radicalmente la urgencia de la investigacion. Un proceso sospechoso en un servidor de produccion expuesto a internet tiene urgencia maxima. El mismo proceso en una maquina de laboratorio aislada puede investigarse con mas calma. Threat Response debe usarse siempre teniendo en cuenta la criticidad, el propietario, el segmento de red y el rol del endpoint afectado.

Contenido ampliado

Puntos clave

• La visibilidad debe responder a hipotesis concretas, no acumular datos sin direccion.
• Threat Response acelera el acceso a evidencia de endpoint a escala.
• Diferentes amenazas priorizan artefactos distintos: persistencia, ejecucion, red o ficheros.
• El contexto del activo (criticidad, exposicion, rol) cambia la urgencia de la investigacion.
• Las relaciones parent-child de procesos son uno de los indicadores mas reveladores.
• Mapear hallazgos a MITRE ATT&CK estructura la comunicacion con otros equipos.

Checklist operativa

• Define la hipotesis inicial del incidente antes de lanzar consultas.
• Selecciona los artefactos mas relevantes segun el tipo de amenaza sospechada.
• Revisa contexto del endpoint: criticidad, owner, segmento, rol.
• Ejecuta consultas en orden: procesos, conexiones, persistencia, ficheros.
• Documenta que evidencia confirma o descarta la hipotesis.
• Escala si los hallazgos afectan a multiples endpoints.

Errores frecuentes

• Recolectar datos masivos sin pregunta concreta ni hipotesis de partida.
• No diferenciar endpoint critico de equipo estandar en la priorizacion.
• Perder trazabilidad de lo consultado y por quien.
• Confundir actividad rara con actividad maliciosa sin contexto operativo.
• Limitarse a un solo tipo de artefacto cuando el atacante usa multiples vectores.
• No usar Saved Questions para estandarizar la respuesta inicial.

Practica sugerida

Prepara un playbook de investigacion inicial para un caso de phishing con posible ejecucion de malware. Define: hipotesis inicial, cinco artefactos a consultar en orden, Questions de Tanium para cada uno, criterios para escalar y template de documentacion de hallazgos.

Preguntas de autoevaluacion

• Que artefactos mirarias primero en una sospecha de persistencia y por que.
• Por que demasiados datos sin hipotesis pueden empeorar la investigacion.
• Que papel juega el contexto del activo en la priorizacion de la respuesta.
• Como se relacionan los artefactos de endpoint con las tacticas de MITRE ATT&CK.
• Que diferencia hay entre un proceso sospechoso y un proceso confirmado como malicioso.

Cierre

La visibilidad vale de verdad cuando ayuda a responder preguntas concretas sobre el endpoint y a reducir incertidumbre con rapidez. Threat Response no es una herramienta de recoleccion masiva sino un instrumento de investigacion dirigida.

Modulo 02. Investigacion y Live Response

Objetivo del modulo

Usar Live Response y las capacidades de investigación de Tanium con control, minimizando impacto y preservando trazabilidad.

Resultados esperados

• Explicar qué añade Live Response a la investigación.
• Diferenciar consulta, recolección y acción intrusiva.
• Definir límites de uso aceptables.

Desarrollo teorico

Tanium Threat Response ofrece dos niveles de interacción con el endpoint durante una investigación. El primer nivel es la consulta pasiva mediante Questions y sensors, donde el analista obtiene información del endpoint sin modificar su estado: procesos activos, conexiones de red, archivos en disco, claves de registro y eventos registrados por Recorder. El segundo nivel es Live Response, una capacidad que permite al analista establecer una sesión interactiva directa con el endpoint para ejecutar comandos, recuperar archivos, inspeccionar configuraciones detalladas y, cuando es necesario, aplicar acciones de remediación. Este segundo nivel es significativamente más potente pero también más invasivo, y su uso requiere un marco operativo claro.

Live Response en Tanium funciona mediante una conexión directa entre la consola del analista y el Tanium Client del endpoint objetivo, canalizada a través de la infraestructura de Tanium Server por TCP 17472. Una vez establecida la sesión, el analista puede ejecutar comandos del sistema operativo en el contexto de seguridad del servicio del Tanium Client, que normalmente ejecuta como SYSTEM en Windows o root en Linux. Esto significa que Live Response tiene acceso completo al sistema, lo que le permite leer cualquier archivo, listar cualquier proceso, inspeccionar cualquier configuración y ejecutar cualquier comando. Esta capacidad es enormemente valiosa para la investigación forense, pero también conlleva riesgos significativos si se usa sin criterio.

La diferenciación entre niveles de interacción es esencial para un uso maduro. Las consultas de solo lectura mediante sensors de Threat Response (listar procesos, obtener conexiones activas, verificar claves de registro) son operaciones de bajo riesgo que no alteran el estado del endpoint y pueden ejecutarse libremente dentro de los permisos RBAC del analista. La recolección de artefactos mediante Live Response (descargar un binario sospechoso, extraer un fichero de log, obtener un volcado de memoria) tiene riesgo medio porque implica acceso directo al sistema de archivos y puede generar actividad que modifique timestamps o active alertas en otras herramientas de seguridad. Las acciones intrusivas mediante Live Response (matar un proceso, eliminar un archivo, modificar una configuración del registro, detener un servicio) tienen riesgo alto porque modifican activamente el estado del endpoint y pueden afectar a la preservación de evidencia forense, a la estabilidad del sistema o a servicios de negocio.

Las reglas operativas para el uso de Live Response deben cubrir tres principios. El primero es la proporcionalidad: el nivel de intervención debe ser acorde al nivel de confirmación de la amenaza y a la urgencia del incidente. Una sospecha preliminar basada en una alerta de baja confianza no justifica una sesión de Live Response con ejecución de comandos; una consulta con sensors es suficiente. Un incidente confirmado con evidencia de ransomware activo justifica el uso completo de Live Response incluyendo acciones de contención inmediata.

El segundo principio es la trazabilidad. Toda sesión de Live Response debe quedar registrada con el nombre del analista que la ejecutó, el endpoint objetivo, la fecha y hora de inicio y fin, los comandos ejecutados y los archivos recolectados. Tanium registra las sesiones de Live Response en los logs de auditoría de la plataforma, pero el analista debe complementar este registro con documentación propia que incluya el contexto del incidente, la hipótesis que motivó la sesión y los hallazgos obtenidos. Esta documentación es imprescindible tanto para la revisión post-incidente como para eventual uso como evidencia legal.

El tercer principio es la coordinación con otros equipos y herramientas. Si el SOC tiene un EDR como CrowdStrike o Microsoft Defender for Endpoint actuando sobre el mismo endpoint, las acciones de Live Response deben coordinarse para evitar conflictos. Un escenario típico de conflicto es cuando el EDR tiene el endpoint en modo de contención y un analista de Tanium intenta ejecutar comandos que el EDR bloquea, o cuando Live Response mata un proceso que el EDR estaba monitorizando para obtener telemetría adicional. Si un equipo de DFIR (Digital Forensics and Incident Response) externo ha sido contratado para el caso, deben establecerse reglas claras sobre qué acciones puede tomar cada equipo y en qué orden, para preservar la integridad de la cadena de custodia forense.

Las capacidades técnicas de Live Response incluyen la ejecución de comandos shell en el endpoint (cmd, PowerShell en Windows; bash, sh en Linux), la navegación por el sistema de archivos para inspeccionar directorios y contenidos, la descarga de archivos desde el endpoint a la consola del analista para análisis offline, la carga de herramientas forenses al endpoint para ejecución local (como autoruns, sigcheck o herramientas de volcado de memoria), y la ejecución de scripts predefinidos almacenados en la biblioteca de contenido de Tanium. Los scripts predefinidos son especialmente útiles porque permiten estandarizar las acciones de investigación y reducir el riesgo de errores de ejecución manual.

Un flujo de investigación típico con Live Response sigue la secuencia: primero verificar con sensors estándar si el artefacto sospechoso existe (Question sobre procesos, conexiones o ficheros), segundo establecer sesión de Live Response solo si la verificación inicial confirma la necesidad de profundizar, tercero ejecutar comandos de inspección de solo lectura para obtener contexto adicional (listar archivos en el directorio sospechoso, obtener propiedades detalladas del proceso, revisar logs locales), cuarto recolectar artefactos relevantes para análisis offline si es necesario (descargar el binario sospechoso, extraer logs de evento), y quinto aplicar acciones de contención solo con aprobación del incident commander y documentación completa.

Contenido ampliado

Puntos clave

• Live Response es potente, pero no neutro.
• La investigación madura distingue entre observación y acción.
• La coordinación con otros equipos es imprescindible.
• Debe existir registro completo de lo ejecutado.

Checklist operativa

• Verifica si hay otras herramientas o equipos actuando.
• Define objetivo exacto de la acción.
• Limita alcance al mínimo necesario.
• Documenta resultado e impacto observado.

Errores frecuentes

• Usar Live Response como primera reacción automática.
• Ejecutar comandos sin objetivo claro.
• No coordinar con DFIR o EDR.
• No registrar lo realizado sobre el endpoint.

Practica sugerida

Redacta un procedimiento para decidir cuándo usar Live Response y cuándo limitarte a observación.

Preguntas de autoevaluacion

• ¿Qué diferencia hay entre investigar y alterar estado?
• ¿Por qué la proporcionalidad importa tanto en Live Response?
• ¿Qué documentación mínima exigirías tras usarlo?

Cierre

Live Response aporta muchísimo valor cuando se usa con intención precisa, control y coordinación.