scieee AI-readable full text Open interactive document viewer

Alerta temprana de amenazas de seguridad con Apache Kafka y la pila ELK

Páez Olmedo, Yeray Manuel

Abstract

Grado en Ingeniería Informática

Full text

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Tecnolog´ ıas de la informaci´ on Alerta Temprana de Amenazas de Seguridad con Apache Kafka y la Pila ELK Autor: Yeray Manuel P´ aez Olmedo Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Menci´ on en Tecnolog´ ıas de la informaci´ on Alerta Temprana de Amenazas de Seguridad con Apache Kafka y la Pila ELK Autor: Yeray Manuel P´ aez Olmedo Tutor: Blas Torregrosa Garcia Resumen Las amenazas persistentes avanzadas son ataques que se suelen realizar contra grandes organizaciones. Estos ataques utilizan t´ecnicas avanzadas para extraer informaci´on y permanecer sin ser detectados. Su detecci´on es compleja, porque se suele crear un malware nuevo para cada ataque. No podemos fiarnos de que un antivirus convencional sea capaz de detectarlas. Una forma de detectar la presencia de amenazas persistentes avanzadas consiste en la monitorizaci´on de equipos. Analizando los eventos que suceden en un equipo se puede detectar el uso de t´ecnicas de ataque. En este documento se describen var´ıas t´ecnicas de ataque, y se ha creado un sistema capaz de detectarlas, bas´andose en un registro de eventos. El sistema se puede separar en tres partes. En primer lugar, tenemos un controlador de dominio Active Directory, configurado para que se instalen de forma autom´atica varias herramientas de monitorizaci´on, en todos los equipos de una organizaci´on. El segundo componente es Apache Kafka, que se utiliza para recopilar los eventos de todos los equipos. El tercer componente es la pila ELK, que se encarga de leer los eventos de Kafka, analizarlos, y mostrar en un panel de mando varios indicadores de actividad maliciosa. Finalmente, se ha hecho una simulaci´on de un ataque, y se ha comprobado como el sistema es capaz de detectar las t´ecnicas utilizadas. Queda demostrada la efectividad de el an´alisis de eventos en la detecci´on de amenazas persistentes avanzadas. La utilizaci´on de un sistema similar al descrito mejorar´ıa la seguridad inform´atica de una organizaci´on. Tabla de Contenidos 1 Introducci´on 1 1.1 Contexto ............................................. 1 1.2 Objetivos ............................................. 1 2 Planificaci´on 3 2.1 Preparareldominio ....................................... 4 2.2 Estudioinicial........................................... 5 2.3 Configuraci´on del laboratorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Simulaci´ondeunataque..................................... 7 2.5 Documentaci´on.......................................... 7 2.6 Plandecontingencia....................................... 8 3 Marco te´orico 9 3.1 Ataquesinform´aticos....................................... 9 3.2 Amenazas persistentes avanzadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Detecci´on de amenazas persistentes avanzadas . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1 Detecci´ondelmalware.................................. 12 3.3.2 Monitorizaci´on del ataque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 T´ecnicas utilizadas en los ataques inform´aticos . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1 Persistencia........................................ 13 3.4.2 Escaladadeprivilegios.................................. 14 3.4.3 Evasi´ondedefensas ................................... 14 3.4.4 Obtenci´on de credenciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.5 B´usqueda ......................................... 15 3.4.6 Movimientolateral.................................... 16 3.4.7 Recolecci´on........................................ 16 3.4.8 Extracci´ondedatos ................................... 17 3.4.9 ComandoyControl ................................... 17 3.5 Herramientas de monitorizaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 ApacheKafka........................................... 18 3.7 LapilaELK............................................ 19 3.7.1 Logstash.......................................... 19 3.7.2 Elasticsearch ....................................... 19 3.7.3 Kibana .......................................... 20 4 Construcci´on del laboratorio 21 4.1 DominioActiveDirectory .................................... 21 7 4.2 ApacheKafka........................................... 23 4.3 LapilaELK............................................ 24 4.4 Visi´ongeneral........................................... 27 5 Simulaci´on de un ataque 29 5.1 Escaladadeprivilegios...................................... 29 5.2 Mantenerpersistencia ...................................... 31 5.3 Movimientolateral........................................ 33 5.4 Recopilaci´ondedatos ...................................... 35 5.5 Extracci´ondedatos ....................................... 36 6 Conclusiones y posibles mejoras 39 6.1 Conclusiones ........................................... 39 6.2 Posiblesmejoras ......................................... 40 ANEXO I Scripts de instalaci´on 47 ANEXO II Ficheros de configuraci´on 51 ANEXO IIIEventos monitorizados 57 ´ Indice de figuras 2.1 DiagramadeGantt. ....................................... 3 3.1 Modelo The Cyber Kill Chain®, desarrollado por Lockheed Martin. . . . . . . . . . . . . 10 3.2 Ciclo de vida de una amenaza persistente avanzada. . . . . . . . . . . . . . . . . . . . . . 11 3.3 Correspondencia de matrices de MITRE con las etapas de The Cyber Kill Chain®. . . . . 13 3.4 Dashboard de ejemplo de Kibana. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1 Pol´ıticasdeauditor´ıa. ...................................... 22 4.2 DashboarddeKibana ...................................... 25 4.3 Eventos de red mostrando los campos mas relevantes. . . . . . . . . . . . . . . . . . . . . 26 4.4 Detalledeuneventodered.................................... 26 4.5 Flujodedatos. .......................................... 27 5.1 Visualizaci´on de accesos a la memoria de lsass.exe. . . . . . . . . . . . . . . . . . . . . . . 30 5.2 Eventos relacionados con el volcado de memoria. . . . . . . . . . . . . . . . . . . . . . . . 31 5.3 Eventos de habilitar una cuenta, y convertirla en administrador. . . . . . . . . . . . . . . 32 5.4 Eventos de ocultaci´on de un fichero. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.5 Creaci´on de una tarea programada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.6 Preparaci´on del movimiento lateral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.7 Copia y ocultaci´on del malware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.8 Creaci´on de la tarea programada, y eliminaci´on del directorio compartido. . . . . . . . . . 34 5.9 Uso de herramientas de recolecci´on de datos, y numero de accesos a ficheros auditados. . . 35 5.10 Eventos de recopilaci´on de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.11 Conexiones FTP por direcci´on de destino. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.12 Detalles de los eventos de conexi´on FTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.3. Configuraci´on del laboratorio Una vez conocidas las t´ecnicas de ataque, se configurar´a la pila ELK, para que sea capaz de analizar los eventos de forma correcta, y detectar amenazas minimizando en lo posible falsos positivos. 3.1 Instalaci´on y configuraci´on de Apache Kafka Duraci´on: 5 d´ıas Predecesoras: 2.5 Descripci´on: Se instalar´a Apache Kafka en una m´aquina Linux. Se configurar´a para que reciba eventos de las m´aquinas windows, y que la pila ELK pueda acceder a ellos. 3.2 Despliegue del software de recolecci´on de eventos Duraci´on: 5 d´ıas Predecesoras: 3.1 Descripci´on: Instalaci´on del software de recolecci´on de eventos. Se utilizar´an las pol´ıticas de dominio para que se instale en todas las m´aquinas de forma autom´atica. Se configurar´a para que lleguen los eventos de todas las m´aquinas a Kafka. 3.3 Configurar auditor´ıa del dominio Duraci´on: 1 d´ıas Predecesoras: 3.2 Descripci´on: Modificar la pol´ıtica del dominio para que se generen eventos de auditoria relacionados con posibles ataques. 3.4 Instalaci´on de la pila ELK Duraci´on: 7 d´ıas Predecesoras: 3.3 Descripci´on: Se instalar´a la pila ELK en la segunda m´aquina Linux. Tambi´en se realizar´a la configuraci´on de Logstash y Elasticsearch. En esta tarea se comprobar´a que los eventos se muestran en Kibana. De no ser as´ı, se realizar´an las modificaciones necesarias. 6 2.4. Simulaci´on de un ataque Se realizar´a una simulaci´on de un ataque en las m´aquinas del laboratorio, para comprobar el funcionamiento de nuestro sistema SIEM, y analizar los resultados. Se desarrollaran las siguientes tareas: 4.1 Estudio de herramientas para simular un ataque Duraci´on: 3 d´ıas Predecesoras: 3 Descripci´on: Se realizar´a un estudio de herramientas que puedan servir para simular los efectos que tendr´ıa un ataque. 4.2 Crear visualizaciones y filtros en Kibana Duraci´on: 3 d´ıas Predecesoras: 3 Descripci´on: Se crear´an una serie de visualizaciones y filtros en Kibana, para facilitar la detecci´on de los ataques, y eliminar el ruido de los eventos cotidianos. 4.2 Simular t´ecnicas de ataque Duraci´on: 4 d´ıas Predecesoras: 3 Descripci´on: Se ejecutar´an las herramientas seleccionadas anteriormente para simular un ataque para comprobar que se pueden detectar en Kibana. En caso de que no se detecten, se realizar´an los cambios de configuraci´on necesarios. 2.5. Documentaci´on La memoria se desarrolla de forma paralela al trabajo, pero se deja un periodo al final para poder realizar posibles correcciones o mejoras al documento. 5.1 Finalizar memoria Duraci´on: 7 d´ıas Predecesoras: 3 Descripci´on: Se completar´an los detalles pendientes de la memoria. Tambi´en se har´a una revisi´on del documento para realizar posibles correcciones y mejoras. 7 2.6. Plan de contingencia Para mitigar los efectos de sucesos imprevistos, se tomar´an las siguientes medidas: Escenario de riesgo Descripci´on Estimaci´on incorrecta del tiempo de una tarea Se retrasar´an las tareas posteriores. En caso de no poder finalizar a tiempo, se retrasar´a la entrega a la segunda convocatoria. Indisposici´on personal Se dedicar´a tiempo extra para intentar volver a la planificaci´on temporal original cuanto antes. De no ser posible, se retrasar´a la entrega a la segunda convocatoria. Fallo de una m´aquina Se realizar´a una copia de seguridad peri´odicamente de los ficheros de configuraci´on, y se apuntaran los pasos seguidos en un fichero de texto. En caso de que sea necesario, se podr´a reconstruir el estado de la m´aquina. Falta de espacio en disco Se solicitar´a un aumento de capacidad del disco. De no ser posible, se eliminar´an los eventos antiguos. Problemas de acceso remoto Mientras no se pueda solucionar, se realizar´an tareas que no requieran el uso de una m´aquina del laboratorio. Problemas en desarrollo del proyecto Se dedicar´a tiempo extra para intentar encontrar una soluci´on. De no ser posible, se solicitar´a ayuda al tutor. Si fuera necesario, se retrasar´ıa la entrega a la segunda convocatoria. Perdida de datos en equipo personal Todos los ficheros relacionados con la elaboraci´on de la memoria y el proyecto se almacenar´an en sistemas con copia de seguridad en la nube. 8 Cap´ıtulo 3 Marco te´orico 3.1. Ataques inform´aticos Un ataque inform´atico es un proceso sistem´atico que se realiza contra un adversario para causarle unos efectos deseados. La esencia de una intrusi´on es que el agresor debe quebrantar la defensa de un entorno seguro y establecer una presencia. Con esa presencia, puede tomar acciones que le hagan conseguir su objetivo. Lockheed Martin ha desarrollado el modelo The Cyber Kill Chain®, para la identificaci´on y prevenci´on de intrusiones. En este modelo se recogen las etapas que tiene que hacer un adversario para conseguir sus objetivos: 1. Reconocimiento: Investigaci´on, identificaci´on y selecci´on de objetivos. Desde un sitio web se puede obtener mucha informaci´on, como por ejemplo direcciones de correo, nombres de empleados, o tecnolog´ıas que utilizan. 2. Preparaci´on: Preparar un ataque, como por ejemplo, integrar un troyano que explote una vulnerabilidad en un documento PDF. 3. Distribuci´on: Transmitir el ataque al objetivo. Esto se puede hacer mediante email, sitios web, o memorias USB. 4. Explotaci´on: Activar el ataque. Frecuentemente, se produce mediante una vulnerabilidad del sistema operativo, aprovechando caracter´ısticas de auto ejecuci´on, o simplemente por ejecuci´on del usuario. 5. Instalaci´on: La instalaci´on del troyano o puerta trasera permite que el adversario pueda mantener presencia dentro del entorno. 6. Comando y control: Establecer un canal mediante el cual el atacante pueda tener acceso desde fuera del entorno del objetivo. Las APT no realizan acciones de forma autom´atica, y necesitan interacci´on manual. 7. Acciones sobre los objetivos: Despu´es de pasar por las otras seis fases, es cuando el atacante puede tomar acci´on para conseguir sus objetivos. Normalmente se trata de extracci´on de informaci´on, que implica recolecci´on y cifrado. Tambi´en puede ser que solo necesite el equipo como punto medio para atacar otros sistemas y moverse lateralmente dentro de la red. 9 Figura 3.1: Modelo The Cyber Kill Chain®, desarrollado por Lockheed Martin. 3.2. Amenazas persistentes avanzadas Las amenazas persistentes avanzadas son ataques prolongados. Su objetivo es extraer informaci´on a largo plazo, no causar da˜nos. Como pueden ser ataques muy lucrativos, suelen tener como objetivo grandes empresas, o naciones, y utilizan t´ecnicas avanzadas y vulnerabilidades zero-day. Para evitar su detecci´on se utilizan t´ecnicas sofisticadas, como reescribir continuamente su c´odigo. 10 Los ataques de una APT se crean espec´ıficamente para cada objetivo. Se construyen nuevas herramientas de malware, en lugar de utilizar otras ya existentes, para evitar ser detectados por antivirus basados en firmas. Ademas, las acciones de una APT no se realizan autom´aticamente, porque los patrones de comportamiento pueden ser detectados mediante t´ecnicas heur´ısticas. En su lugar, es el atacante el que manualmente realiza las acciones. Para ejecutar un ataque con una APT, el atacante tiene que realizar como m´ınimo las siguientes fases: Obtener acceso: Normalmente se realiza mediante phising. Establecer persistencia: Despu´es de obtener acceso, el atacante realiza mas reconocimiento, y utiliza el malware que ha plantado para crear puertas traseras y tuneles para poder moverse sin ser detectado. Obtener mayor acceso: Una vez dentro, necesita obtener permisos administrativos para tener mayor acceso. Moverse lateralmente: Con permisos de administrador, el atacante puede moverse por toda la red, e intentar acceder a otros servidores. Preparar el ataque: en esta etapa, se recogen los datos, se comprimen, y se cifran, para poder extraerlos. Extracci´on de datos: El atacante transfiere los datos a su sistema. Permanecer hasta ser detectado: El atacante puede volver a repetir el proceso mas tarde, siempre que no haya sido detectado. Figura 3.2: Ciclo de vida de una amenaza persistente avanzada. 11 3.3. Detecci´on de amenazas persistentes avanzadas Las APT est´an dise˜nadas con la intenci´on de no ser detectadas. Hay varias t´ecnicas que podemos utilizar para intentar detectarlas, pero no todas tienen por que funcionar. 3.3.1. Detecci´on del malware En la fase de preparaci´on del ataque, se construye un mecanismo para infiltrar el malware. La detecci´on de este malware durante la fase de distribuci´on podr´ıa frenar un ataque antes de que pueda causar da˜nos, pero es una t´ecnica que no suele funcionar con las APT. Existen principalmente dos m´etodos de detecci´on: Detecci´on basada en firma: Consiste en establecer un identificador a una amenaza conocida, con el objetivo de detectarla si vuelve a aparecer. Como las APT se crean espec´ıficamente para cada ataque, el indice de detecci´on es bajo. Detecci´on basada en comportamiento: Consiste en analizar el c´odigo de un objeto antes de su ejecuci´on, para detectar patrones de comportamiento que normalmente est´an asociados a ataques inform´aticos. Con este m´etodo, la tasa de detecci´on es mas alta, pero tiene mayor coste computacional y puede detectar falsos positivos. Como las APT utilizan t´ecnicas avanzadas para no ser descubiertas, debemos asumir que son capaces de sortear este tipo de detecci´on. Por la naturaleza de las APT, no podemos considerar fiables ninguno de estos m´etodos. Otra t´ecnica que podr´ıa ser de utilidad es la monitorizaci´on. 3.3.2. Monitorizaci´on del ataque Como la detecci´on del malware es dif´ıcil, otra forma para detectar una APT es la monitorizaci´on. Las APT realizan una serie de acciones, como la escalada de privilegios, o la extracci´on de datos, que nos pueden permitir detectarla. Algunas de estas t´ecnicas de ataque contra las que podemos monitorizar son: Escalada de privilegios: Se consigue mediante manipulaci´on de cuentas, y crackeo de contrase˜nas. Las acciones relacionadas con la manipulaci´on de cuentas generan eventos en el registro de eventos de Windows. Persistencia: Para mantener persistencia, la APT puede utilizar mecanismos del sistema operativo para programar la ejecuci´on del malware, por ejemplo durante el arranque. Existen pol´ıticas de auditoria que notifican cuando se modifica la configuraci´on de estos mecanismos. Movimiento lateral: Se puede hacer con herramientas de despliegue de software, o mediante inicios de sesi´on remotos. Se pueden detectar porque aparecen patrones similares en varios equipos. Recolecci´on de datos: Acceso a ficheros de inter´es. Se accede a los datos locales de varios equipos, carpetas compartidas, correos electr´onicos, etc. Una vez recolectados, se comprimen y se cifran para facilitar su extracci´on. Esto tambi´en se puede detectar configurando una pol´ıtica de auditor´ıa que notifique cuando se produce un acceso. Comando y control: Ponerse en contacto con el atacante para recibir instrucciones. Una forma de detectar esto puede ser el an´alisis del tr´afico de red. 12 Extracci´on de datos: Realizar una transferencia de datos a una m´aquina del atacante. Se puede utilizar multitud de protocolos. De nuevo, es posible detectarlo mediante el an´alisis del tr´afico de red. La detecci´on de estas acciones presenta varias dificultares. Todas ellas se realizan de forma cotidiana, y pueden aparecer en grandes vol´umenes en entornos corporativos. Separar los eventos normales de los de un ataque requiere mantener una atenci´on especial y constante. A´un as´ı, el realizar una monitorizaci´on adecuada puede ser la mejor o ´unica forma de detectar una APT. 3.4. T´ecnicas utilizadas en los ataques inform´aticos La organizaci´on MITRE, mantiene una base de conocimientos de acceso publico, que recoge t´acticas y t´ecnicas observadas en ataques reales. Las separa en dos matrices: PRE-ATT&CK®, que se encarga de las fases de reconocimiento y preparaci´on, y ATT&CK®, para el resto. Amplia las etapas de The Cyber Kill Chain®para dividir las t´ecnicas de ataque. En este trabajo, vamos a explorar las t´ecnicas que aparecen en ATT&CK®, y en concreto, en las que se pueden detectar con la pila ELK y el registro de eventos de windows. El nombre de las t´ecnicas que se describen a continuaci´on incluye el c´odigo identificador asignado por MITRE. Figura 3.3: Correspondencia de matrices de MITRE con las etapas de The Cyber Kill Chain®. 3.4.1. Persistencia La persistencia consiste en t´ecnicas que el adversario utiliza para seguir manteniendo acceso a sistemas despu´es de reinicios, cambio de credenciales, y otros factores que puedan cortar el acceso. T1098 Manipulaci´on de cuentas Cualquier acci´on que pueda permitir preservar acceso a una cuenta comprometida, como puede ser modificaci´on de credenciales, o grupos de permisos. 13 T1547 Ejecuci´on autom´atica Configurar el sistema de forma que se ejecute un programa autom´aticamente durante el arranque del sistema, o durante el inicio de sesiones de usuario. T1136 Creaci´on de cuentas Con el nivel de acceso adecuado, un atacante puede crearse una cuenta para mantener acceso en los sistemas victima. T1543 Creaci´on de servicios Crear un servicio de windows que ejecute una carga maliciosa. Estos servicios se pueden configurar para que se ejecuten de forma autom´atica durante el arranque del sistema. T1053 Tareas programadas Un atacante puede crear una tarea programada, utilizando el programador de tareas de windows, que ejecute repetidamente un malware. T1078 Cuentas v´alidas Obtener credenciales de acceso de cuentas existentes. Pueden utilizar cuentas que se crean por defecto, como la cuenta Administrador, o obtener informaci´on de cuentas existentes. La detecci´on de un ataque con eventos de cuentas puede ser dif´ıcil, porque pueden suceder de forma normal, cuando no hay un ataque. Su an´alisis se debe basar en patrones, como por ejemplo, si suceden en horarios extra˜nos, o si presentan un volumen inusual. En cuanto a la creaci´on de tareas programadas y servicios, su detecci´on es mas sencilla. Se producen con baja frecuencia, y se crean por los administradores, por lo que se debe investigar cualquier evento no programado. 3.4.2. Escalada de privilegios La escalada de privilegios consiste en t´ecnicas que el adversario utiliza para obtener permisos de mayor nivel en un sistema o en una red. Los adversarios pueden entrar y explorar una red con acceso sin privilegios, pero necesitan permisos elevados para conseguir sus objetivos. Algunas cuentas que se pueden utilizar son: SYSTEM, administrador local, cuentas de usuario con permisos similares a administrador, o cuentas de usuario con acceso a sistemas espec´ıficos. Las t´ecnicas que se utilizan se solapan con las de persistencia. La escalada se puede conseguir obteniendo acceso a una cuenta con mayor privilegio, o programando la ejecuci´on del malware para que se ejecute con otra cuenta de usuario. La detecci´on de estas t´ecnicas se realiza de forma similar a las de persistencia. 3.4.3. Evasi´on de defensas Con est´as t´ecnicas, el adversario intenta evitar ser detectado, por ejemplo desactivando caracter´ısticas de seguridad, o ofuscando el malware. T1484 Modificaci´on de la pol´ıtica de dominio Desactivar la configuraci´on de seguridad o auditor´ıa para evadir defensas. Tras el ataque, pueden volverse a activar para no dejar rastro. 14 T1222 Modificaci´on de permisos de ficheros y directorios Se puede modificar la configuraci´on de seguridad para acceder a ficheros protegidos, evadiendo las listas de control de acceso. Puede que sea necesario cambiar el propietario del fichero. T1562 Debilitar defensas Desactivar antivirus y firewall, o configurarlos para que no detecten el ataque. T1070 Eliminaci´on de indicadores Eliminar o alterar los registros de eventos para que no aparezca ninguna actividad del malware. T1036 Enmascaramiento Manipular caracter´ısticas del malware para que parezca legitimo. Esto puede ser, por ejemplo, utilizar nombres de procesos del sistema, o modificando la fecha de creaci´on para que parezca que se instal´o con el sistema operativo. T1112 Modificar el registro Utilizar el registro de windows para almacenamiento de configuraci´on y datos del malware, o para eliminar informaci´on sobre su presencia. Todas estas t´ecnicas se pueden detectar habilitando las pol´ıticas de auditor´ıa correspondientes. Incluso la eliminaci´on del registro de eventos deja un evento. Como ninguno de estos suelen ocurrir de forma frecuente, se deben investigar cada vez que aparezcan. 3.4.4. Obtenci´on de credenciales T´ecnicas utilizadas para obtener nombres de cuentas y contrase˜nas. Un atacante con credenciales v´alidas tiene acceso al sistema, y es mas dif´ıcil de detectar. T1110 Fuerza bruta Utilizar t´ecnicas de fuerza bruta para obtener acceso a cuentas cuando se desconoce la contrase˜na. Se puede hacer con una lista de contrase˜nas comunes, o intentando todas las posibilidades. El ataque es mas efectivo si el adversario tiene informaci´on sobre la pol´ıtica de contrase˜nas. T1003 Descarga de credenciales Obtenci´on de credenciales almacenadas en el sistema, como puede ser accediendo a la memoria de lsass.exe, que gestiona el acceso de las cuentas. Normalmente la informaci´on est´a en forma de hash. Facilita la obtenci´on de contrase˜nas con t´ecnicas de fuerza bruta, porque se puede hacer de forma offline. Un ataque por fuerza bruta genera muchos eventos de inicio de sesi´on fallido, y es f´acil de detectar. Para la detecci´on de descarga de credenciales, se deben auditar los ficheros y programas que pueden contener esta informaci´on. 3.4.5. B´usqueda T´ecnicas que un atacante puede utilizar para obtener mas informaci´on del entorno. Esta informaci´on permite que se pueda modificar el ataque atendiendo a las caracter´ısticas especificas del sistema. 15 Figura 4.1: Pol´ıticas de auditor´ıa. 22 4.2. Apache Kafka Apache Kafka se ha instalado en linux-00. Se ha realizado una instalaci´on manual con el paquete binario de la versi´on 2.7.0 y Scala 2.13 en /opt. Como es una aplicaci´on java, tambi´en se ha instalado la versi´on 14 del jre openjdk. # wget https://ftp.cixug.es/apache/kafka/2.7.0/kafka_2.13-2.7.0.tgz # tar xvf kafka_2.13-2.7.0.tgz # mv kafka_2.13-2.7.0 /opt/kafka # apt install openjdk-14-jre La configuraci´on por defecto (server.properties) se ha modificado para que los mensajes se almacenen en el disco, y se ha reducido el tiempo de retenci´on a 24 horas con las siguientes directivas. log.dirs=/opt/kafka/kafka-logs log.retention.hours=24 A pesar de que solo se utilice un nodo Kafka, necesita comunicarse con ZooKeper, un servicio de coordinaci´on distribuida que viene incluido. Para facilitar su inicio, se ha creado un usuario para ZooKeper y otro para Kafka, y se ha creado un servicio de systemd para cada uno (ANEXO II). Se est´a trabajando para que en versiones posteriores de Kafka no sea necesario utilizar Zookeper. Cuando se inicia un cluster Zookeper, se genera un id del cluster. Cuando Kafka se conecta por primera vez, guarda este id para conectarse siempre al mismo cluster. Zookeper guarda el identificador en /tmp, y en caso de reinicio del sistema se pierde, y los clientes Kafka no pueden volverse a conectar. Para solucionar este problema, se ha modificado la configuraci´on de Zookeper (zookeeper.properties) para que guarde los datos en almacenamiento persistente. dataDir=/opt/kafka/zookeeper Despu´es se ha creado un topic para los eventos de windows recogidos por Winlogbeat, y otro para los eventos de red recogidos por Packetbeat. Como solo se dispone de un servidor, los topics no se dividen en particiones. Para ahorrar espacio en disco, se ha seleccionado el algoritmo de compresi´on zstd. # /opt/kafka/bin/kafka-topics.sh \ --bootstrap-server localhost:9092 --create --topic winlogbeat \ --partitions 1 --config compression.type=zstd # /opt/kafka/bin/kafka-topics.sh \ --bootstrap-server localhost:9092 --create --topic packetbeat \ --partitions 1 --config compression.type=zstd Con est´a configuraci´on, tanto los productores como los consumidores pueden acceder a los topics. No es necesario ning´un tipo de autenticaci´on. Para comprobar que Kafka est´a recibiendo mensajes, podemos utilizar el siguiente comando para ver los mensajes del topic winlogbeat: # /opt/kafka/bin/kafka-console-consumer.sh \ --bootstrap-server localhost:9092 --topic winlogbeat --from-beginning 23 Como los eventos de Kafka pueden ser utilizados en otras aplicaciones, en esta etapa no se realiza ning´un tipo de filtrado. Los eventos que no son interesantes para la detecci´on de amenazas pueden seguir siendo de utilidad para otros consumidores, como por ejemplo, en un entorno empresarial que tenga un sistema de monitorizaci´on del estado de los equipos, o del rendimiento. 4.3. La pila ELK La pila ELK se ha instalado en linux-01. Se han utilizado los paquetes deb de la versi´on 7.11.1 de los tres componentes. # wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.11.1-amd64.deb # wget https://artifacts.elastic.co/downloads/kibana/kibana-7.11.1-amd64.deb # wget https://artifacts.elastic.co/downloads/logstash/logstash-7.11.1-amd64.deb # apt install ./elasticsearch-7.11.1-amd64.deb # apt install ./kibana-7.11.1-amd64.deb # apt install ./logstash-7.11.1-amd64.deb La configuraci´on por defecto de Elasticsearch y Kibana asume que ambos se encuentran en el mismo equipo, y no es necesario modificar nada. La configuraci´on de Logstash es mas compleja. Hay que especificar un origen y destino de los datos, y unas normas de filtrado (ANEXO II). En nuestro caso, los datos se leen de Kafka, y se env´ıan a Elasticsearch. En cuanto al filtrado, en primer lugar, hay que conseguir que Logstash sea capaz de interpretar los mensajes. Para ello, cuenta con varios filtros integrados. En nuestro caso, los eventos est´an en formato JSON, que se puede convertir sin problemas con el filtro correspondiente. Una vez convertido, se pueden escribir reglas utilizando directamente el nombre de los campos. En este trabajo, se han elaborado filtros para eliminar eventos irrelevantes, y que solo aparezcan eventos ´utiles relacionados con alguna de las t´ecnicas descritas anteriormente, siguiendo la recomendaci´on del MITRE, y de Microsoft. Con Logstash configurado, se puede acceder a la interfaz web de Kibana, y seleccionar el indice logstash como fuente de datos. Al hacer esto ya se puede acceder a los eventos recogidos. Aunque se han filtrado los eventos, su consulta y an´alisis sigue siendo una tarea laboriosa. No nos interesan ver siempre los detalles de todos los eventos. En su lugar, se pueden guardar consultas que filtren y muestren solo eventos relevantes a lo que se est´e analizando. Ademas, se pueden crear visualizaciones de los datos de forma que se puedan apreciar ciertos comportamientos de forma visual. Con estas visualizaciones no se pueden detectar t´ecnicas lentas, que generen pocos eventos con intervalos prolongados, pero sigue siendo de utilidad para otras cosas. Por ejemplo, un ataque que haga varios intentos por segundo para encontrar la contrase˜na de un usuario, o una extracci´on de datos utilizando el protocolo DNS, generar´an un numero elevado de eventos en un peque˜no intervalo de tiempo. En la siguiente captura de pantalla (figura 4.2) se muestra un dashboard en el que se puede detectar un nivel de actividad de red inusual entre las 20:00 y las 23:00 horas. El nivel de peticiones DNS es mas elevado en ese intervalo, y vemos que hay un pico de trafico en los puertos 53 (DNS) y 443 (HTTPS). Ademas, vemos que el pico de trafico se genera en windows-01 y que hay un elevado numero de inicios de sesi´on. El trafico elevado de server en este caso se debe a que es el servidor DNS, y tiene que reenviar las peticiones de nombres que no pertenecen al dominio. 24 Figura 4.2: Dashboard de Kibana Desde el propio dashboard, se puede seleccionar la opci´on de indagar para mostrar los eventos que han ocurrido en esa franja de tiempo. En un principio muestra todos los detalles de cada evento, pero se puede seleccionar que solo se muestren los campos relevantes para tener una visualizaci´on mas sencilla en forma de tabla. 25 Figura 4.3: Eventos de red mostrando los campos mas relevantes. Desde esta tabla, se puede seleccionar un evento para ver todos sus datos si es necesario. En la siguiente imagen (figura 4.4) se muestran algunos de los datos de un evento de red. Figura 4.4: Detalle de un evento de red. 26 4.4. Visi´on general Con el laboratorio construido, el flujo de los eventos ser´a el siguiente: 1. Winlogbeat y Packetbeat recogen los eventos de cada equipo, y los mandan a Kafka. 2. Los eventos de todos los equipos se almacenan en Kafka, y se ponen a disposici´on de los consumidores. 3. Logstash lee los eventos de Kafka, los filtra, y se los env´ıa a Elasticsearch. 4. Elasticsearch almacena los datos, crea los indices necesarios, y proporciona las funciones de b´usqueda mediante una API REST. 5. Kibana utiliza Elasticsearch para proporcionar b´usqueda, filtrado, y visualizaci´on de datos desde una interfaz web. linux-00 linux-01 Logstash Elasticsearch Kibana server Winlogbeat Packetbeat windows-00 Winlogbeat Packetbeat windows-01 Winlogbeat Packetbeat Kafka Dominio AD hackeame.red Figura 4.5: Flujo de datos. 27 Cap´ıtulo 5 Simulaci´on de un ataque En este capitulo, se va a realizar una serie de ataques que cubran las fases habituales de una APT. El ataque se realizar´a con APTSimulator, una utilidad que incluye m´ultiples herramientas y scripts para simular algunas t´ecnicas comunes de ataques reales. En algunos casos, como en el movimiento lateral, los scripts incluidos son insuficientes, y se han preparado unos propios para realizar la tarea correspondiente. La simulaci´on se realiza sobre windows-00. El procedimiento a seguir ser´a en primer lugar la obtenci´on de credenciales, y la escalada de privilegios. Con una cuenta administrativa se van a realizar t´ecnicas de evasi´on de defensas, persistencia, y movimiento lateral a server. Finalmente, se realizara una exploraci´on y extracci´on de datos de server. Los ataques que se realizan no son necesariamente los mas sofisticados, y sirven solo como demostraci´on de la detecci´on basada en eventos. Por ese motivo, no se van a realizar ataques sigilosos que generen eventos con intervalos muy largos. Este tipo de ataques son mas dif´ıciles de descubrir, pero deber´ıan ser detectables con las mismas t´ecnicas utilizadas a continuaci´on. Por motivos de tama˜no y legibilidad, las capturas de pantalla que aparecen en esta secci´on muestran solo una parte de todos los campos que se almacenan de cada evento. Desde la interfaz web se pueden ver todos, pero se han seleccionado los mas importantes para la demostraci´on en cada caso. 5.1. Escalada de privilegios Para la escalada de privilegios, se utiliza la t´ecnica T1003: Descarga de credenciales. En primer lugar, se utiliza Process Explorer, de Sysinternals, para hacer un volcado de memoria del proceso lsass.exe. Este proceso se encarga, entre otras cosas, de verificar las contrase˜nas de usuario en los inicios de sesi´on, y almacena hashes de las contrase˜nas en la memoria de proceso. Despu´es, se utiliza mimikatz, una herramienta que es capaz de leer el volcado de memoria, y extraer las contrase˜nas. ECHO =========================================================================== ECHO LSASS DUMP ECHO. ECHO Dumping LSASS memory with ProcDump ping -n 5 127.0.0.1 > NUL %ZIP % e -p %PASS % %TOOLARCH % -aoa -o %PUBLIC % toolset \ procdump64 .exe > NUL %PUBLIC % \ procdump64 . exe -accepteula -ma lsass .exe %APTDIR % \ somethingwindows . dmp 2 >&1 lsass-dump.bat 29 ECHO =========================================================================== ECHO MIMIKATZ ECHO. ECHO Dropping a custom mimikatz build into the APT dir ping -n 5 127.0.0.1 > NUL %ZIP % e -p %PASS % %TOOLARCH % -aoa -o %APTDIR % toolset \mim .exe > NUL ECHO Executing it to get it into memory and saving the output to out. tmp ... ping -n 5 127.0.0.1 > NUL %APTDIR % \mim. exe > out .tmp ECHO Extracting Mimik4tz output to target directory ... ping -n 5 127.0.0.1 > NUL %ZIP % e -p %PASS % %FILEARCH % -aoa -o %APTDIR % toolset \mim-out .txt > NUL mimikatz-1.bat Para encontrar este ataque, primero hay que detectar el acceso a la memoria de lsass.exe. Por como est´a configurado Sysmon, solo se registran intentos de acceso a la memoria de lsass.exe que no han sido generados por procesos de Microsoft. Como esto no deber´ıa pasar nunca, siempre que aparezca uno de estos eventos debe ser investigado. Para facilitar su detecci´on, se ha creado una visualizaci´on (figura 5.1). Figura 5.1: Visualizaci´on de accesos a la memoria de lsass.exe. Como ha habido accesos a la memoria de lsass.exe, se deben investigar los eventos que han sucedido en ese periodo. Al hacerlo, se pueden ver los pasos seguidos para realizar el ataque (figura 5.2). 30 Figura 5.2: Eventos relacionados con el volcado de memoria. En primer lugar, se extrae la herramienta procdump64.exe, y se ejecuta para volcar la memoria de lsass.exe en el fichero somethingwindows.dmp. Justo despu´es vemos que se generan dos eventos de acceso a la memoria de lsass.exe, que son los que nos han alertado anteriormente. Cuando finaliza, se extrae una versi´on modificada de mimikatz, con el nombre mim.exe, y se ejecuta. Finalmente, se extrae un fichero que contiene una salida de ejemplo de mimikatz, para simular el rastro que dejar´ıa. Con este ataque, un atacante puede haber obtenido cunetas de usuario del sistema. Suponiendo que las cuentas extra´ıdas cuentan con permisos de administrador, utilizar´a estas cuentas en las fases posteriores del ataque. 5.2. Mantener persistencia Para mantener la persistencia, al atacante le interesa tener una cuenta mas discreta con permisos administrativos que pueda utilizar sin levantar sospecha. En este ejemplo se activa la cuenta de invitado, y se le asignan permisos de administrador. Este proceso es mas conveniente que crear un usuario nuevo, porque se utiliza una cuenta que viene integrada en windows. De esta forma, puede pasar desapercibida cuando se hace un listado de los usuarios del sistema, y no aparece en los logs de creaci´on de cuentas. ECHO =========================================================================== ECHO GUEST USER ECHO Activating guest user account ping -n 3 127.0.0.1 > NUL net user invitado /active:yes ECHO Adding the guest user to the local administrators group 31 Cap´ıtulo 6 Conclusiones y posibles mejoras 6.1. Conclusiones En este trabajo, se han estudiado las amenazas persistentes avanzadas, y se ha creado un sistema capaz de detectarlas. Como las amenazas persistentes avanzadas son ataques con objetivos concretos, utilizan mecanismos ´unicos, y no podemos contar con que sean detectadas por antivirus. En su lugar, para su detecci´on, es necesario utilizar otros mecanismos, como el an´alisis de registros de eventos. Una forma de hacerlo es utilizando la pila ELK. Los ataques con amenazas persistentes suelen tener como objetivo grandes empresas. Para simular estas condiciones, se ha creado un dominio Active Directory con tres equipos. La detecci´on de amenazas en estos entornos necesita la recopilaci´on de eventos de todos los equipos. Para ello, se ha utilizado Apache Kafka. Para comprender como detectarlas, se ha hecho un estudio de amenazas persistentes, las t´ecnicas que utilizan, y como detectarlas. Despu´es, se ha investigado el funcionamiento del registro de eventos de windows para ver que tipo de eventos se registran. Para extender sus capacidades se ha utilizado Sysmon, que a˜nade varios tipos de eventos. Ademas, se ha utilizado Packetbeat para recoger informaci´on del tr´afico de red. El despliegue de software en los equipos Windows se ha realizado mediante pol´ıticas de dominio. Tambi´en se han configurado pol´ıticas de auditor´ıa para la detecci´on de ciertas t´ecnicas. Se ha instalado Apache Kafka en una m´aquina linux para recopilar los eventos de todos los equipos. Tanto Winlogbeat como Packetbeat son capaces de enviar eventos a Kafka, no es necesario utilizar ning´un programa o plugin externo. En la otra m´aquina linux se ha instalado la pila ELK: Elasticsearch, Logstash, Kibana. Se ha configurado Logstash para que acceda a los eventos almacenados en Kafka, los filtre, y se los env´ıe a Elasticsearch. Elasticsearch se encarga de almacenar los datos, y crea los indices necesarios para realizar consultas. Kibana utiliza la API de Elasticsearch para proporcionar sus funciones desde una interfaz gr´afica. A pesar del filtrado en Logstash, sigue llegando demasiada informaci´on a Elasticsearch. Para facilitar el an´alisis de estos datos, se ha creado visualizaciones y filtros en Kibana. Con algunas visualizaciones se puede detectar un ataque r´apidamente. Cuando no es posible siguen siendo de utilidad, ya que permiten que se puedan detectar patrones extra˜nos. Los filtros de Kibana se pueden utilizar para que se muestre la informaci´on relevante de un tipo de ataque. Con algunas t´ecnicas, las gr´aficas no son de utilidad, y es necesario utilizar alguno de estos filtros. 39 Para comprobar la detecci´on de algunas de las t´ecnicas estudiadas, se ha simulado un ataque que comienza en una m´aquina windows, y consigue infectar al controlador del dominio, y extraer datos protegidos. Para ello, se han utilizado algunos scripts de APTSimulator. Para el movimiento lateral, recopilaci´on, y extracci´on de datos, se han creado scripts propios. Queda demostrada la efectividad de Apache Kafka y la pila ELK para la detecci´on de amenazas basada en an´alisis de eventos. Juntos forman un sistema robusto que permite la monitorizaci´on de entornos con m´ultiples equipos. Su utilizaci´on mejorar´ıa la seguridad de grandes organizaciones, permitiendo la detecci´on de ataques adicionales en los que un antivirus no resulta eficaz. 6.2. Posibles mejoras A pesar de haber conseguido su objetivo, existen formas de mejorar el sistema. Las t´ecnicas que se detectan con an´alisis del trafico de red, necesitan un estudio mas en profundidad. En este trabajo se han utilizado ataques simples, pero un atacante competente ser´ıa capaz de camuflar la comunicaci´on con las m´aquinas infectadas. Algunas t´ecnicas, como la utilizaci´on de protocolos no est´andar, rotaci´on de direcciones y puertos, o la extracci´on mediante servicios web como google drive, son mucho mas dif´ıciles de detectar. Como la extracci´on es el objetivo final de cualquier ataque, el sistema se beneficiar´ıa mucho si estuviera mejor preparado para detectar estas actividades. El sistema se ha construido para la monitorizaci´on de un entorno Windows, pero en algunas organizaciones se utiliza Linux. Ser´ıa beneficioso que el sistema pudiera monitorizar equipos Linux, pero su adaptaci´on no es trivial. Los ficheros log en Linux no recogen la misma informaci´on, y no tienen el mismo formato que en el registro de eventos de Windows. La configuraci´on de Logstash y Kibana deber´ıa ser distinta. El software de monitorizaci´on Sysmon no es compatible con Linux, y habr´ıa que buscar una alternativa. En este trabajo, el ataque lo ha hecho la misma persona que ha creado el sistema. Las t´ecnicas de ataque utilizadas eran conocidas, y se han seleccionado porque se sab´ıa que se pod´ıan detectar. Si el atacante fuera otra persona, podr´ıa utilizar t´ecnicas imprevistas. De esta forma, pueden aparecer agujeros en las defensas que se desconoc´ıan. Al exponer y corregir estos problemas, mejorar´ıa la robustez del sistema. Para detectar algunas de las t´ecnicas con este sistema, no queda mas remedio que analizar manualmente una gran cantidad de eventos. Ser´ıa interesante investigar las capacidades de Elasticsearch de hacer Machine Learning, y que se automaticen algunos aspectos del an´alisis. Debidamente configurado, podr´ıa ser interesante que se generaran notificaciones por correo cuando se detecte una amenaza. En este trabajo, se utiliza una ´unica instancia de Apache Kafka. Ser´ıa interesante proponer escenarios, como la monitorizaci´on de varias sucursales, en las que sea necesario crear un cluster distribuido con Kafka, y probar sus capacidades de escalabilidad y disponibilidad. 40 Bibliograf´ıa [1] Eyal Aharoni, “Seeing the Unseen: Detecting and Preventing the Advanced Persistent Threat”cymulate, Enero 2019. Accedido Junio 2021. [Online]. Disponible: https://blog.cymulate. com/advanced-persistent-threat [2] Mary K. Pratt, “What is SIEM software? How it works and how to choose the right tool”CSO, Nobviembre 2017. Accedido Junio 2021. [Online]. Disponible: https://www.csoonline.com/article/ 2124604/what-is-siem-software-how-it-works-and-how-to-choose-the-right-tool.html [3] INCIBE, “Las 7 fases de un ciberataque. ¿Las conoces?”INCIBE, Enero 2020. Accedido Junio 2021. [Online]. Disponible: https://www.incibe.es/protege-tu-empresa/blog/ las-7-fases-ciberataque-las-conoces [4] Eric M. Hutchins, Michael J. Cloppert, Rohan M. Amin, Ph.D., “Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains”Lockheed Martin Corporation. Accedido Junio 2021. [Online]. Disponible: https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/ LM-White-Paper-Intel-Driven-Defense.pdf [5] Linda Rosencrance, “advanced persistent threat (APT)”TechTarget, Agosto 2020. Accedido Junio 2021. [Online]. Disponible: https://searchsecurity.techtarget.com/definition/ advanced-persistent-threat-APT [6] Do Xuan Choa, Ha Hai Nam, “A Method of Monitoring and Detecting APT Attacks Based on Unknown Domains”Procedia Computer Science, vol. 150, pp. 1143-1148, 2019. Accedido Junio 2021. [Online]. Disponible: https://www.sciencedirect.com/science/article/pii/S1877050919304041/ pdf?md5=0073c63fe2a4bf96c7e0c77a3491cc91&pid=1-s2.0-S1877050919304041-main.pdf [7] Yona Hollander, “Behavioral rules vs. signatures: Which should you use?”Computerworld, Febrero 2003. Accedido Junio 2021. [Online]. Disponible: https://www.computerworld.com/article/ 2581345/behavioral-rules-vs--signatures--which-should-you-use-.html [8] “ATT&CK Matrix for Enterprise”MITRE. Accedido Abril 2021. [Online]. Disponible: https:// attack.mitre.org/ [9] Mark Russinovich, Thomas Garnier, “Sysmon v13.21”Microsoft, Junio 2021, Manual de Sysmon. Accedido Junio 2021. [Online]. Disponible: https://docs.microsoft.com/en-us/sysinternals/ downloads/sysmon [10] “Packetbeat overview”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https://www. elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html 41 [11] “Kafka Use cases”Apache Software Foundation. Accedido Junio 2021. [Online]. Disponible: https: //kafka.apache.org/uses [12] “Kafka Introduction”Apache Software Foundation. Accedido Junio 2021. [Online]. Disponible: https://kafka.apache.org/intro [13] “What is the ELK Stack?”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https: //www.elastic.co/what-is/elk-stack [14] “The ELK stack”Amazon Web Services Accedido Junio 2021. [Online]. Disponible: https://aws. amazon.com/es/elasticsearch-service/the-elk-stack/ [15] “Centralize, transform & stash your data”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https://www.elastic.co/logstash [16] “Logstash Introduction”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https:// www.elastic.co/guide/en/logstash/current/introduction.html [17] “What is Elasticsearch?”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https:// www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html [18] “Data in: documents and indices”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https://www.elastic.co/guide/en/elasticsearch/reference/current/documents-indices. html [19] “What is Kibana?”Elasticsearch B.V. Accedido Junio 2021. [Online]. Disponible: https://www. elastic.co/what-is/kibana [20] Mark Russinovich, “Process Explorer v16.42”Microsoft, Junio 2021, Manual de Process Explorer. Accedido Junio 2021. [Online]. Disponible: https://docs.microsoft.com/en-us/sysinternals/ downloads/process-explorer [21] errorBoss, “Lsass.exe”WinTuts, Diciembre 2014. Accedido Junio 2021. [Online]. Disponible: https: //www.wintuts.com/lsass-exe [22] Benjamin DELPY, “Home”, Julio 2020, Wiki de Mimikatz. Accedido Junio 2021. [Online]. Disponible: https://github.com/gentilkiwi/mimikatz/wiki [23] “Cached and Stored Credentials Technical Overview”Microsoft, Agosto 2016. Accedido Junio 2021. [Online]. Disponible: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/ windows-server-2012-r2-and-2012/hh994565(v=ws.11) [24] Mark Russinovich, “PsExec v2.34”Microsoft, Mayo 2021, Manual de PsExec. Accedido Junio 2021. [Online]. Disponible: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec [25] “Kafka input plugin”Elasticsearch B.V. Documentaci´on de Logstash. Accedido Junio 2021. [Online]. Disponible: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-kafka. html 42 [26] “Grok filter plugin”Elasticsearch B.V. Documentaci´on de Logstash. Accedido Junio 2021. [Online]. Disponible: https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok. html [27] “Appendix L: Events to Monitor”Microsoft, Julio 2018. Accedido Junio 2021. [Online]. Disponible: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/ appendix-l--events-to-monitor [28] Francisco Cesar Ganso Gil, “Threat hunting con la pila ELK”Universidad de Valladolid. 43 Anexos 45 ANEXO I Scripts de instalaci´on instalar winlogbeat.ps1 Start-Process msiexec.exe -Wait -ArgumentList ’ / quiet / package "\\ server \ software \ winlogbeat-7 .11.1windows-x86_64 . msi" ’ $hostname =hostname $kafka_host ="192.168.5.12:9092" $topic =" winlogbeat " $config =@" winlogbeat . event_logs : - name: Application ignore_older: 72h - name: System - name: Security processors : - script: lang: javascript id: security file: ‘${ path. home }/ module / security / config / winlogbeat-security . js - name : Microsoft-Windows-Sysmon / Operational processors : - script: lang: javascript id: sysmon file: ‘${ path. home }/ module / sysmon / config / winlogbeat-sysmon . js - name: Windows PowerShell event_id : 400 , 403 , 600 , 800 processors : - script: lang: javascript id: powershell file: ‘${ path. home }/ module / powershell / config / winlogbeat-powershell . js - name : Microsoft-Windows-PowerShell / Operational event_id : 4103 , 4104 , 4105 , 4106 47 4697, # Se ha instalado un servicio en el sistema 4698, # Se ha creado una tarea programada 4699, # Se ha eliminado una tarea programada 4700, # Se ha activado una tarea programada 4701, # Se ha desactivado una tarea programada 4702, # Se ha actualizado una tarea programada # Auditoria 4715, # Se ha modificado la politica de auditoria de un objeto 4719, # Se ha modificado la politica de auditoria del sistema 4817, # Se ha modificado la configuraci ´on de auditoria de un objeto # Active directory 5136, # Se ha modificado un objeto de Active Directory 5137, # Se ha creado un objeto de Active Directory 5138, # Se ha recuperado un objeto de Active Directory 5139, # Se ha movido un objeto de Active Directory 5141 # Se ha eliminado un objeto de Active Directory ] { drop {} } # Eliminar eventos producidos por equipos if [user][ name] =~ /\ $$ /{ drop{} } if [winlog][ event_data ][ SubjectUserName] =~ /\ $$ /{ drop{} } # Eliminar eventos porducidos por usuarios del sistema if [user][ name]in ["UMFD-10","DWM-10"]{ drop{} } # Eliminar eventos de directorios de red por defecto if [winlog][ event_data ][ ShareName ]in [" \\*\ ADMIN$"," \\*\ C$","\\*\IPC$", " \\*\ NETLOGON "," \\*\ SYSVOL "]{ drop{} } # Eliminar eventos producidos por procesos del sistema if [process][ name]in [" tentacle_client .exe ","PandoraAgent.exe", "autodiscover.exe"," LocalBridge .exe "," SearchApp . exe","MicrosoftEdgeUpdate.exe", " MsMpEng . exe "," svchost . exe" ," packetbeat . exe "," wmiprvse .exe ", " CompatTelRunner . exe","SystemSettings.exe"," backgroundTaskHost . exe" , " StartMenuExperienceHost . exe"," TiWorker . exe"," SearchUI . exe", "ShellExperienceHost.exe"," ServerManager .exe "," conhost .exe "]{ drop{} } if [process][ parent][ executable ] == "C :\ Windows \ System32 \ svchost .exe "{ drop{} } # Formatear campos xml if [winlog][ event_id ] == 4698 { xml { 54 source => "[ winlog ][ event_data ][ TaskContent ]" store_xml => false remove_namespaces => true xpath => ["// Command / text () ","TaskCommand"] xpath => ["// URI / text ()"," TaskName "] xpath => [" // Author / text ()" ," TaskAuthor "] } } } } output { elasticsearch { hosts =>[" localhost :9200 " ] } } sysmon.xml <Sysmon schemaversion =" 4.50 "> <HashAlgorithms>SHA256</HashAlgorithms> <EventFiltering> <!-- No crear eventos de finalizaci ´on de procesos -- > <ProcessTerminate onmatch="include" /> <!-- Detecar volcado de memoria a lsass. exe --> <ProcessAccess onmatch="include"> <TargetImage condition =" image " >lsass .exe </ TargetImage> </ ProcessAccess > <!-- Filtrar los procesos del sistema --> <ProcessAccess onmatch="exclude"> <SourceImage condition =" contains "> svchost </ SourceImage> <SourceImage condition =" contains "> wmiprvse </ SourceImage> <SourceImage condition =" contains "> MsMpEng </ SourceImage> <SourceImage condition =" contains "> packetbeat </ SourceImage> </ ProcessAccess > <!-- Detecar cambios en la fecha de creacion de ficheros --> <FileCreateTime onmatch="exclude"> <Image condition =" contains "> LogonUI </ Image > <Image condition =" contains "> MpSigStub </ Image > <Image condition =" contains ">msedge</Image > </ FileCreateTime> </ EventFiltering> </ Sysmon> 55 ANEXO III Eventos monitorizados Sysmon ID Evento Descripci´on 1 creacion de proceso 2 Un proceso ha cambiado la fecha de creacion de un fichero 4 El estado del servicio sysmon ha cambiado 8 Creado hilo remoto 9 Acceso de datos en crudo 10 un proceso ha accedido a otro proceso 11 Creacion de fichero 12 Objeto del registro creado 13 Objeto del registro escrito 14 Objeto del registro renombrado 22 Consulta DNS 23 Eliminacion de fichero 25 Manipulada la imagen de un proceso 57 Cuentas de usuario ID Evento Descripci´on 4624 Una cuenta ha iniciado sesi´on 4625 Una cuenta ha fallado un inicio de sesi´on 4720 Se ha creado una cuenta de usuario 4722 Se ha activado una cuenta de usuario 4723 Se ha intentado cambiar la contrase˜na de una cuenta de usuario 4724 Se ha intentado reiniciar la contrase˜na de una cuenta de usuario 4725 Se ha desactivado una cuenta de usuario 4726 Se ha eliminado una cuenta de usuario 4738 Se ha modificado una cuenta de usuario 4740 Se ha bloqueado una cuenta de usuario 4767 Se ha desbloqueado una cuenta de usuario 4781 Se ha modificado el nombre de una cuenta de usuario 4782 Se ha accedido al hash de la contrase˜na de una cuenta de usuario 4794 Se ha intentado establecer la contrase˜na de administrador del modo de recuperaci´on de Active Directory 4798 Se ha enumerado la pertenencia a grupos de una cuenta de usuario 5376 Se ha creado una copia de seguridad de las credenciales del gestor de credenciales Grupos ID Evento Descripci´on 4731 Se ha creado un grupo de seguridad 4732 Se ha a˜nadido un miembro a un grupo de seguridad 4733 Se ha eliminado un miembro a un grupo de seguridad 4734 Se ha eliminado un grupo de seguridad 4735 Se ha modificado un grupo de seguridad 4764 Se ha modificado el tipo de un grupo 4799 Se han enumerado los miembros de un grupo de seguridad Recursos compartidos ID Evento Descripci´on 5140 Se ha accedido a un objeto compartido 5142 Se ha creado un objeto compartido 5143 Se ha modificado un objeto compartido 5144 Se ha eliminado un objeto compartido 58 Ficheros y claves del registro ID Evento Descripci´on 4656 Se ha solicitado acceso a un objeto 4657 Se ha modificado un valor del registro 4663 Se ha intentado acceder a un objeto 4670 Se han modificado los permisos de un objeto Firewall ID Evento Descripci´on 5025 Se ha detenido el Firewall de Windows 5030 El servicio de Firewall de Windows no se ha podido iniciar 5034 Se ha detenido el driver del Firewall de Windows 5035 No se ha podido iniciar el driver del Firewall de Windows Registro de eventos ID Evento Descripci´on 1100 Se ha detenido el servicio de registro de eventos 1102 Se ha eliminado el registro de auditor´ıa Ejecuci´on autom´atica ID Evento Descripci´on 4697 Se ha instalado un servicio en el sistema 4698 Se ha creado una tarea programada 4699 Se ha eliminado una tarea programada 4700 Se ha activado una tarea programada 4701 Se ha desactivado una tarea programada 4702 Se ha actualizado una tarea programada 59 Auditor´ıa ID Evento Descripci´on 4715 Se ha modificado la pol´ıtica de auditoria de un objeto 4719 La pol´ıtica de auditoria del sistema se ha cambiado 4817 La configuraci´on de auditoria de un objeto se ha cambiado Active Directory ID Evento Descripci´on 5136 Se ha modificado un objeto de Active Directory 5137 Se ha creado un objeto de Active Directory 5138 Se ha recuperado un objeto de Active Directory 5139 Se ha movido un objeto de Active Directory 5141 Se ha eliminado un objeto de Active Directory 60