Linux e ingeniería de detección en la nube - Empezando con Defend for Containers (D4C)

Introducción

Los sistemas Linux siguen siendo una base fundamental para la infraestructura moderna, especialmente en entornos nativos en la nube donde los contenedores y las plataformas de orquestación son la norma. A medida que las cargas de trabajo pasan de anfitriones longevos a contenedores efímeros, la técnica de los atacantes también cambia. La actividad que antes dejaba artefactos persistentes en el disco se limita cada vez más a comportamientos de ejecución de corta duración que pueden ser difíciles de capturar usando fuentes de registro tradicionales.

Por tanto, la ingeniería de detección en estos entornos depende en gran medida de la visibilidad en tiempo de ejecución. Entender cómo se ejecutan los procesos dentro de contenedores, cómo se acceden a los archivos y cómo interactúan las cargas de trabajo con el host se vuelve más importante que depender de indicadores estáticos o artefactos posteriores al incidente.

Elastic proporciona varias fuentes de telemetría enfocadas en Linux para soportar este tipo de trabajo de detección. En publicaciones anteriores de este serial, nos centramos en la visibilidad a nivel de host usando Auditd y Auditd Manager, mostrando cómo los eventos de bajo nivel del sistema pueden traducir en detecciones de alta fidelidad. En esta entrada, el enfoque se traslada a Defend for Containers de Elastic: una integración de seguridad en tiempo de ejecución diseñada específicamente para cargas de trabajo Linux contenedorizadas.

El objetivo de este artículo no es documentar todas las funciones de Defender para Contenedores, sino proporcionar un punto de partida práctico para los ingenieros de detección: qué datos produce la integración y cómo razonar sobre esos datos. En la siguiente parte, veremos cómo puede aplicar a escenarios realistas de ataques de contenedores.

Transparencia optimizada con Defender para contenedores

Nos complace anunciar la llegada de Defender for Containers en la versión 9.3.0 Libera. Esta integración aporta un enfoque simplificado a la seguridad de contenedores, ofreciendo una base estable para la visibilidad en infraestructuras nativas de la nube. Los usuarios pueden aprovechar un conjunto de reglas de detección diseñadas para defender de amenazas modernas de Kubernetes y vulnerabilidades específicas de contenedores. La llegada de Defender for Containers viene acompañada de un conjunto de reglas de detección específico para contenedores, diseñado en torno a modelos realistas de contenedores y de amenaza Kubernetes.

En el momento de escribir esto, el conjunto de reglas Defender for Containers proporciona cobertura básica para técnicas comunes de ataque a contenedores, incluyendo actividad de reconocimiento, intentos de acceso a credenciales, ataques kubelet, abuso de tokens de cuentas de servicio, ejecución interactiva de procesos, creación y modificación de archivos, abuso de intérpretes, ejecución de cargas útiles codificadas, instalación de herramientas, comportamiento de túnel y múltiples vectores de escalada de privilegios. Es importante destacar que todas las reglas de detección existentes específicas de contenedores y Kubernetes se hicieron compatibles con Defender for Containers, permitiendo que la lógica previamente centrada en el host opere directamente sobre la telemetría en tiempo de ejecución del contenedor.

Esto convierte a Defender for Containers en una fuente de datos práctica e inmediatamente utilizable para ingenieros de detección Linux centrados en la detección en tiempo de ejecución basada en comportamientos. El resto de esta publicación se centra en cómo se ve esa telemetría en la práctica y cómo puede aplicar a escenarios reales de ataques de contenedores.

Introducción a Defender para contenedores

Defend for Containers es una integración de seguridad en tiempo de ejecución que proporciona visibilidad de los contenedores Linux mientras se ejecutan. En lugar de depender de escaneos estáticos de imágenes o registros post-ejecución, se centra en observar el comportamiento del contenedor en tiempo real.

A un nivel general, Defender for Containers captura eventos de ejecución relevantes para la seguridad de contenedores en ejecución, como la ejecución de procesos y el acceso a archivos. Estos eventos se enriquecen con contexto de contenedor y orquestación y se envían a Elasticsearch, donde pueden ser analizados y empleados como entrada para las reglas de detección.

Desde una perspectiva de ingeniería de detección, Defender for Containers se sitúa en la intersección entre el comportamiento tradicional de Linux y el contexto del contenedor. Los procesos, las llamadas a sistemas y la actividad de archivos siguen siendo señales centrales, pero ahora están restringidos a contenedores, espacios de nombres y cargas de trabajo que pueden existir solo brevemente.

Defender para Contenedores se despliega como parte del Agente Elástico e integra directamente con Seguridad Elástica. Una vez habilitado, proporciona un flujo dedicado de eventos de ejecución en contenedor que pueden consultar usando KQL o ES|QL, o consumido directamente por análisis de detección. Esto permite a los ingenieros de detección aplicar técnicas de análisis familiares teniendo en cuenta las realidades operativas de las cargas de trabajo nativas en la nube.

En las secciones siguientes, examinaremos los eventos de Defender para Contenedores con más detalle y repasaremos varios escenarios de ataques a contenedores para ilustrar cómo estos datos pueden emplear en la práctica.

Configuración de Defender para Contenedores

Antes de poder aprovechar la visibilidad y análisis en tiempo de ejecución de Defender for Containers, necesitas desplegar la integración y configurar una política que defina qué eventos observar y qué acciones tomar cuando se encuentren actividades de coincidencia. Más información sobre la integración y su configuración se puede encontrar aquí. A un nivel general, esta configuración consiste en:

1. Desplegar la integración de Defend for Containers vía Elastic Agent en tu entorno Kubernetes.
2. Configurar o personalizar la política Defender para contenedores, que consiste en selectores que definen qué operaciones emparejar y respuestas que definen qué acciones realizar.
3. Validar y perfeccionar la política basar en el comportamiento observado de la carga de trabajo.

Métodos de despliegue

Defender para contenedores se entrega como una integración con Elastic Agent y depende de Elastic Agent para recoger y reenviar la telemetría en tiempo de ejecución de contenedores a tu Elastic Stack. Para las cargas de trabajo de Kubernetes, instalas la integración a través de la interfaz de seguridad de Elastic y luego inscribes agentes en los nodos del clúster.

El flujo básico de despliegue es:

En la interfaz de seguridad de Elastic, navega hasta Fleet y crea una nueva Política de Agente (o agrega la integración a una existente). Una vez creada la Política de Agente, podemos agregar la integración "Defender para contenedores" a la política.

Dale un nombre a la integración y, opcionalmente, ajusta los selectores y respuestas por defecto (veremos las opciones disponibles más adelante en esta publicación). Una vez seleccionada la opción "Agregar integración", debería estar disponible una nueva Política de Agente con la integración correcta.

Para esta demostración, aprovecharemos el método de despliegue de Kubernetes. Para desplegar esta política en una carga de trabajo, podemos navegar a Acciones → Agregar agente → Kubernetes. Aquí vemos instrucciones para copiar o descargar el manifiesto de Kubernetes.

Una nota importante a tener en cuenta es: "Tenga en cuenta que el siguiente manifiesto contiene límites de recursos que pueden no ser apropiados para un entorno de producción. Revisa nuestra guía sobre cómo escalar el Agente Elástico en Kubernetes antes de desplegar este manifiesto."

Tendrás que incluir los siguientes capabilities bajo securityContext en tu YAML de Kubernetes para que el servicio funcione:

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

Luego de copiar o descargar el manifiesto elastic-agent-managed-kubernetes.yml proporcionado, puedes editarlo según lo necesites y aplicarlo con:

kubectl apply -f elastic-agent-managed-kubernetes.yml

Como también se menciona en el manifiesto, revisa la guía "Ejecutar Elastic Agent en Kubernetes gestionado por Fleet" para más información sobre despliegues.

Espera a que los pods de Elastic Agent se programen y a que los datos empiecen a fluir hacia Elasticsearch.

Una vez desplegado, Elastic Agent establecerá una conexión con Fleet, se inscribirá bajo la política seleccionada y comenzará a emitir telemetría Defender para Contenedores que Elastic Security podrá consumir.

En la siguiente sección, analizaremos las opciones de configuración de integración y exploraremos qué funciones están disponibles para usar.

Políticas de Defender para Contenedores

En el núcleo de la configuración de Defend for Containers está la política. Las políticas determinan qué actividad observar y cómo responder cuando ocurren eventos de coincidencia. Las políticas se componen de dos bloques fundamentales:

• Selectores: definen qué eventos son de interés especificando operaciones y condiciones;
• Respuestas: definir qué acciones tomar cuando se cumplen las condiciones de un seleccionador.

Las políticas de Defender para Contenedores pueden editar antes del despliegue o modificar luego del despliegue a través del editor de políticas de la interfaz de seguridad elástica.

Estructura de políticas

Cada política debe contener al menos un selector y al menos una respuesta. Un selector típico especifica una o más operaciones (como eventos de proceso o actividades de archivo) y emplea condiciones (como nombre de imagen del contenedor, espacio de nombres o etiqueta de pod) para acotar el alcance. Las respuestas hacen referencia a los selectores e indican qué acción tomar cuando coinciden los eventos.

La política predeterminada de Defender para contenedores incluye dos pares de selector y respuesta: "Detección de amenazas" y "Detección y prevención de deriva".

Detección de amenazas: Un selector llamado allProcesses coincide con todos los eventos fork y exec de los contenedores.

Y el response asociado tiene la acción configurada para Log, cerciorando que los eventos sean absorbidos y puedan ser analizados.

Detección y prevención de deriva: Un selector llamado executableChanges coincide con createExecutable y modifyExecutable operaciones.

Y la respuesta está configurada para crear alertas (y puede modificar para bloquear esas operaciones).

Estos pueden modificar mediante la interfaz, pero en el fondo, estas políticas son simples archivos de configuración YAML que pueden modificar fácilmente y usar en cualquier flujo CI|CD:

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

A continuación, echaremos un vistazo a algunos selectores y respuestas de ejemplo y discutiremos las opciones que tienes para configurar la integración a tu gusto.

Ejemplo de fragmento de selector

Los selectores permiten emparejamientos de grano fino usando condiciones en campos como:

• containerImageFullName: nombres de imagen completa como docker.io/nginx;
• containerImageName: nombres parciales de imágenes;
• containerImageTag: etiquetas específicas como launt;
• kubernetesClusterId: IDs de clúster Kubernetes;
• kubernetesClusterName: nombres de clústeres de Kubernetes;
• kubernetesNamespace: espacios de nombres donde se ejecuta la carga de trabajo;
• kubernetesPodName: nombres de pods, con soporte para comodines posteriores;
• kubernetesPodLabel: pares clave/valor de etiqueta, con soporte de comodines.

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

En este ejemplo, el selector llamado nodeExports coincide con eventos de archivo que crean o modifican ejecutables dentro de contenedores cuyos nombres de imagen contienen "nginx" y cuyo espacio de nombres Kubernetes comienza con “prod-”.

Ejemplo de fragmento de respuesta

Las respuestas determinan qué ocurre cuando se cumplen las condiciones del selector. Las acciones comunes incluyen:

• log: enviar el evento como telemetría para análisis;
• alert: crear una alerta en Elastic Security;
• block: impide la operación (para tipos soportados).

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

Aquí, la respuesta llamada alertAndBlockNodeExports hace referencia al selector nodeExports previamente definido y generará una alerta y bloqueará la operación.

Comodines y emparejamiento

Los selectores en Defender for Containers soportan comodines posteriores en condiciones basadas en cadenas (como nombres de pods o etiquetas de imagen). Esto permite emparejamientos amplios sin enumerar todos los valores posibles. Por ejemplo, un selector de pods de backend-* coincidirá con todos los pods cuyos nombres comienzan por backend-, mientras que una condición de etiqueta como role:api* coincide con valores de etiqueta que comienzan con api.

Este comodín es esencial en entornos dinámicos donde las cargas de trabajo escalan y cambian rápidamente.

Además de la simple coincidencia de cadenas, los selectores Defender for Containers también soportan semántica de comodín basada en rutas al emparejar rutas de archivos. Consideremos el siguiente ejemplo de selector:

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

En este ejemplo:

• /usr/bin/echo coincide solo con el echo binario en ese mismo camino.
• /usr/sbin/* Coincide con todo lo que es hijo directo de /usr/sbin.
• /usr/local/** Coincide todo recursivamente bajo /usr/local, incluyendo caminos como /usr/local/bin/something.

Estas distinciones permiten establecer con precisión el alcance de los selectores basados en archivos, equilibrando la cobertura y el ruido. En la práctica, permiten a los ingenieros de detección dirigir a binarios específicos, directorios completos o árboles de directorios profundos, dependiendo del caso de uso, sin recurrir a reglas excesivamente permisivas.

Uniéndolo todo

Hasta ahora, analizamos los selectores de Defender for Containers, la semántica de comodines, los tipos de eventos y cómo reflejan el comportamiento de los atacantes en tiempo de ejecución. El paso final es entender cómo estas piezas se unen dentro de una política para expresar una lógica real de detección.

Consideremos el siguiente fragmento de política:

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

Esta política define tres selectores. Dos selectores (binDirExeMods y etcFileChanges) describen la actividad del sistema de archivos de interés, mientras que el tercer selector (nginx) describe un contexto de contenedor a excluir.

La sección de respuesta une estos selectores. Los selectores listados bajo match están lógicamente OR'd, lo que significa que cualquiera de las dos condiciones es suficiente para activar la respuesta. El selector listado bajo exclude actúa como un NOTlógico , eliminando eventos coincidentes cuando la imagen del contenedor está nginx.

Leída en lenguaje claro, la política expresa la siguiente lógica:

Si se crea o modifica un ejecutable en cualquier parte de /usr/bin, o se crea, modifica o elimina un archivo bajo /etc , y la actividad no se origina en un contenedor de nginx , entonces genera una alerta y bloquea la acción.

En forma booleana, esto puede expresar como:

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

Aquí es donde las políticas de Defender para Contenedores se vuelven poderosas. En lugar de escribir lógica de detección compleja en un lenguaje de consulta, los selectores te permiten descomponer el comportamiento en pequeños bloques reutilizables y luego combinarlos declarativamente. Mezclando selectores basados en caminos, tipos de operaciones, contexto del contenedor y exclusiones, puedes expresar una lógica de detección matizada que sigue siendo legible y mantenible.

En la práctica, este modelo permite a los ingenieros de detección traducir hipótesis de amenaza directamente en lógica de políticas: qué comportamiento importa, dónde ocurre, en qué cargas de trabajo y qué debe ocurrir cuando ocurre.

Validación y refinamiento de políticas

Una vez desplegada una política, es fundamental validarla frente al comportamiento real de la carga de trabajo antes de permitir respuestas agresivas como el bloqueo. Las políticas demasiado restrictivas pueden interrumpir las operaciones normales de los contenedores; Las políticas demasiado permisivas pueden dejar pasar desapercibidas actividades no deseadas.

Un flujo de trabajo recomendado es:

1. Despliega la política predeterminada en modo de monitorización (por ejemplo, con selectores que registran eventos).
2. Observa los eventos que aparecen en Elasticsearch para entender los patrones normales de carga de trabajo.
3. Ajusta los selectores y respuestas de forma incremental, pasando de solo log → alerta → bloque, probando en cada etapa.
4. Emplea un clúster de staging o de prueba para validar los comportamientos de bloqueo antes de aplicarlos en producción.

Limitaciones de Defender para la Beta de Contenedores

Al momento de escribir esto, Defend for Containers está disponible como una integración Beta, y sus capacidades actuales y soporte para la plataforma reflejan ese estado.

Defend for Containers es compatible formalmente con Amazon EKS y Google GKE. Aunque la integración puede desplegar en Azure AKS, esta configuración no está oficialmente soportada. En individuo, los despliegues de AKS actualmente carecen de telemetría de eventos de archivos, lo que limita la cobertura de detección para técnicas de ataque basadas en archivos en esos entornos.

La Beta actual tampoco recoge eventos de la red. Como resultado, las detecciones relacionadas con conexiones salientes, movimientos laterales de red o exfiltración de datos deben basar en fuentes de datos complementarias, como la integración Network Packet Capture o las integraciones Packetbeat , en lugar de solo en la telemetría de Defender para contenedores.

Para la actividad de archivos, Defender para contenedores registra intencionadamente los eventos abiertos de archivos solo cuando se abren con intención de escritura. Esta elección de diseño reduce el ruido y se centra en comportamientos que modifiquen el estado del sistema. Sin embargo, también significa que el acceso de solo lectura a archivos sensibles, como el descubrimiento secreto, el scraping de configuración o los intentos fallidos de acceso, no es actualmente observable.

Esta limitación afecta a casos de detección como:

• Buscando y leyendo tokens de cuentas de servicio Kubernetes,
• Escanear archivos .env o material de credenciales.

Estas son áreas donde futuras iteraciones de Defend for Containers podrían proporcionar una telemetría más granular para apoyar casos de uso avanzados en ingeniería de detección.

Activando las reglas de detección predefinidas de Defender for Containers

Defender para los barcos de contenedores con un conjunto de reglas de detección preconstruidas que proporcionan cobertura básica para técnicas comunes de ataque a contenedores. Una vez habilitada la integración, estas reglas pueden activar directamente desde Elastic Security sin configuración adicional.

Se recomienda habilitar las reglas precompiladas como punto de partida, ya que están diseñadas para alinear con la telemetría en tiempo de ejecución y ejecución de cobertura de Defend for Containers, la modificación de archivos, la persistencia y el comportamiento post-compromiso dentro de los contenedores. A partir de ahí, las reglas pueden ampliar o perfeccionar para adaptar a cargas de trabajo y modelos de amenazas específicos del entorno.

Filtrando por "Data Source: Elastic Defend for Containers", puedes encontrar todas las reglas asociadas a esta integración.

Nota: si no ves que aparezcan reglas, cerciórate de que tu pila esté ejecutando la versión 9.3.0, ya que estas reglas se despliegan solo en la versión 9.3.0+.

Con todas las limitaciones importantes de la Beta mapeadas, la integración desplegada, las reglas de detección preconstruidas instaladas y habilitadas, y una política funcional establecido, el siguiente paso es explorar la semántica de eventos que produce Defend para contenedores, incluyendo campos comúnmente usados en lógica de detección, consideraciones de rendimiento y cómo estos eventos difieren de los eventos de Elastic Defend.

Análisis de eventos de Defender para contenedores

Ahora que Defender for Containers está desplegado y las políticas están establecidas, el siguiente paso es entender los eventos que genera. De forma similar a trabajar con Elastic Defend o Auditd Manager, Defender para la telemetría de contenedores se vuelve mucho más valiosa una vez que desarrollas un modelo mental de cómo se estructuran los eventos y qué campos son más relevantes para la ingeniería de detección.

Defend for Containers produce múltiples tipos de eventos, especialmente eventos de proceso y de archivo, cada uno enriquecido con contexto de contenedor, host y orquestación. Aunque las señales subyacentes siguen arraigadas en el comportamiento de Linux, los Kubernetes adicionales y los metadatos del contenedor te permiten razonar sobre la actividad de formas que no son posibles con la telemetría solo del host.

Las siguientes secciones recorren los grupos de campo y tipos de eventos más importantes, empleando eventos reales de Defender for Containers como puntos de referencia.

Campos comunes

Antes de adentrar en categorías específicas de eventos, es útil entender los campos que aparecen de forma constante en la telemetría de Defender for Containers. Estos campos proporcionan el pegamento contextual que vincula las acciones individuales en tiempo de ejecución con políticas, selectores y los puntos de ejecución subyacentes dentro del kernel.

Aunque los eventos de proceso y archivo difieren en sus detalles, los campos descritos a continuación están presentes en los flujos de datos de Defender para contenedores y suelen ser el primer lugar a buscar al validar detecciones o solucionar el comportamiento de la política.

Defender para contexto específico de contenedores

Defender para contenedores agrega varios campos específicos sobre cómo se recogen eventos y se aplican las políticas.

El campo cloud_defend.hook_point indica en qué parte del núcleo se capturó el evento. En el ejemplo mostrado, valores como tracepoint__sched_process_fork y tracepoint__sched_process_exec revelan que el evento se generó a partir de puntos de traza del núcleo asociados con la creación y ejecución de procesos.

El campo cloud_defend.matched_selectors muestra qué selectores en la política activa coincidieron con el evento. En el ejemplo, el valor allProcesses indica que este evento coincidió con un selector amplio que captura toda la actividad del proceso. Al ajustar políticas o investigar alertas, este campo es esencial para entender por qué se capturó un evento.

Los campos cloud_defend.package_policy_id y cloud_defend.package_policy_revision vinculan el evento a una política específica de Agente Elástico y su revisión. Esto permite correlacionar eventos con cambios de configuración a lo largo del tiempo y verificar qué versión de una política estaba activa cuando ocurrió el evento.

Metadatos de eventos

Los eventos Defend for Containers siguen las convenciones de Elastic Common Schema e incluyen metadatos estándar de eventos que describen el tipo y el ciclo de vida de la actividad.

El campo event.category identifica el tipo de actividad de alto nivel, como process o file, y suele ser el primer campo empleado al filtrar los datos de Defender para contenedores. El campo event.action describe lo que ocurrió, por ejemplo, fork o exec para la actividad del proceso, o open, creation, modificationy deletion para eventos de archivo.

El campo event.type agrega contexto al ciclo de vida, como start para la ejecución de procesos, y a menudo se emplea junto con event.action para distinguir diferentes fases de actividad. El campo event.dataset indica el flujo de datos Defender for Containers de origen, como cloud_defend.process, lo cual es útil al construir consultas o detecciones con alcance de conjuntos de datos.

Campos adicionales de metadatos como event.id, event.ingestedy event.kind se emplean principalmente para correlación, ordenamiento y resolución de problemas, más que para lógica de detección.

Información del host

Los eventos Defend for Containers incluyen el contexto completo del anfitrión, similar a Elastic Defend y Auditd Manager. Esto permite correlacionar la actividad en tiempo de ejecución del contenedor con el nodo Kubernetes subyacente.

El campo host.name identifica el nodo en el que se ejecuta el contenedor, mientras que host.os.* proporciona detalles del sistema operativo, como la distribución y la versión del kernel. El campo host.architecture indica la arquitectura de la CPU, que puede ser relevante al analizar la ejecución binaria o el comportamiento específico del núcleo.

Un campo particularmente útil es host.pid_ns_ino, que identifica el espacio de nombres PID. Este campo permite correlacionar la actividad del contenedor con la telemetría a nivel de anfitrión y de núcleo, y es especialmente valioso al investigar intentos de escape de contenedores o impactos a nivel de nodo.

Este contexto de host es fundamental al analizar ataques cloud-native, ya que varios contenedores suelen compartir el mismo host y kernel, y el comportamiento en tiempo de ejecución de un contenedor puede tener participaciones más allá de sus límites.

Contexto del contenedor y del orquestador

La principal fortaleza de Defender por Contenedores radica en su conciencia de contenedores. Cada evento en tiempo de ejecución se enriquece con metadatos de contenedor y orquestación, permitiendo analizar la actividad en el contexto de lo que se está ejecutando, dónde se ejecuta y con qué privilegios.

A nivel de contenedor, campos como container.id y container.name identifican de forma única el contenedor en ejecución, mientras que container.image.name, container.image.tag, y el hash de imagen proporcionan visibilidad sobre el origen y la versión de la carga de trabajo. Esto es especialmente útil para distinguir entre imágenes de utilidad esperadas y cargas de trabajo inesperadas o ad hoc.

Un campo clave para la evaluación de riesgos es container.security_context.privileged. Este campo indica explícitamente si un contenedor está ejecutar en modo privilegiado. Cuando la ejecución privilegiada se combina con otras señales como shells interactivos o amplias capacidades de Linux, el perfil de riesgo de cualquier actividad detectada aumenta significativamente.

Defender para contenedores también enriquece eventos con contexto de orquestación. Campos como orchestrator.cluster.name, orchestrator.namespacey orchestrator.resource.name (normalmente el nombre del Pod) vinculan el comportamiento en tiempo de ejecución a las cargas de trabajo de Kubernetes. Las etiquetas expuestas mediante orchestrator.resource.label permiten además que las detecciones incorporen la intención de carga de trabajo y la propiedad.

Para la ingeniería de detección, este contexto permite un alcance preciso de las detecciones para:

• espacios de nombres específicos (por ejemplo, kube-system),
• contenedores privilegiados o de alto riesgo,
• cargas de trabajo con etiquetas sensibles,
• o imágenes de utilidad conocidas como netshoot, kubectlo curl.

Esta capa de enriquecimiento permite expresar directamente la lógica de detección consciente de contenedores, sin tener que inferir intención indirectamente a partir de rutas del sistema de archivos, cgroups o identificadores de espacios de nombres.

Eventos de proceso

La ejecución de procesos es uno de los tipos de señal más importantes que ofrece Defender para Contenedores. Los eventos de proceso capturan actividades fork, execy end dentro de los contenedores y exponen información detallada de linaje fundamental para entender cómo se desarrolla la ejecución en tiempo de ejecución.

Varios campos son especialmente importantes para la ingeniería de detección. La combinación de process.name y process.executable identifica qué se ejecutó y desde dónde, mientras que process.args proporciona una visión de cómo se invocó. Campos como process.pid, process.start, process.endy process.exit_code describen el ciclo de vida del proceso y son útiles para el análisis temporal y la reconstrucción de ejecución-flujo. El process.entity_id proporciona un identificador estable que permite rastrear procesos a través de múltiples eventos relacionados.

Defender para contenedores también recoge información rica sobre ascendencia. Los campos bajo process.parent.* describen el proceso padre inmediato, lo que permite detectar relaciones sospechosas padre-hijo, como las conchas generadas por binarios inesperados. Además, process.entry_leader.* y process.session_leader.* proporcionan anclajes de nivel superior dentro del árbol de procesos.

Al igual que Elastic Defend, Defend for Containers modela los procesos como un grafo en lugar de eventos aislados. El líder de entrada es especialmente útil en entornos de contenedores, ya que a menudo representa el proceso inicial lanzado por el tiempo de ejecución del contenedor (por ejemplo, containerd, runc, o una shell especificada como punto de entrada del contenedor). Anclar las detecciones al líder de entrada permite interpretar los árboles de proceso de forma consistente, incluso cuando los contenedores generan muchos procesos hijos de corta duración.

Los campos líderes de sesión proporcionan contexto adicional sobre la ejecución interactiva y los límites de la sesión, ayudando a distinguir servicios en segundo plano de actividades interactivas o impulsadas por atacantes.

En conjunto, estos campos permiten expresar una lógica de detección que va más allá de las ejecuciones individuales y, en su lugar, razona sobre cadenas de ejecución, linaje e intención, lo cual es esencial para detectar técnicas reales de ataque en contenedores.

Capacidades y contexto de privilegios

Uno de los aspectos más poderosos de los eventos de proceso Defender for Containers es la inclusión de información de capacidades de Linux. Para cada proceso, Defender para Contenedores expone tanto los conjuntos de capacidades efectivos como permitidos a través de:

• process.thread.capabilities.effective
• process.thread.capabilities.permitted

Estos campos describen lo que un proceso puede hacer realmente en tiempo de ejecución, independientemente de su ID de usuario o del límite del contenedor.

En contenedores privilegiados, los procesos a menudo exponen un amplio conjunto de capacidades efectivas, incluyendo otras muy sensibles como CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIOy CAP_BPF. La presencia de estas capacidades cambia significativamente el perfil de riesgo de cualquier comando ejecutado, ya que permiten acciones que pueden afectar directamente al kernel del host u otras cargas de trabajo.

Desde la perspectiva de la ingeniería de detección, este contexto es fundamental. Permite que las detecciones vayan más allá de la simple coincidencia de nombres de procesos y en su lugar razonen sobre el impacto. La misma ejecución binaria puede tener participaciones muy diferentes dependiendo de si se ejecuta con un conjunto de capacidades mínimo o con privilegios cercanos al nivel del host.

En la práctica, los datos de capacidades permiten a los ingenieros de detección:

• Identifica herramientas sospechosas realizadas en recipientes excesivamente permisivos.
• Correlaciona el comportamiento en tiempo de ejecución con combinaciones peligrosas de capacidades.
• Prioriza las alertas basar en el potencial real de explotación en lugar de en la actividad superficial.

Esto resulta especialmente relevante en la investigación de breakout de contenedores, donde la presencia o ausencia de capacidades específicas suele determinar si un exploit es viable.

Ejecución interactiva

El campo process.interactive indica si un proceso está asociado a una sesión interactiva. En entornos de contenedores, la ejecución interactiva es relativamente rara para cargas de trabajo de producción y a menudo se correlaciona fuertemente con la actividad posterior al compromiso o la actividad práctica en el teclado.

Defender para contenedores expone la interactividad no solo a nivel de proceso, sino también a través de contextos de ejecución relacionados, incluyendo process.parent.interactive, process.entry_leader.interactivey process.session_leader.interactive. Esto permite determinar si toda una cadena de ejecución es interactiva, en lugar de depender de una sola bandera de proceso de forma aislada.

Ejemplos comunes de ejecución interactiva dentro de contenedores incluyen generar una bash o sh shell, ejecutar utilidades interactivas como curl, kubectlo busybox, o el reconocimiento dirigido por el operador dentro de un Pod comprometido. Aunque estas acciones pueden ser legítimas durante la depuración, son poco comunes en cargas de trabajo de producción en estado estacionario.

Cuando se combina con la imagen del contenedor, el espacio de nombres y el contexto de privilegios, la ejecución interactiva se convierte en una señal de anomalía fuerte. Permite que la lógica de detección distinga entre el comportamiento automatizado esperado del contenedor y la actividad de forma más coherente con la intervención manual o la exploración impulsada por el atacante.

Eventos de archivo

Los eventos de archivo Defend for Containers capturan la actividad del sistema de archivos dentro de contenedores y se emiten para una variedad de operaciones. A diferencia de la monitorización tradicional de integridad de archivos, estos eventos son conscientes del tiempo de ejecución y están organizados en cargas de trabajo de contenedores, proporcionando contexto sobre cómo y por qué ocurren los cambios en los archivos.

Defend for Containers puede detectar actividad de archivos como apertura de archivos con intención de escritura, modificaciones de contenido, creación de archivos, cambios de nombre, cambios de licencias y eliminaciones. Al centrar en operaciones orientadas a la escritura, Defender para Contenedores enfatiza comportamientos que alteran el estado del sistema en lugar del acceso pasivo a archivos.

Esto permite a los ingenieros de detección razonar sobre los patrones de uso de archivos en tiempo de ejecución, no solo como resultado de un cambio.

Varios campos son especialmente importantes al construir detecciones basadas en archivos. Los campos file.path y file.name identifican el archivo afectado y su ubicación, mientras que file.extension pueden ayudar a distinguir binarios, scripts y archivos de configuración. Los campos event.action y event.type describen qué operación ocurrió y cómo debe interpretar en el ciclo de vida del evento.

En conjunto, estos campos permiten a Defender para contenedores distinguir el acceso benigno a archivos de patrones de modificación sospechosos, como escribir binarios o cambiar licencias dentro de directorios sensibles.

Unirlo

Como con cualquier otra fuente de datos, la telemetría de Defender para Contenedores se vuelve realmente valiosa una vez que entiendes cómo combinar campos entre los dominios de proceso, archivo, contenedor y orquestación. En lugar de depender de indicadores estáticos, Defender para Contenedores permite la ingeniería de detección basada en el comportamiento en tiempo de ejecución, el contexto de privilegios y la identidad de la carga de trabajo.

Conclusión

Defender para contenedores en Elastic Stack 9.3.0 incluye la detección en tiempo de ejecución de contenedores como componente central de la ingeniería de detección en Linux. Cuenta con un alcance claro, un modelo de configuración basado en políticas y telemetría en tiempo de ejecución diseñada específicamente para cargas de trabajo contenedorizadas.

En esta publicación, analizamos cómo desplegar Defend for Containers, cómo está estructurado su modelo de políticas y cómo se generan y enriquecen los eventos en tiempo de ejecución con contexto de contenedores y orquestación. Exploramos la estructura de los eventos de proceso y archivo, los metadatos de capacidades, las señales de ejecución interactivas y los campos específicos de contenedor que permiten expresar las detecciones de manera consciente de la carga de trabajo.

La conclusión clave es que la detección efectiva de contenedores requiere razonar sobre el comportamiento en tiempo de ejecución en contexto: los procesos, las modificaciones de archivos, los privilegios y la identidad de la carga de trabajo deben evaluar juntos. Defender para contenedores proporciona la telemetría necesaria para hacerlo posible.

En el próximo artículo, construiremos sobre esta base repasando un escenario realista de ataque de contenedores y demostrando cómo la telemetría de Defender para Contenedores presenta cada etapa de compromiso en la práctica.