Detección innovadora de inyección de procesos mediante las anomalías de red

Resumen ejecutivo

• Los investigadores de Akamai han creado una nueva técnica para detectar la inyección de procesos mediante el análisis de las anomalías en la red.

• Los mecanismos de detección actuales dependen de factores basados en host que pueden ser omitidos por las nuevas técnicas de ataque, lo que hace que sea necesaria una nueva forma de identificar las amenazas.

• A medida que evolucionan estas técnicas de ataque, también deben hacerlo los mecanismos de defensa, con el menor número posible de falsos positivos.

• Un ataque de inyección de procesos efectivo puede provocar numerosos resultados adversos, que incluyen el movimiento lateral, la derivación de privilegios y la instalación de puertas traseras.

• Nuestra metodología de detección se basa en la observación del comportamiento en red de un proceso, lo que hace más difícil que una amenaza quede sin detectar.

• Puede consultar un ejemplo de esta metodología en acción tomado de un incidente real que, según se descubrió, tenía vínculos con la campaña de cryptojacking WannaMine.

Introducción

La inyección de procesos se utiliza en casi todas las operaciones de ataque. Los atacantes siguen encontrando formas de manipular las soluciones de seguridad; por ejemplo, ocultando y ejecutando una carga útil dentro de un proceso ya activo.

Las técnicas de inyección se encuentran entre las amenazas que han evolucionado de forma más significativa a lo largo de los años. Estas sofisticadas técnicas de solo memoria están sustituyendo rápidamente a las técnicas de inyección tradicionales, que pueden ser detectadas fácilmente por las soluciones de seguridad modernas, como la detección y respuesta de terminales (EDR).

Independientemente del objetivo del atacante, una inyección efectiva dará paso a intentos de moverse lateralmente, realizar un análisis de la red o instalar un listener que sirva de puerta trasera. De este modo, comienza el juego del gato y el ratón: un atacante encuentra un nuevo vector de ataque, los proveedores de seguridad actualizan su detección, etc.

Estas nuevas técnicas de detección se introducen mensualmente, lo que significa que la tecnología EDR tiene que actualizar sus detecciones con una cantidad mínima de falsos positivos. Teniendo en cuenta el nivel de riesgo que comporta una inyección efectiva, tuvimos que preguntarnos: "¿Qué podemos hacer de manera diferente?»

La mayoría de los mecanismos de detección implican técnicas como el seguimiento de las llamadas de API, los cambios en los indicadores de protección de la memoria, las asignaciones y otros artefactos basados en host. Sin embargo, sabemos que estos mecanismos se pueden manipular mediante nuevas técnicas y amenazas. Estas nuevas técnicas de inyección, ligadas a métodos de omisión de herramientas de detección y respuesta de terminales (EDR), no se detectan ni bloquean de forma sistemática. Esto implica que, como investigadores de amenazas, no podemos depender únicamente de una solución antivirus (AV) o EDR para mitigar estos ataques basados en host, y que necesitamos una forma eficaz de detectar los ataques exitosos.

En esta entrada del blog, presentaremos una técnica de detección de inyección de procesos desarrollada por el equipo de Akamai Hunt que utiliza la detección de anomalías en la red, en lugar de los artefactos basados en host indicados anteriormente. Nuestra técnica se centra en el comportamiento del proceso en la red, lo cual es mucho más difícil de ocultar que los artefactos del host, como las llamadas a API o los cambios en el sistema de archivos. Empleamos esta técnica, entre muchas otras, para detectar malware, movimiento lateral, exfiltración de datos y otros tipos de ataque en las redes de nuestros clientes.

Nuestro sistema de detección consta de tres pasos principales:

1. Categorizar la comunicación de procesos en grupos de puertos

2. Crear un estándar de periodo temporal variable para la comunicación de procesos normales

3. Comparar los nuevos datos del proceso con el estándar

Si lo desea, no dude en pedir a su equipo de seguridad que implemente la lógica que se describe en esta publicación. Aunque no disponga de la gran cantidad de datos que tenemos en Akamai Hunt, podrá obtener resultados interesantes con sus propios datos.

¿Cómo se comunica un proceso?

Es fácil asumir que las comunicaciones de procesos son uniformes; es decir, que los mismos procesos de diferentes redes tienen los mismos patrones de comunicación. Aunque esto es así para algunos procesos, es completamente falso para otros. Suponemos que los procesos nativos del sistema operativo se comportan de forma similar, comunicándose con dominios similares y utilizando los mismos protocolos de red, pero hay muchas variables que afectan a esta suposición: Las compilaciones del sistema operativo, las regiones, los servidores proxy y otras configuraciones específicas de la red pueden afectar a sus destinos de comunicación y al protocolo de red utilizado (Figura 1).

En estos datos recopilados de Akamai Guardicore Segmentation, podemos ver la incoherencia del uso de puertos en acción. Esto en sí puede dificultar bastante la detección, por lo que el siguiente paso fue encontrar una forma de estudiar los datos con un formato que podamos analizar. Introducir grupos de puertos.

Clasificación de la comunicación de procesos mediante grupos de puertos

En nuestra investigación, descubrimos que al agrupar puertos similares y asociarlos a aplicaciones específicas, podemos proporcionar contexto para el algoritmo de detección y encontrar patrones de comunicación de forma más sencilla. Esto nos ayuda a detectar anomalías en los patrones de comunicación.

Por ejemplo, supongamos que observamos un proceso específico que se comunica utilizando los puertos 636 y 389 en una red, y los puertos 3268 y 3269 en otra. Dado que todos ellos forman parte del protocolo ligero de acceso a directorios (LDAP), podemos clasificarlos como un grupo de puertos: comunicación LDAP.

Funciona para la mayoría de las aplicaciones, pero intentar clasificar el intervalo de puertos válidos completo no es sencillo. Muchos puertos se utilizan en más de una aplicación, lo que puede provocar que los procesos se clasifiquen de forma incorrecta cuando utilizan puertos compartidos con otro software. Esto nos llevó a limitar las clasificaciones de puertos solo a los que se usan principalmente para un tipo de aplicación, dejando el intervalo de puertos alto como un grupo de puertos.

La asignación completa de puertos se puede consultar en el Apéndice A.

¿Cuántos datos son suficientes para sacar conclusiones?

Supongamos que observa que un proceso específico se ejecuta en siete equipos realizando todas las conexiones mediante HTTPS a un servidor web específico. ¿Podría deducir que el mismo proceso nunca utilizaría otra forma de comunicación? Seguramente, no.

Para decidir qué cantidad de datos por proceso son suficientes, tomamos cada par de grupos de procesos y puertos, y contamos el número de redes en las que lo hemos visto.

Para empezar, solo tenemos en cuenta los procesos detectados en tres o más redes de clientes. Si un proceso apareciera en menos de tres redes (de los cientos de redes que tenemos en nuestro conjunto de datos), sería difícil tomar decisiones seguras sobre su perfil de red.

A continuación, determinamos el nivel de estabilidad de un proceso según las diferencias en el comportamiento en red entre los diferentes clientes. Si un proceso se comunica utilizando los mismos grupos de puertos en todos los clientes en los que se ha observado, se considerará estable. Si un proceso se comunica de forma completamente diferente en cada red de cliente, se considerará inestable.

Hemos agregado, además, los niveles de estabilidad de los 12 mejores, los 25 mejores y los 100 mejores, que solo tienen en cuenta los puertos entre los 12, 25 y 100 más populares. También hemos incluido un nivel semiestable, que ignora el rango de puertos alto (números de puerto por encima de 49151).

Respaldo y confianza

Si trabaja con datos extraídos de una sola red, puede obtener respaldo y confianza del mundo de la minería de datos, lo que ayuda a evaluar la solidez y la relevancia de los datos dentro de un conjunto de datos.

El respaldo mide la frecuencia de un conjunto de elementos en el conjunto de datos; la confianza mide la fiabilidad de la relación entre dos conjuntos de elementos de una regla de asociación. En nuestro caso:

Respaldo(proceso) = (Número de puntos de datos que contienen el proceso) / (Número total de puntos de datos)

Respaldo(proceso –> grupo de puertos) = (Número de puntos de datos en los que un proceso se comunicó en un grupo de puertos específico) / (Número total de puntos de datos que contienen el proceso)

Un punto de datos sería una matriz diferenciada de: [Host, proceso, grupo de puertos]

Establecemos un valor de umbral para el respaldo mínimo que debe tener un proceso, junto con una confianza mínima que un grupo de puertos debe tener para que se considere parte del estándar. Este es también el paso 1 del algoritmo Apriori, un algoritmo popular que se utiliza para encontrar patrones en grandes conjuntos de datos. Después de la evaluación, decidimos los valores que ofrecen resultados interesantes junto con una baja relación señal-ruido.

Crear un estándar de periodo temporal variable

Nuestra técnica de detección se basa en comparar cada comunicación de proceso con su estándar de comportamiento anterior.

Para ello, comparamos todas las comunicaciones de procesos producidas en un día específico con un estándar basado en los datos del mes anterior (Figura 2).

Esto nos ayuda a adaptarnos a las tendencias de las redes de los clientes, ya que al día siguiente se tienen en cuenta los cambios en la red, las implementaciones de sistemas y las herramientas observadas por primera vez.

Resolver falsos positivos comunes

Algunos ajustes de la aplicación pueden cambiar el perfil de red de un proceso. Si un determinado ajuste de aplicación se modifica de una dirección IP a un nombre de host, comenzará a generar tráfico DNS. Lo mismo ocurre con el uso de servidores proxy internos, donde en cada red se puede emplear un puerto diferente para el mismo propósito. Otros puertos de destino tienden a generar menos falsos positivos y se pueden incluir en la lista de permitidos por cliente para mantener intacta la lógica original.

Para reducir el número de estos falsos positivos, cada alerta generada se examinará utilizando la siguiente lógica:

Si el puerto anómalo de un proceso es el puerto DNS/proxy:

1. Se extrae la IP de destino

2. Se comprueba cuántos activos se han puesto en contacto con la misma IP de destino en el mismo puerto durante el mes anterior

3. Si ese número es superior al 20 % del número de hosts de red, se marca la alerta como falso positivo
   

Esta lógica ayuda a gestionar la configuración específica de la red para los dos tipos de comunicación más ruidosos: la comunicación DNS y proxy.

Detección de amenazas reales: Ejemplo de ataque de un cliente de Hunt

Utilizando nuestro nuevo método para un cliente de Hunt, detectamos cinco procesos que se desviaban de su estándar de comunicación respectivo. Estos cinco ejecutables nativos del sistema, que utilizan un patrón de comunicación muy específico de puertos relacionados con la web, comenzaron a comunicarse con otros activos de la red mediante el protocolo Server Message Block (SMB) (Figura 3).

Al observar los estándares de los procesos, podemos ver que ninguno de ellos debería iniciar ninguna comunicación SMB (Figura 4).

Durante la investigación de la alerta, detectamos que el archivo C:\Windows\NetworkDistribution\svchost.exe se ejecutaba en dos hosts y, en uno de ellos, también se encontró un archivo llamado

C:\Windows\System32\dllhostex.exe.

En otro equipo, encontramos un script malicioso interesante (Figura 5).

Fig. 6: Comparación de este ataque con ataques anteriores

Todos nuestros hallazgos se comunicaron puntualmente al cliente, junto con los pasos de corrección y las recomendaciones de política de red.

Conclusión

En el panorama de amenazas y técnicas de ataque, es muy necesario contar con metodologías de detección precisas. Cada red es un ecosistema diferente con desafíos únicos, lo que dificulta la "estandarización" de la detección. Muchas organizaciones han intentado detectar ataques y no lo han conseguido, ya sea porque un atacante ha utilizado una nueva técnica o porque las herramientas de detección eran en sí demasiado complejas.

Al centrarnos en los patrones de comunicación de un proceso, podemos mejorar las técnicas de detección tradicionales desde un ángulo completamente diferente. Al combinar este análisis de patrones con nuestro conjunto de datos masivo, pudimos crear y utilizar esta metodología para detectar de forma eficiente anomalías en la red del proceso y, de ese modo, encontrar a los atacantes en las redes de los clientes.

Akamai Guardicore Segmentation y el servicio Akamai Hunt pueden bloquear la propagación de intentos de ransomware y movimiento lateral, que se complementa con un servicio de detección que le avisa cada vez que se produce un ataque.