Propiedades de la campaña

Una campaña detectada por la aplicación NSX Network Detection and Response se caracteriza por varias propiedades.

A continuación se detallan las propiedades de la campaña y sus definiciones.

Nombre de propiedad	Descripción
Nombre	Un identificador de campaña que identifica de forma exclusiva la campaña.
Hosts	Los hosts que se ven afectados por la campaña.
Amenaza	Las amenazas detectadas de la campaña.
Etapas de ataque	Las fases del ciclo de vida del almacén correspondientes a las actividades detectadas. Consulte Acerca de las etapas de ataque para obtener detalles.
Duración	El intervalo de tiempo durante el cual se han observado las actividades asociadas con una campaña.

Acerca de las etapas de ataque

Las etapas de ataque son las fases del ciclo de vida de un adversario que corresponden a las actividades detectadas por la aplicación NSX Network Detection and Response.

Un modelo de adversario describe las acciones que puede realizar un adversario para comprometer y operar dentro de una red empresarial. La aplicación NSX Network Detection and Response utiliza el modelo Tácticas, técnicas y conocimientos comunes de adversario (ATT&CK™) de MITRE para describir los comportamientos de estos. En este modelo, las técnicas que podría utilizar un adversario se agrupan en una serie de categorías tácticas, que corresponden a diferentes etapas del ciclo de vida del ataque.

En el sistema, la actividad asociada con cada evento detectado puede asociarse a una etapa de ataque específica y podría proporcionar una indicación del progreso de la campaña a lo largo de su ciclo de vida. (Es posible que las actividades detectadas en diferentes fases de ataque no estén asociadas a una etapa de ataque específica). Actualmente, se utilizan las siguientes etapas de ataque.

Nombre de la etapa de ataque	Descripción
Distribución	La etapa en la que los atacantes envían la carga útil al destino. Entre los mecanismos de distribución más comunes se encuentran las vulnerabilidades remotas, las páginas web de descargas drive-by y las unidades USB u otras unidades extraíbles malintencionadas.
Explotación	La etapa en la que se implementa la carga útil del atacante en la red de destino. En consecuencia, uno o varios dispositivos de la red de destino están comprometidos y bajo el control del atacante.
Comando y control	La etapa en la que los atacantes se comunican con los sistemas que controlan dentro de la red de destino, lo que permite obtener acceso remoto "práctico al teclado" a estos sistemas.
Acceso de credenciales	La etapa en la que los atacantes obtienen acceso o control sobre las credenciales de sistema, dominio o servicio utilizadas en el entorno de destino. Por lo general, los atacantes intentan obtener credenciales legítimas de las cuentas de los usuarios y administradores para suplantarlos o crear nuevas cuentas.
Detección	La etapa en la que los atacantes intentan encontrar más información sobre el entorno de destino. Los atacantes suelen intentar identificar dispositivos adicionales en la red que puedan utilizar para sus objetivos.
Movimiento lateral	La etapa en la que los atacantes pasan por la red de destino al obtener acceso y control sobre los sistemas remotos.
Recopilación	La etapa en la que los atacantes identifican y recopilan información de una red de destino antes de la exfiltración.
Exfiltración	La etapa en la que los atacantes eliminan archivos e información de una red de destino.

Acerca de las reglas de correlación

En general, los incidentes se agrupan en una campaña cuando hay evidencia que indica que las actividades malintencionadas o los ataques correspondientes están relacionados.

Dado que estas reglas de correlación se ejecutan en el servicio de nube NSX Advanced Threat Prevention, pueden mejorarse o extenderse independientemente de los ciclos de versión de NSX. Además, la lista de reglas de correlación o el comportamiento específico de una regla pueden cambiar con el tiempo.

Las siguientes son las reglas de correlación admitidas actualmente.

Evento de anomalía

Esta regla correlaciona los eventos de detección de la función Tráfico sospechoso de NSX con eventos de tipo infección de impacto más alto. Por ejemplo, un evento de anomalía de la función Tráfico sospechoso de NSX coincide con un evento de red de alto impacto para los mismos hosts.

Exfiltración

Esta regla correlaciona los eventos de exfiltración que van precedidos por eventos de tipo infección. Por ejemplo, un evento de red de comando y control va seguido de un evento de red que sabemos que está exfiltrando datos.

Transferencia de archivos (basada en hash)

Esta regla correlaciona las transferencias de archivos malintencionadas. Por ejemplo, si se descarga el mismo archivo malintencionado en varios hosts de la red, la regla correlacionará todas estas transferencias en una intrusión. La similitud de las transferencias de archivos malintencionadas se determina en función del hash SHA-1 del archivo transferido.

Transferencia de archivos (basada en etiquetas de análisis)

Esta regla correlaciona las transferencias de archivos malintencionadas. Por ejemplo, si se descarga el mismo archivo malintencionado en varios hosts de la red, la regla correlacionará todas estas transferencias en una intrusión. La similitud de las transferencias de archivos malintencionadas se determina en función de las etiquetas asociadas a las tareas de análisis de los archivos.

Análisis de vulnerabilidad

Esta regla correlaciona diferentes tipos de eventos de red que potencialmente indican un análisis de vulnerabilidad. Por ejemplo, se observan varios eventos de tipo NTA o de tipo infección saliente desde un único host hacia uno o varios hosts de destino internos.

Olas

Este grupo de reglas identifica las "olas" de ataque, en las que se observa el mismo ataque (es decir, incidentes para la misma amenaza) en varios hosts de la red dentro de un período de tiempo determinado.

Este grupo de reglas es útil para identificar los hosts de la red que han pasado a formar parte de la misma infraestructura de comando y control o que han estado expuestos al mismo vector de ataque (por ejemplo, un ataque de tipo drive-by o un ataque de distribución de malware). Como resultado, estas reglas están restringidas a las amenazas de clase comando y control, drive-by, distribución de malware, sinkhole, falso AV y minería de criptomonedas.

Las reglas de este grupo se activan en los siguientes casos.

• Existen eventos de firma de red en los que la clase de amenaza es comando y control, lo que afecta a varios hosts.

• Existen eventos de firma de red en los que la clase de amenaza es distribución de malware, lo que afecta a varios hosts.

• Hay eventos de firma de red en los que la clase de amenaza es drive-by y la entrada (dirección IP o nombre de host) donde se produjeron las detecciones son la misma, lo que afecta a varios hosts.

• Hay eventos de reputación malintencionados para la misma entrada (dirección IP o nombre de host) y la clase de amenaza es comando y control, lo que afecta a varios hosts.

• Hay eventos de reputación malintencionados para la misma entrada (dirección IP o nombre de host) y la clase de amenaza es distribución de malware, lo que afecta a varios hosts.

En este caso, la ventana de correlación se establece en tres días. Por lo tanto, se consideran relacionados dos incidentes por la misma amenaza que afectan a diferentes hosts si se producen dentro de este intervalo de tiempo limitado.

Nota:

Estas reglas pueden crear campañas que incluyan solo un host y un incidente.

Drive-by confirmado

Este grupo de reglas identifica las campañas en las que un host interno está expuesto a un ataque de tipo drive-by con éxito. Se considera que un ataque drive-by a un host tiene éxito si va seguido de una actividad de comando y control, descarga de malware, sinkhole o falso AV. Las reglas de este grupo se activan en los siguientes casos.

• Un ataque drive-by seguido de cerca por actividad de descarga de malware: en este caso, la ventana de correlación es de 10 minutos, ya que esperamos que la descarga esté causada inmediatamente por una vulnerabilidad del navegador con éxito.

• Un ataque drive-by seguido de cerca por actividad de un falso AV: en este caso, la ventana de correlación es de 10 minutos, ya que esperamos que la actividad del falso AV siga inmediatamente a una vulnerabilidad drive-by.

• Un ataque drive-by seguido de actividad de comando y control: en este caso, la ventana de correlación es de cuatro horas, ya que el canal de comando y control puede tardar en configurarse.

• Un ataque drive-by seguido de actividad sinkhole: en este caso, la ventana de correlación es de cuatro horas, ya que la actividad hacia un servidor malintencionado con un sinkhole a través de un canal de comando y control puede tardar en configurarse.Esta regla correlaciona la actividad de movimiento lateral saliente de un host de la red de inicio y las infecciones en ese host que se produjeron antes de las detecciones de movimiento lateral (pero dentro de la ventana de correlación).

Nota:

Estas reglas pueden crear campañas que incluyan solo un host.

Descarga de archivo confirmada

Este grupo de reglas identifica las campañas en las que se descarga y ejecuta correctamente un archivo malintencionado en un host. Se considera que un archivo descargado se ejecutó correctamente en un host si, poco después de la descarga, hay eventos de red para las actividades que coinciden con la actividad observada durante el análisis del archivo.

En particular, el análisis de archivos puede proporcionar dos partes más de información para caracterizar la actividad observada durante el análisis.

Información de malware

Si el comportamiento del archivo coincide con el comportamiento de una amenaza conocida, el nombre del malware pasará a estar disponible.

Información de IoC de red

Si durante el análisis la muestra genera un tráfico de red que coincide con las firmas de red o la inteligencia de amenazas, se pondrán a disposición los indicadores del tráfico. Es decir, se proporcionará información sobre reputación malintencionada y coincidencias de firma de red.

Las reglas de este grupo se activan en los siguientes dos casos, según el tipo de información derivada del análisis de archivos.

• Caso basado en malware

  • Se descarga un archivo en un host.

  • El análisis del archivo atribuye una amenaza específica al archivo (por ejemplo, el malware Emotet).

  • Más tarde, se detecta un evento de red para la misma amenaza (es decir, Emotet) para el host que descargó el archivo.

• Caso basado en IoC de red

  • Se descarga un archivo en un host.

  • El análisis del archivos identifica IoC de red para el archivo.

  • Más tarde, el host que descargó el archivo intenta contactar con una dirección IP o un nombre de host incluidos en el IoC de reputación malintencionada extraído para el archivo y este tráfico coincide con una firma de red.

La aplicación NSX Network Detection and Response establece la ventana de correlación en este caso en tres días.

Nota:

Esta regla puede crear campañas que incluyan solo un host.

Movimiento lateral

Este grupo de reglas identifica campañas en las que los atacantes han establecido una "cabeza de playa" en la red comprometiendo algunos hosts y luego intentan moverse lateralmente dentro de la red para comprometer hosts adicionales.

Este grupo consta de dos reglas, cada una de las cuales detecta un paso independiente de la campaña de movimiento lateral.

Movimiento lateral saliente

Esta regla correlaciona la actividad de movimiento lateral saliente de un host de la red local y las infecciones en ese host que se produjeron antes de las detecciones de movimiento laterales (pero dentro de la ventana de correlación).

Movimiento lateral entrante

Esta regla correlaciona la actividad de movimiento lateral entrante con un host de la red de inicio configurada y la actividad comúnmente observada después de un compromiso inicial (comando y control, sondeo y recopilación de credenciales) que ocurrió en el mismo host después de las detecciones de movimiento lateral.Por ejemplo, el uso del protocolo de escritorio remoto (RDP) puede ser normal en un entorno en el que esta herramienta se utiliza para fines administrativos legítimos, pero en otras situaciones puede ser un indicio muy sospechoso de que un atacante podría estar intentando controlar de forma remota un host.

Tenga en cuenta que estas reglas solo se activarán para los hosts dentro de la red de inicio, es decir, que la campaña se crea solo si los hosts de origen y destino de las actividades de movimiento lateral pertenecen a la red de inicio. Si la red de inicio no está configurada, el sistema utilizará rangos de RFC1918 de forma predeterminada.

Promoción de eventos INFO

La aplicación NSX Network Detection and Response detecta varias actividades en una red protegida que podrían ser interesantes para un analista, pero que probablemente no sean malintencionadas. Estas detecciones generan eventos INFO, que se pueden ver estableciendo un valor adecuado para el filtro "resultado de evento".

La aplicación NSX Network Detection and Response no tiene en cuenta los eventos INFO para fines de correlación.

Un desafío con estas detecciones es que la misma actividad de evento INFO puede ser normal o altamente sospechosa, en función de la red en la que la detectó la aplicación NSX Network Detection and Response. Por ejemplo, el uso del protocolo de escritorio remoto (RDP) puede ser normal en un entorno en el que esta herramienta se utiliza para fines administrativos legítimos, pero puede ser un indicio muy sospechoso de que un atacante podría estar intentando controlar de forma remota un host.

La lógica de detección de anomalías es capaz de determinar cuándo ciertos tipos de detecciones de INFO son inusuales para la red supervisada y para los hosts de origen y destino específicos involucrados. Cuando el sistema determina que una detección de INFO es inusual, el evento pasa al modo de "detección" y, como consecuencia, se muestra entre los eventos normales. Este escenario es relevante en el contexto de las reglas de correlación para el movimiento lateral, ya que la detección de la actividad de movimiento lateral a menudo provoca la creación de eventos INFO.

Red de inicio

La configuración de red de inicio tiene el siguiente efecto en las reglas de correlación de campañas.

• Todas las reglas de correlación de campañas ignoran los eventos que se produjeron en hosts fuera de la red de inicio.

• Si no hay ninguna red de inicio configurada, el sistema establecerá de forma predeterminada los rangos de RFC1918.

La red de inicio se configura en Seguridad > Configuración general > Rangos de IP privados.

Silenciamiento de hosts

La configuración de silenciamiento de hosts tiene el siguiente efecto en las reglas de correlación de campañas.

• Si se configura el silenciamiento de hosts, todas las reglas de correlación de campañas ignorarán los eventos que se produjeron en los hosts silenciados.

• Si no se configura ningún silenciamiento de hosts, todos los hosts de origen detectados en un evento se considerarán válidos para la correlación.

Para asegurarse de que el silenciamiento de hosts no incluya por error hosts cuya actividad debe incluirse en campañas, debe comprobar esta configuración.

Acerca de la evidencia

La aplicación NSX Network Detection and Response informa sobre las acciones observadas al analizar un evento, un incidente o una campaña.

La evidencia contiene la siguiente información.

Evidencia de detección básica: red

Tipo de evidencia REPUTATION

Indica que se detectó tráfico de red a una IP o un dominio que están asociados a una amenaza conocida.

Se mostrará un campo SUBJECT y una dirección IP o un dominio. Por ejemplo: reputation: evil.com (evento de referencia), 6.6.6.6 (evento de referencia) o bad.org (evento de referencia).

Por lo general, estos dominios y direcciones IP malintencionados se bloquean. Si está disponible, se mostrará información de reputación adicional.

Las direcciones IP pueden anotarse con una ubicación (marca de país).

Tipo de evidencia SIGNATURE

Indica que se detectó tráfico de red que coincide con una firma de red para una amenaza conocida.

Se muestra un campo Detector que es el nombre/identificador único de la firma con la que se encontró una coincidencia. Por ejemplo, Detector: et:2014612 o Detector: llrules:1490720342088.

Tipo de evidencia ANOMALY

Similar a SIGNATURE, con la diferencia de que la detección se basa en una heurística que detecta algo anómalo. Por ejemplo, Anomaly: anomaly:download_smb.

Tipo de evidencia FILE DOWNLOAD

Se descargó un archivo sospechoso o malintencionado.

Se muestra task_uuid, el identificador de un análisis (detonación en espacio aislado) y severity, la puntuación de dicho análisis. Por ejemplo, File download: a7ed621.

A continuación se muestra información opcional adicional del evento de referencia.

• La URL desde la que se descargó el archivo

• El tipo de archivo (normalmente ejecutable)

• El nombre del archivo

Tipo de evidencia UNUSUAL_PORT

Indica que se está utilizando un puerto TCP o UDP poco común y que corresponde a lo que se espera de esta amenaza específica.

La dirección IP o el dominio implicados en el tráfico que utilizó el puerto inusual se muestran en el campo SUBJECT.

Tipo de evidencia URL_PATH_MATCH

Similar a UNUSUAL_PORT, con la diferencia de que la detección se basa en una ruta de URL. Por ejemplo, http://evil.com/evil/path?evil=threat, la detección se activa con la parte /evil/path de la URL.

Tipo de evidencia DGA

DGA hace referencia a "algoritmo de generación de dominios", un enfoque utilizado por algunos tipos de malware, donde en lugar de utilizar una pequeña cantidad de dominios para comando y control, el malware incluye un algoritmo que genera miles de nuevos dominios aleatorios cada día. A continuación, intenta ponerse en contacto con cada uno de ellos. Para controlar su malware, el grupo solo registra uno o varios de estos dominios. El uso de DGA es muy visible en la red debido a los intentos de resolución de muchos de estos dominios.

La evidencia DGA se utiliza actualmente, además de la evidencia de reputación regular, cuando se detectan varios dominios malintencionados de un algoritmo DGA que se está resolviendo.

Evidencia de la correlación de varios eventos

Evidencia de la correlación de varios eventos

Los siguientes tipos de evidencia se crean en los casos en los que la combinación de varios eventos de red en un host aumenta la confianza en que se detectó una amenaza correctamente. Los tipos de evidencias pueden ser, por ejemplo, que se contacte con la misma entrada de reputación maliciosa o que se active la misma firma de red.

En cada uno de estos casos, la amenaza puede etiquetarse de la siguiente manera.

• Repeated: la amenaza específica se ha detectado tres o más veces.

• Periodic: también se detectó que la amenaza específica se producía a intervalos regulares.

Se muestra una etiqueta en la evidencia de REPUTATION/SIGNATURE correspondiente.

En el ejemplo de la evidencia REPUTATION, si se detectan evidencias repetidas y periódicas de bad.org, se mostrará una etiqueta REPEATED o PERIODIC.

Tipo de evidencia CONFIRMED_EXECUTION

Está asociada a amenazas como MALICIOUS FILE DOWNLOAD. Significa que se detecta un comportamiento en la red desde el host que descargó el archivo que confirma que el archivo descargado se ejecutó realmente.

Por ejemplo:

• Se descargó un archivo malintencionado en el host 1.2.3.4.

• Cuando se ejecuta en un espacio aislado, este archivo se pone en contacto con el host evil.com.

• Poco después, se observa el tráfico de comando y control desde el host 1.2.3.4 hacia evil.com, lo que confirma que se ejecutó el archivo malintencionado.

El evento de referencia vinculado es donde se descargó el archivo.

La evidencia adicional puede proporcionar confirmación de la amenaza, como la siguiente información sobre el archivo.

• UUID de tarea

• Puntuación

• Nombre de archivo

• URL desde la que se descargó

Tipo de evidencia CONFIRMED_C&C

De forma similar a CONFIRMED_EXECUTION, esta evidencia se agrega a la detección de comando y control para la amenaza especificada debido a que el host descargó previamente un archivo para esa amenaza.

Tipo de evidencia CONFIRMED_DRIVE_BY

Se agrega en situaciones en las que se detectó un ataque de tipo drive-by seguido de una indicación de que el ataque se realizó con éxito. Por ejemplo:

• El host 1.2.3.4 parece ser víctima de un ataque de tipo drive-by.

• Poco después, el host 1.2.3.4:

  • Descargó un archivo malintencionado

  • Generó tráfico de comando y control

Esta evidencia se agrega a un evento de referencia del evento drive-by inicial.

Tipo de evidencia DRIVEBY_CONFIRMATION

De forma similar a la evidencia CONFIRMED_DRIVEBY, esta evidencia se agrega como evento de referencia a las detecciones de descarga de archivos malintencionados o comando y control que se produjeron poco después de un ataque drive-by.