Exportación de datos de la pila de amenazas para análisis personalizados
Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Comience a utilizar Distributed Cloud AIP con su equipo hoy mismo .
¿Este host ha sido comprometido? ¿Este anfitrión siempre hacía esto?
Cualquiera que haya trabajado en operaciones, ingeniería o seguridad ha tenido en algún momento un servidor o servidores que mostraban un comportamiento inesperado. Podría estar ejecutando procesos extraños, consumiendo más memoria de lo esperado, aceptando solicitudes, estableciendo conexiones a GitHub, lo que sea.
El primer paso para clasificar un evento es saber que tienes uno. Hay varias fuentes de datos que potencialmente pueden indicarle un servidor host en particular:
- Herramientas de monitoreo que miden cosas como el espacio en disco y memoria
- Sistemas de detección de intrusiones de seguridad que generan alertas
- Registros de aplicação que muestran fallas al comunicarse con hosts específicos
En este punto, hay algún servidor al que queremos ir y obtener más información. Suponiendo que no todos los datos del sistema encajan necesariamente en nuestro SIEM, el siguiente paso lógico es conectarse al host y comenzar a consultar directamente al sistema operativo sobre lo que está haciendo. Dependiendo de su nivel de familiaridad con el entorno, esto puede ser tan amplio como herramientas como uname y vmstat hasta elementos más específicos como ps y lsof. En cualquier caso, se le mostrará lo que está haciendo actualmente el host. Aquí está el problema con este proceso: En realidad no te importa el estado actual; quieres saber qué cambió. Al igual que cuando se obtiene una solicitud de extracción en Git, no desea revisar toda la base del código, solo las partes que se han modificado.
Portabilidad de datos a Amazon S3
Aquí, en el programa Threat Stack Cloud SecOps Program℠, los analistas de seguridad de nuestro SOC han desarrollado una solución para ayudarnos a responder este tipo de preguntas para nuestros clientes. La plataforma de seguridad en la nube Threat Stack® tiene esta ingeniosa característica que llamamos portabilidad de datos. A un alto nivel, esto nos permite tomar la telemetría que recopilamos de los hosts, incluidos elementos como ejecutables en ejecución, usuarios, argumentos de línea de comandos, conexiones, etc., y almacenarlos en depósitos S3.
Lo bueno de los blobs S3 es que son una forma económica de almacenar grandes cantidades de datos. Lo que sí es un problema es aprovechar una gran cantidad de datos no indexados. Con ese fin, terminamos usando Amazon EMR para crear notebooks Jupyter PySpark para usar Apache Spark DataFrames y Python pandas DataFrames para crear una herramienta poderosa para comparar el estado actual de una máquina con cualquier estado anterior que tengamos en retención.
ETL (el favorito de todos)
Aquí hay un par de notas antes de mirar nuestros ejemplos de código. Las tablas y referencias de esquema se almacenan en AWS Glue y coinciden con el formato de eventos sin procesar de Threat Stack para sistemas Linux . Puede agregar estos datos a su base de datos existente. Luego, hay una configuración definida para el clúster Spark que le indica que lea desde Glue para saber qué tablas y columnas están disponibles. Luego, cuando se crea un clúster, puedes hacer referencia a la tabla dentro del cuaderno de JupyterLab.
Nota: El siguiente código es totalmente real; la situación es artificial. En algún momento del Día de San Valentín se le pidió a un analista de seguridad que comprometiera un host con nuestro agente ejecutándose en él. El objetivo era averiguar qué se hizo.
Entremos en el código
Lo primero que necesitamos crear son nuestra SparkSession y SparkContext. Afortunadamente, cuando usamos un notebook de PySpark, estos se instancian automáticamente cuando ejecutamos nuestra primera celda.
Configurando nuestro notebook PySpark.
Obtuvimos un objeto spark al que haremos referencia más adelante, y también obtuvimos sc, que es nuestro contexto spark. Luego podemos usar eso para cargar en pandas y Matplotlib .
Instalación de paquetes.
En este próximo paso, confirmaré los nombres de las columnas creando un spark.table() basado en las tablas Glue y luego mostraré mi esquema heredado.
Leyendo la estructura de nuestras columnas cargadas desde AWS Glue.
Genial, ahora puedo ver qué columnas y tipos tengo disponibles para comenzar a ejecutar mis consultas SQL. Ahora puedo tomar cualquier servidor y cualquier rango de tiempo que quiera y compararlos. Aquí, estoy creando dos Spark DataFrames, recopilando los datos que necesitaré para realizar la investigación previa al incidente y el análisis forense posterior al incidente:
SELECCIONAR fecha_clave, marca de tiempo, tsEventType, llamada al sistema, conexión, usuario, comando, exe, argumentos DE compact.audit_v4 DONDE fecha_clave >= '2020-02-05-00' Y fecha_clave < '2020-02-14-00' Y id_organización = '5a8c4a54e11909bd290021ed' Y id_agente = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' AGRUPAR POR fecha_clave, marca de tiempo, tsEventType, llamada al sistema, conexión, usuario, comando, exe, argumentos SELECCIONAR fecha_clave, marca de tiempo, tsEventType, llamada al sistema, conexión, usuario, comando, exe, argumentos DE compact.audit_v4 DONDE fecha_clave >= '2020-02-14-00' Y clave_de_fecha < '2020-02-17-00' Y id_de_organización = '5a8c4a54e11909bd290021ed' Y id_de_agente = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' AGRUPACIÓN POR clave_de_fecha, marca_de_tiempo, tipo_de_evento_ts, llamada_del_sistema, conexión, usuario, comando, exe, argumentos
Agrupando los datos en torno a nuestra fecha de compromiso del 14 de febrero. (Algunas celdas del cuaderno se muestran aquí como Gists de GitHub para facilitar su lectura).
Ahora, una rápida comprobación de la cantidad de datos que he recopilado:
Contar la cantidad de registros en ambos Spark DataFrames para garantizar una cantidad razonable para la investigación.
Eso parece correcto. Tengo un rango de tiempo mucho más grande para mi preCompromiseDf versus mi postCompromiseDf . (El “Df” sirve para ayudarme a recordar que estos son objetos Spark DataFrame, simplemente una convención de nomenclatura).
Los DataFrames de Apache Spark son útiles porque almacenan el DataFrame completo en todo el clúster. Esto es genial para conjuntos de datos masivos, pero en este caso, en realidad tengo una cantidad relativamente pequeña de registros que quiero comparar. Para ese fin, ejecuto toPandas() para mover esos datos a la memoria de mi computadora portátil, lo que permitirá un cálculo más rápido.
Como no estamos tratando con “big data”, en este caso es más rápido ejecutar el resto de nuestro análisis localmente.
Comenzando nuestro análisis
Ahora puedo empezar a hacer cosas potentes, como comprobar cuáles son los nuevos ejecutables que se están ejecutando en este servidor desde la medianoche del 14 de febrero.
/tmp/EXCITADO MIENTRAS /usr/bin/wget /tmp/FRONTAL /tmp/PEINE INUSUAL /tmp/BLOQUEO ENTORNO /tmp/nmap /usr/bin/scp /tmp/astilla /tmp/astilla2 /tmp/PULGAR ORGULLOSO
Una lista de ejecutables que se ejecutan en el servidor durante la noche en cuestión.
Bueno, hola a todos, algunos nombres de ejecutables en mayúsculas al azar: nmap, scp, wget y algo llamado sliver. Una pequeña búsqueda en Google revela que es muy probable que Sliver esté asociado con https://github.com/BishopFox/sliver y que sea un marco de implante que admite comando y control sobre múltiples protocolos.
Tengo la prueba que necesito de que mi servidor ha sido comprometido, pero quiero hacer mi debida diligencia y ver qué se hizo realmente con estos ejecutables. Al usar mi lista como filtro contra el mismo DataFrame, puedo extraer otros detalles e indicadores de compromiso (IoC):
argumentos del exe 80 /tmp/EXCITED_WHILE ./EXCITED_WHILE 162 /usr/bin/wget wget https://github.com/andrew-d/static-binari... 255 /tmp/EXCITADO_MIENTRAS ./EXCITADO_MIENTRAS 256 /tmp/FRONT_RUN ./FRONT_RUN 359 /tmp/INUSUAL_COMB ./INUSUAL_COMB 360 /tmp/BLOQUEO_ENTORNO ./BLOQUEO_ENTORNO 464 /tmp/nmap 494 /tmp/BLOQUEO_ENTORNO ./BLOQUEO_ENTORNO 533 /tmp/EXCITADO_MIENTRAS ./EXCITADO_MIENTRAS 589 /tmp/FRONT_RUN ./FRONT_RUN 603 /tmp/EXCITADO_MIENTRAS ./EXCITADO_MIENTRAS 658 /tmp/EXCITADO_MIENTRAS ./EXCITADO_MIENTRAS 660 /tmp/FRONT_RUN ./FRONT_RUN 671 /usr/bin/scp scp -t /tmp/ 699 /tmp/BLOQUEO_ENVOLVENTE ./BLOQUEO_ENVOLVENTE 738 /tmp/PEINE_INUSUAL ./PEINE_INUSUAL 762 /tmp/astilla ./astilla 816 /tmp/BLOQUEO_ENVOLVENTE ./BLOQUEO_ENVOLVENTE 834 /tmp/astilla2 ./astilla2 878 /tmp/nmap /tmp/nmap 909 /tmp/MIENTRAS_EXITADO ./MIENTRAS_EXITADO 937 /tmp/FRONTAL ./FRONTAL 992 /tmp/FRONTAL ./FRONTAL 1023 /tmp/FRONTAL 1040 /usr/bin/scp scp -t /tmp/ ...
Extrayendo cualquier argumento relacionado asociado con mi lista de ejecutables sospechosos.
Entonces, se usó scp para mover archivos, wget extrajo algo de código de GitHub (ir a esa fila me muestra cómo fue que nmap llegó al sistema) y los detalles de la ejecución de esos otros archivos están contenidos dentro del archivo mismo, ya que no recibieron argumentos de línea de comando. En este punto tiene sentido tomar una instantánea del host como evidencia y finalizar la instancia.
El paso final es confirmar que ningún otro host del entorno se haya visto comprometido. Para esto, tomaremos algunos elementos de nuestra lista de IoC anterior y los verificaremos en todos los servidores.
SELECCIONAR clave_de_fecha, marca_de_tiempo, tipo_de_evento_ts, llamada_del_sistema, conexión, usuario, comando, exe, argumentos, Id_de_agente, tty, sesión, cwd DE compact.audit_v4 DONDE clave_de_fecha >= '2020-01-01' Y clave_de_fecha <= '2020-02-29' Y id_de_organización = '5a8c4a54e11909bd290021ed' Y tipo_de_evento_ts = 'audit' Y llamada_del_sistema = 'execve' AGRUPAR POR clave_de_fecha, marca_de_tiempo, tipo_de_evento_ts, llamada_del_sistema, conexión, usuario, comando, exe, argumentos, Id_de_agente, tty, sesión, cwd
52
Esa consulta devuelve 52 resultados en todo el entorno para actividad sospechosa de nmap y sliver. Podemos limitar aún más esta vista moviéndonos a un DataFrame de pandas y agrupando los resultados por cada servidor:
Introducción a su propio análisis de Threat Stack
Gracias por acompañarme a través de este post. Estoy muy entusiasmado por las posibilidades que brindan estos datos y por encontrar nuevas formas de explorarlos. Si actualmente utiliza la plataforma Threat Stack, puede configurar su propia portabilidad de datos utilizando esta documentación como guía. El beneficio es que usted puede decidir el nivel correcto de datos a conservar para las necesidades de su propio negocio.
Para las personas que aprovechan nuestro servicio Threat Stack Oversight℠, tenemos 30 días de datos de eventos y estaremos encantados de trabajar con usted para brindar un análisis forense más profundo de su entorno aprovechando este conjunto de herramientas en caso de que no tenga un lago de datos.
El próximo paso para el equipo de Operaciones de Seguridad de Threat Stack es comenzar a buscar incorporar más gráficos y tablas para ayudar a analizar los datos visualmente como parte de nuestro próximo análisis utilizando cuadernos de ciencia de datos. Habrá más información al respecto, pero aquí hay un primer paso hacia algunas IP geolocalizadas (la densidad de cada círculo indica la cantidad de conexiones).
¡Pronto habrá más visualizaciones analíticas del equipo de Threat Stack Security!
Threat Stack ahora es F5 Distributed Cloud App Infrastructure Protection (AIP). Comience a utilizar Distributed Cloud AIP con su equipo hoy mismo .