Diseño de un Entorno Open Source para Análisis Automatizados de Malware

Equation Chapter 1 Section 1 Trabajo Fin de Grado Grado de Ingeniería de las Tecnologías de Telecomunicación Diseño de un Entorno Open Source para Análisis Automatizados de Malware Autor: Manuel Martín Gutiérrez Tutor: Francisco Javier Muñoz Calle Dpto. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 iii iii Diseño de un Entorno Open Source para Análisis Automatizados de Malware Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Diseño de un Entorno Open Source para Análisis Automatizados de Malware Autor: Manuel Martín Gutiérrez Tutor: Francisco Javier Muñoz Calle Profesor Colaborador Dep. de Ingeniería Telemática Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2019 v v Diseño de un Entorno Open Source para Análisis Automatizados de Malware Trabajo Fin de Grado: Diseño de un Entorno Open Source para Análisis Automatizados de Malware Autor: Manuel Martín Gutiérrez Tutor: Francisco Javier Muñoz Calle El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: Sevilla, 2019 El Secretario del Tribunal vii vii Diseño de un Entorno Open Source para Análisis Automatizados de Malware La memoria de este trabajo se distribuye bajo la licencia GNU GPL v3. La Licencia Pública General de GNU es una licencia libre, sin derechos para software y otros tipos de trabajos. Las licencias para la mayoría del software y otros trabajos prácticos están diseñadas para suprimir la libertad de compartir y modificar los trabajos. Por el contrario, la Licencia Pública General de GNU pretende garantizar su libertad para compartir y modificar todas las versiones de un programa -- y garantizar que siga siendo software libre para todos sus usuarios. Nosotros, la Fundación para el Software Libre, utilizamos la Licencia Pública General de GNU para la mayoría de nuestro software; se aplica también a cualquier otro trabajo publicado de esta manera por sus autores. También puede aplicarlo a sus programas. Cuando hablamos de software libre, nos referimos a la libertad, no al precio. Nuestras Licencias Públicas Generales están diseñadas para asegurar que tiene la libertad de distribuir copias de software libre (y cobrar por ellas si lo desea), de recibir el código fuente o de poder obtenerlo si lo desea, de modificar el software o usar partes del mismo en nuevos programas libres y de saber que puede hacer estas cosas. Para conseguir más información sobre la licencia y sus términos se pueden seguir los siguientes enlaces: • Información general en castellano: https://www.gnu.org/licenses/licenses.es.html • Licencia original en inglés: https://www.gnu.org/licenses/gpl.html ix ix Diseño de un Entorno Open Source para Análisis Automatizados de Malware There is nothing so stable as change. Bob Dylan xvii xvii Diseño de un Entorno Open Source para Análisis Automatizados de Malware Índice Agradecimientos xi Resumen xiii Abstract xv Índice xvii Índice de Tablas xxi Índice de Figuras xxiv Notación xxvii 1 Introducción 29 1.1 Motivación 29 1.2 Objetivos 30 1.3 Fases del trabajo 31 2 Fundamentos de Malware 33 2.1 Tipología 34 2.1.1 Dropper – Downloader 34 2.1.2 Rogue software 34 2.1.3 Troyano y Remote Administration Toolkit (RAT) 34 2.1.4 Rootkit 34 2.1.5 Gusano 35 2.1.6 Virus 35 2.2 Propósitos 35 2.2.1 Obtener beneficios económicos directos 35 2.2.2 Dañar los activos comprometidos 35 2.2.3 Robar información 36 2.3 Vectores de ataque 36 2.4 Activadores 36 2.4.1 Básicos 37 2.4.2 Indicadores de entorno virtual 37 2.4.3 Temporizadores 37 2.4.4 Señales provenientes del C&C 37 2.4.5 Actividad del usuario 37 2.5 Amenaza persistente avanzada – APT 38 2.5.1 Fases 38 2.6 Análisis 39 2.6.1 Estático 39 2.6.2 Dinámico 40 2.7 Información de amenazas 40 2.7.1 OpenIOC 41 2.7.2 CybOX – MAEC – STIX 41 2.7.3 TAXII 42 3 Diseño de la Arquitectura 43 3.1 Tecnologías 44 3.1.1 Monitorización de red y extracción de ficheros 44 3.1.2 Motores de antivirus 45 3.1.3 Sandboxing 46 3.1.4 Gestión e intercambio de información de amenazas 48 3.2 Disposición de componentes 49 3.3 Modelo para pruebas 50 3.3.1 Máquinas Virtuales 50 3.3.2 Redes virtuales 52 3.3.3 Esquema del modelo 52 4 Diseño de la Solución 55 4.1 Características 56 4.2 Atributos de calidad 56 4.3 Diagrama de flujo 56 4.4 Programación en Bash 58 4.4.1 Programación defensiva 58 4.5 Aspectos a destacar 60 4.5.1 Monitorización de las llamadas al sistema dentro un directorio 61 4.5.2 Gestión de la salida estándar y de la salida de error 61 4.5.3 Gestión de errores 61 4.5.4 Gestión de subprocesos 62 4.5.5 Gestión de contenedores de Docker 63 4.5.6 Gestión del cierre del programa – Señales 65 4.6 Licencia del programa 65 5 Validación y Resultados 67 5.1 Objetivo del Proyecto – Problema Inicial a Resolver 67 5.2 Requisitos 68 5.3 Riesgos Potenciales 68 5.4 Análisis de Riesgos 70 5.4.1 Clasificación de Riesgos 70 5.4.2 Control de Riesgos 71 5.5 Validación de la Solución 73 5.5.1 Tareas de la sesión de validación 73 5.5.2 Criterio de aceptación 73 5.5.3 Escenario de las Pruebas 73 5.5.4 Formato de los casos y procedimientos 75 xix xix Diseño de un Entorno Open Source para Análisis Automatizados de Malware 5.5.5 Casos, procedimientos y resultados 75 5.6 Aceptación de la Solución 81 6 Lineas de Mejora 85 6.1 Funcionalidades de la solución desarrollada 85 6.2 Funcionalidades de las herramientas del entorno 86 6.3 Arquitectura 86 6.4 Apariencia 86 7 Conclusiones 89 7.1 Malice – Malware Analysis Framework 90 7.2 Cuckoo Sandbox 90 7.3 MISP (Malware Information Sharing Platform) 90 Bibliografía 91 Índice de Conceptos 93 Glosario 94 Anexo A: Docker Community Edition 97 Instalación de Docker Community Edition 97 Cambiar el controlador de almacenamiento de Docker a Overlay2 98 Anexo B: Malice - Malware Analysis Framework 101 Instalación de Malice - Malware Analysis Framework 101 Desinstalación de Malice - Malware Analysis Framework 101 Configuración Inicial Malice - Malware Analysis Framework 102 Anexo C: Cuckoo Sandbox 2.0 109 Instalación de Cuckoo Sandbox Host 109 Instalación y configuración de Cuckoo Sandbox Guests 113 Creación de Cuckoo Guests manualmente 113 Creación de Cuckoo Guests mediante VMCloak 115 Configuración inicial Cuckoo Host 116 Arranque inicial Cuckoo Sandbox 120 Integración con MISP 120 Anexo D: Bro Network Security Monitor 123 Configuración: Extraer archivos del tráfico de red 123 Anexo E: ninjaMind 127 Anexo F: Presupuesto 141 xxi xxi Diseño de un Entorno Open Source para Análisis Automatizados de Malware Índice de Tablas Tabla 1-1. Fases del trabajo 32 Tabla 5-1. Relación requisitos-riesgos 69 Tabla 5-2. Clasificación de riesgos: Clase 70 Tabla 5-3. Clasificación de riesgos: Prioridad 70 Tabla 5-4. Clasificación de riesgos 71 Tabla 5-5. Control de Riesgos 72 Tabla 5-6. Formato de los casos 75 Tabla 5-7. Formato de los procedimientos 75 Tabla 5-8. Caso PR-I-01 76 Tabla 5-9. Procedimiento PR-I-01-001 76 Tabla 5-10. Caso PR-I-02 76 Tabla 5-11. Procedimiento PR-I-02-001 76 Tabla 5-12. Caso PR-I-03 77 Tabla 5-13. Procedimiento PR-I-03-001 77 Tabla 5-14. Caso PR-I-04 77 Tabla 5-15. Procedimiento PR-I-04-001 77 Tabla 5-16. Caso PR-T-01 78 Tabla 5-17. Procedimiento PR-T-01-001 78 Tabla 5-18. Procedimiento PR-T-01-002 79 Tabla 5-19. Procedimiento PR-T-01-003 79 Tabla 5-20. Procedimiento PR-T-01-004 79 Tabla 5-21. Procedimiento PR-T-01-005 79 Tabla 5-22. Procedimiento PR-T-01-006 80 Tabla 5-23. Procedimiento PR-T-01-007 80 Tabla 5-24. Aceptación de la solución: Matriz de trazabilidad 82 Tabla F-1. Presupuesto del proyecto 142 xxiii xxiii Diseño de un Entorno Open Source para Análisis Automatizados de Malware Índice de Figuras Figura 3-1. Ejemplo de la arquitectura básica de Cuckoo Sandbox 47 Figura 3-2. Ejemplos de uso de MISP 49 Figura 3-3. Componentes del entorno y sus interacciones 50 Figura 3-4. Esquema de red del modelo virtual 53 Figura 4-1. Diagrama de flujo de la solución 57 Figura 4-2. Mensaje de ayuda de ninjaMind 60 Figura 5-1. Prioridad de los riesgos: Sumario 71 Figura 5-2. Escenario de las pruebas 74 Figura 5-3. Validación de los requisitos: Sumario 83 Figura B-0-1. Plugins de Malice instalados 107 Figura B-0-2. Configuración de Malice-Kibana primer acceso 108 Figura B-0-3. Ver análisis de prueba en Malice-Kibana primer acceso 108 Figura C-0-1. Obtener API key de MISP 121 xxv xxv Diseño de un Entorno Open Source para Análisis Automatizados de Malware Introducción 32 Tabla 1-1. Fases del trabajo Fases Semanas 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Investigación 20 h 20 h 20 h 20 h 10 h 10 h Diseño 10 h 10 h 20 h 10 h Implementación 10 h 20 h 20 h 20 h 20 h 10 h Experimentación 10 h 10 h Documentación 10 h 20 h 2 FUNDAMENTOS DE MALWARE a palabra “malware” proviene del concepto anglosajón “malicious software”. Se usa como término genérico para denominar a cualquier software que cumpla de forma deliberada la intención dañina de su creador. Por lo tanto, no se considera malware todo aquel software defectuoso que, aun teniendo comportamientos peligrosos, se deban a errores durante su programación inintencionados. Durante este capítulo se sentará la base de conocimiento sobre la que se desarrolla el trabajo realizado en el resto del proyecto. En determinados casos, se utilizarán términos en inglés debido al escaso uso de sus traducciones en español para hacer referencia a ellos. De esta manera se facilita encontrar más información acudiendo a diferentes fuentes si se desea. Antes de seguir, es necesario definir qué es un “Command & Control”. Abreviaturas habituales del término son C&C y C2. Se trata servidores que gestionan las comunicaciones con las máquinas comprometidas a través del malware instalado. Por un lado, el envío de órdenes y por otro, la recepción de datos de la víctima. L So you run and you run to catch up with the sun, but it's sinking racing around to come up behind you again. Roger Waters, Pink Floyd Fundamentos de Malware 34 2.1 Tipología En base al comportamiento del malware y al objetivo con el que han sido desarrollados, es decir, cómo y a qué afectan, se detallan a continuación los principales tipos. Debido a que una misma muestra puede realizar diversas actividades en función de la fase en la que se encuentre, los grupos que se describen en este apartado no son excluyentes entre sí. 2.1.1 Dropper – Downloader Suelen ser sencillos programas cuyo único objetivo es instalar malware adicional. Normalmente pertenecen a la primera fase de un ataque y se quedan permanentemente en el sistema para insertar más malware en un futuro. La principal diferencia entre los Droppers y los Downloaders es que los primeros traen consigo el malware a instalar y los otros se conectan a un servidor remoto para descargarlo. La URL puede venir predefinida en el código o generarse automáticamente mediante el uso de algoritmos. 2.1.2 Rogue software Este tipo de herramientas se publicita como software pare prevenir y/o limpiar infecciones por malware y su principal objetivo es conseguir que el usuario realice un pago. Un detalle importante para distinguir a la mayoría de ellas es que no tienen un nombre de producto, una marca, para identificarse. En cambio, utilizan nombres genéricos como “Anti-Malware Tool”, “Malware Cleaner”, etc. No todas las muestras de este tipo instalan malware de forma paralela al programa principal, pero sí que contactan con sus respectivos C&C con el fin de poder vender posteriormente la infección mediante el uso actualizaciones automáticas. Son altamente peligrosas porque pueden afectar a la continuidad del negocio. Una de sus variantes es el ransomware, que hace imposible el uso de la máquina bloqueándola y genera un aviso pidiendo un pago por parte del usuario para liberarla. Hoy en día, en la mayoría de los casos cifran los datos del disco duro en segundo plano mientras muestran el aviso para pagar. A cambio, ofrecen la clave que devuelve el acceso a la información, aunque normalmente no se facilita ni cediendo a la extorsión y realizando el pago. 2.1.3 Troyano y Remote Administration Toolkit (RAT) Están diseñados para tomar el control sobre la máquina comprometida. El objetivo es conseguir toda la información posible mediante la exfiltración de datos. Suelen requerir la interacción del usuario para iniciarse. Existen RATs prefabricados para comercializar con ellos y posteriormente poder ser personalizados. Ésa es una de las causas de que haya bastante disparidad en la sofisticación de las muestras encontradas pertenecientes a este tipo. 2.1.4 Rootkit Son muy sigilosos y sofisticados. Suelen trabajar a nivel de los controladores, lo que los hace bastante complicados de detectar y eliminar. Esta misma razón es la que provoca que sean difíciles de desarrollar y requieran una buena inversión de tiempo, ya que un error en los controladores podría tumbar el sistema por completo. Uno de los usos más frecuentes es esconder la actividad de otros tipos de malware. En el caso de los denominados RATs, podría encubrir de cara al sistema conexiones creadas desde un determinado puerto. El único método capaz asegurar por completo una desinfección de esta categoría es formatear el disco y reinstalar el sistema operativo. En muchas de las muestras no es suficiente con sólo reinstalar el sistema operativo porque afectan a la partición de arranque y serían capaces de reinstalar el malware al volver a iniciar 35 35 Diseño de un Entorno Open Source para Análisis Automatizados de Malware la máquina. 2.1.5 Gusano Su principal característica es que se difunden de forma rápida y automática. Hacen uso de diferentes métodos de propagación como discos extraíbles, correos electrónicos, la red, etc. Por lo tanto, rara vez se ven sin contener algunas de las funcionalidades pertenecientes al resto de categorías. Su capacidad para extenderse a lo largo de una organización los hace realmente peligrosos y, sobre todo, difíciles de erradicar por completo. Hace tiempo eran típicas las muestras de este tipo que se realizaban sólo con el fin de molestar al usuario mostrando algún mensaje o reproduciendo música. En la actualidad, no suele ocurrir esto y normalmente están asociadas a motivos relacionados con los del resto de malware. 2.1.6 Virus Se trata de ejecutables que infectan a otros ejecutables del sistema o a los sectores de arranque del disco. A día de hoy, es menos común que afecten a los sectores de arranque a excepción de si tienen una componente de tipo rootkit. De hecho, es probable que cuenten con funcionalidades de las otras categorías como droppers y downloaders, troyanos y RATs, etc. Suelen ser bastante dañinos y como método de desinfección se recomienda un formateo del disco y una reinstalación completa del sistema operativo. Esto se debe a que buscan ejecutables y DLLs para infectarlos e incluso aunque se eliminen todas las copias en memoria, podrían volver a cargar su contenido en la máquina al ejecutar algún programa que no hubiese sido limpiado. 2.2 Propósitos En los siguientes subapartados se detallan los principales propósitos que puede tener un determinado malware. En el primero de ellos se especifica que los beneficios económicos son directos porque a través de los otros dos también se podrían acabar consiguiendo. Dañar a alguna víctima concreta o robar información confidencial podría generar ganancias derivadas de estas acciones. 2.2.1 Obtener beneficios económicos directos Para conseguir ganancias se usan dos métodos: • Robar información bancaria: tarjetas, pins, credenciales de banca online, etc. o Según la variante de malware, es posible que ni siquiera importe qué tipo de cifrado use la página web del banco. Esto se debe a que consigue la información directamente de la memoria inyectando código en el proceso del navegador. • Engañar o forzar al usuario para que realice pagos. o Se basan en rogue software, normalmente en ransomware, utilizando el procedimiento detallado en el apartado anterior. 2.2.2 Dañar los activos comprometidos Consiste en causar la indisponibilidad de un servicio, máquina o incluso una organización. Esta era la motivación original cuando se comenzó a diseñar malware en la década de los 70. Podía venir derivada de la búsqueda de notoriedad y de la demostración de habilidades por parte del desarrollador. Ejemplos típicos de ello eran los programas encargados de modificar el arranque para mostrar algún mensaje indicando que había Fundamentos de Malware 36 sido comprometido. El ejemplo más famoso hasta la fecha en este ámbito se dio en 2010 y se corresponde con el malware llamado Stuxnet. Tenía como objetivo la infraestructura nuclear iraní y consiguió causar daños importantes en los sistemas industriales de la central nuclear de Natanz. 2.2.3 Robar información Suele ser malware usado para atacar de forma dirigida a una organización concreta y estar específicamente diseñado para tener éxito en ella. Esto conlleva que, en la mayoría de los casos, sean muestras nunca vistas anteriormente. El objetivo principal es hallar y exfiltrar datos relativos a la propiedad intelectual de la víctima. En general, conllevan ataques complejos que dependen de diferentes fases. Normalmente se les relaciona con las amenazas persistentes avanzadas. En los próximos apartados se entrará en detalle a estudiar la naturaleza de este tipo de amenazas. 2.3 Vectores de ataque Los vectores de ataque son las localizaciones, respecto al sistema amenazado, en las que se explotan las vulnerabilidades, ej.: red, local, etc. Éstas son utilizadas por los atacantes para acceder a sus víctimas. Varias de ellas se sirven de la ingeniería social. Dicho término hace referencia al conjunto de técnicas y herramientas usados para conseguir engañar al usuario y que facilite la infección de la organización a la que pertenece. Las interacciones del usuario pueden desencadenar la fuga de información o que el atacante tenga éxito con alguno de los otros objetivos descritos anteriormente. Los vectores más comunes a día de hoy se encuentran descritos a continuación: • Red: Se trata de evadir la seguridad perimetral y comprometer a la organización a través de vulnerabilidades explotables de forma remota. Tecnologías normalmente afectadas son: o Servicios disponibles: Ejemplos de este tipo son el DNS, los volúmenes compartidos, etc. o Navegación web: Consiste en hacer uso de vulnerabilidades en las aplicaciones web, de descargas de malware directamente al equipo o de infectar al propio navegador. • Local: Se trata de evadir la seguridad en los equipos finales y comprometer a la organización a través de vulnerabilidades explotables de forma local. Tecnologías normalmente afectadas son: o Correo Electrónico: Se suele enviar malware adjunto o a través de enlaces en el cuerpo del correo. Mediante ingeniería social, se busca que el destinatario caiga en la trampa y libere la muestra en su entorno. o Dispositivos extraíbles: Un ejemplo de esta vía suele ser la infección mediante un dispositivo de almacenamiento extraíble. Una vez conectado al puerto USB del equipo, libera el malware. Al igual que mediante el correo electrónico, en la mayoría de los casos conlleva una importante componente de ingeniería social para conseguir que el usuario realice la acción necesaria, como insertar el dispositivo USB en este caso. 2.4 Activadores En busca de hacer el malware lo más difícil posible de detectar, existe la posibilidad de diseñarlo para permanecer inactivo hasta que se produzcan ciertas condiciones. Muchas de ellas están destinadas a evitar que el malware se active en una máquina virtual. Esta lista puede ser muy extensa y pormenorizada si se llega a bajo nivel, tanto que se saldría del alcance de estas primeras nociones sobre malware. Es interesante conocer las más frecuentes de cara a saber las 37 37 Diseño de un Entorno Open Source para Análisis Automatizados de Malware limitaciones e incluso a implementar posibles contramedidas en el entorno virtual. Por lo tanto, se describen a continuación los grupos más comunes de medidas que utilizan para intentar pasar desapercibidos en los análisis. 2.4.1 Básicos En este grupo encontramos, en mayor medida, dos tipos de condiciones para que se inicie el malware: • Parámetros de ejecución: Sólo se iniciará después de que se haya ejecutado con unos determinados parámetros de la línea de comandos. • Reinicio: Sólo se iniciará después de un reinicio completo de la máquina en la que se encuentra. 2.4.2 Indicadores de entorno virtual • Detección de hardware: Comprobación de diversos aspectos indicadores de que la máquina es virtual, por ejemplo, la dirección MAC. • Detección de claves del registro: Relacionado con el anterior, pero enfocado en el registro de Windows, ya que por defecto hay algunas claves indicadoras de que se encuentra en una máquina virtual. 2.4.3 Temporizadores A veces, la muestra iniciará su actividad después de que se cumpla alguna condición temporal. Éstas suelen ser de los siguientes tipos: • Tiempo inicial de inactividad: Sólo se iniciará después de que pase un determinado tiempo (horas, días, semanas, meses) desde que se produzca su instalación. • Ejecución en un determinado momento: Soló iniciará su actividad a una hora y/o en una fecha específica. 2.4.4 Señales provenientes del C&C En algunas ocasiones, el malware no comenzará a desarrollar su comportamiento hasta que no reciba instrucciones específicas de su correspondiente servidor de Command and Control. En función de lo que el servidor le mande, podría comenzar a exfiltrar información, a tratar de hacer uso de una vulnerabilidad, etc. Por eso, en la mayoría de los casos, no sería suficiente con enviarle una señal cualquiera simulando ser su Command & Control. 2.4.5 Actividad del usuario Diversos desarrollos de malware pueden ser diseñados para permanecer inactivos hasta que detecten eventos que denoten la interacción de un usuario real con el sistema. Algunos ejemplos que confirman la existencia de un usuario y, por lo tanto, de un entorno físico son: • Actividad del ratón • Pulsaciones de teclas • Manipulación de ventanas Fundamentos de Malware 38 2.5 Amenaza persistente avanzada – APT Las amenazas persistentes avanzadas, normalmente conocidas como APT (Advanced Persistent Threat), son ataques muy complejos. Estos cuentan con un estudio previo de la organización en el punto de mira y un elaborado diseño por fases para conseguir no ser detectadas. Otro de los aspectos que las caracterizan es que están totalmente personalizadas para desenvolverse en el entorno de la víctima y, en gran parte de las ocasiones, hacen uso de 0-days. Los ataques de tipo 0-day se basan en explotar vulnerabilidades no conocidas hasta entonces ni por el fabricante ni por el público en general. Si se tienen en cuenta todas las características aportadas, es fácil llegar a la conclusión de que prácticamente todas las amenazas persistentes avanzadas son de naturaleza desconocida, nunca vistas anteriormente. Esto supone todo un reto no sólo para detectarlas, sino también para categorizarlas y analizarlas. Se podrían ver motivadas por cualquiera de los principales propósitos descritos previamente, pero lo habitual es que su finalidad sea hallar y exfiltrar datos relativos a la propiedad intelectual de la víctima. 2.5.1 Fases Antes de entrar en detalle con cada una de las fases, es necesario indicar que no siempre los ataques basados en amenazas persistentes avanzadas las ejecutan todas. De hecho, en ocasiones un ataque se sirve de comprar la información sobre una determinada organización obtenida mediante otros ataques previos realizados con el objetivo de comercializar los accesos conseguidos. 2.5.1.1 Reconocimiento Se descubren las vulnerabilidades de la futura organización víctima y se obtiene toda la información posible que sea de dominio público. Se llega incluso a conseguir información personal de empleados a través de las redes sociales. Con esto se acaba elaborando una base sobre la que empezar a diseñar el malware. 2.5.1.2 Infección Se comienza la intrusión haciendo uso de uno o varios de los vectores de ataque descritos en este capítulo. Una vez dentro, suelen establecer una puerta trasera por la que descargar malware adicional, ya que en esta fase lo habitual es que sean sencillas muestras de tipo dropper – downloader. 2.5.1.3 Operación Se explotan las vulnerabilidades del entorno, es decir, del sistema, de la red interna, etcétera. Además, se intenta expandir la infección a la mayor parte posible de la organización buscando activos valiosos y vulnerabilidades en diferentes sistemas. Con ello se pretende hallar credenciales de usuarios con suficientes privilegios, establecer las conexiones necesarias con el exterior y desplegar todas las herramientas necesarias para llevar a cabo su cometido. 2.5.1.4 Exfiltración Una vez que ya se tiene desplegado el malware, se ha encontrado la localización de la información sensible y se ha conseguido la forma de acceder a ella, comienza el verdadero propósito del ataque. En primer lugar, se prepara la información cifrándola y comprimiéndola. Una vez que esté lista, se envía al servidor de Command and Control. 39 39 Diseño de un Entorno Open Source para Análisis Automatizados de Malware 2.5.1.5 Persistencia Con la información sensible ya en manos de los responsables del malware y el objetivo conseguido, se eliminan las evidencias del ataque, pero no se desarticula el complejo diseño desplegado a lo largo de la organización. Al contrario, se continúa creando puertas traseras adicionales, analizando los datos recopilados, infectando nuevos sistemas, etc. 2.6 Análisis Con los análisis de malware se pretende sacar la suficiente información de una muestra como para averiguar el riesgo que conlleva. Hay diferentes métodos para conseguir información sobre de qué tipo es, el propósito que tiene, a qué va dirigido… Los desarrolladores de malware son conscientes de ello, por lo que se esmeran en crear mecanismos cada vez más elaborados y sofisticados para evitar ser detectados durante la realización de los análisis. No obstante, fabricantes y profesionales del sector intentan implementar todas las medidas posibles para contrarrestar a estos mecanismos y seguir detectado el mayor número de muestras posibles. Es una lucha constante, aunque habitualmente el malware es el que lleva la delantera. La gran diversidad de opciones existentes para analizar una muestra se puede dividir en dos grandes grupos: análisis estático y análisis dinámico. 2.6.1 Estático Este grupo de análisis se centra en sacar toda la información posible de una muestra sin ejecutarla. Los tipos de informaciones que se suelen obtener con este método son: • Tipo de archivo • Dependencias de librerías u otras herramientas • Metadatos • Cadenas que lo identifiquen • Firmas Precisamente las firmas son el primer valor que se trata de conseguir, ya que es la “huella digital” de un determinado archivo. Existen diferentes funciones de un solo sentido para generar la firma en base a su complejidad, algunos ejemplos son md5, sha-1 y sha-256. La mayor diferencia entre ellos es el número de bits usados para generar la firma. Éste es el método usado por productos de seguridad como los antivirus. Si en su base de datos se encuentra la firma de la amenaza, detectan rápidamente a la muestra. En cambio, si la amenaza no es conocida por el fabricante del motor de antivirus y, por tanto, no tienen su firma, serán incapaz de detectarla. 2.6.1.1 Aspectos relevantes Ventajas: • Rapidez de detección si la amenaza es conocida. • Bajos requisitos computacionales. Inconvenientes: • Inutilidad a la hora de detectar amenazas vistas por primera vez. • Necesita de un tiempo de reacción por parte de los fabricantes para que generen la firma de una nueva Fundamentos de Malware 40 amenaza. 2.6.2 Dinámico Al contrario que el análisis estático, éste grupo centra su método de obtener información en ejecutar la muestra y observar su comportamiento. Los aspectos más determinantes son los relativos a la interacción del ejecutable tanto con el sistema en el que se encuentra como con sistemas remotos a través de la red. Estas interacciones se pueden dividir en diferentes ámbitos en función de contra qué se realicen: • Otros procesos • Sistema de ficheros • Registro de Windows • Llamadas a la API del sistema • Actividad a través de las interfaces de red A la hora de crear un entorno que tenga como uso exclusivo analizar el comportamiento del malware, se pueden valorar diferentes planteamientos. Todos ellos se basan en el concepto de sandbox, entorno completamente aislado del resto de la infraestructura en el que poder liberar las muestras para que desarrollen toda su actividad programada. Siendo los requisitos tener un entorno aislado siempre en el mismo punto de partida para cada nueva muestra de malware, queda claro que utilizar máquinas virtuales y sus snapshots los cubre a la perfección. No sólo eso, sino que además automatiza todo el tedioso proceso de deshacer los cambios introducidos por la última muestra analizada. Como contrapartida, hay que tener en cuenta los activadores descritos anteriormente en este capítulo. Son utilizados por el malware para saber si se encuentran en un entorno virtual y permanecer inactivos. 2.6.2.1 Aspectos relevantes Ventajas: • Capaces de detectar amenazas desconocidas dejando que se ejecuten libremente dentro del entorno de análisis y estudiando su comportamiento. • Su capacidad de detección no depende directamente de actualizaciones de la base de datos de información por parte de los fabricantes. Inconvenientes: • El tiempo que se necesita por muestra para terminar el análisis no es despreciable. Incluso en entornos completamente automatizados puede tardar del orden de 3-5 minutos de media. • Se necesita un hardware completo dedicado o, en el caso de ser un entorno virtual, un anfitrión con altos requisitos de procesamiento y memoria para dar cabida a las diferentes máquinas virtuales analizadoras. 2.7 Información de amenazas Tras realizar diversos análisis, se empieza a acumular información sobre las muestras de malware conocidas. Ésta va desde firmas hasta características muy concretas del comportamiento como ficheros que escribe en un determinado directorio del sistema, entradas del registro que modifica, URLs con las que conecta, etc. Es en este momento cuando surgen cuestiones como: • “¿En qué formato se almacena?” 41 41 Diseño de un Entorno Open Source para Análisis Automatizados de Malware • “¿Es sólo para consumo propio o puede ser útil compartirla?” • “¿Se puede recibir información extra de amenazas de fuentes externas?” • “¿Existe algún estándar para poder intercambiar información usando la misma notación?” En primer lugar, sí, es muy útil compartir la información obtenida de amenazas analizadas. Lo es tanto como recibir actualizaciones de los resultados generados por fuentes de confianza que completen la nuestra. Para ello, se introduce el concepto de IOC (Indicator Of Compromise), indicador de compromiso. Hace referencia a toda aquella información relevante para describir atributos estáticos o dinámicos de una determinada muestra. Proviene de la idea de que, si se analiza un sistema y se encuentran los detalles recogidos en un indicador de compromiso concreto, se está ante una infección provocada por el malware al que hace referencia dicho indicador de compromiso. En segundo lugar, sí, existen sintaxis ya diseñadas para describir la información recopilada sobre las amenazas. El problema es que a día de hoy el sector está en un punto demasiado prematuro en este ámbito como para tener una única sintaxis universal. Se encuentran varias opciones, todas ellas abiertas y de uso público, intentos de conseguir una estandarización. En los siguientes subapartados se dan unas breves pinceladas sobre las alternativas más extendidas. 2.7.1 OpenIOC OpenIOC (Open Indicator Of Compromise) es un formato creado por Mandiant, una compañía perteneciente al grupo empresarial FireEye. Se puede decir que son los precursores del concepto de indicador de compromiso y, sobre todo, de la implantación de su uso a gran escala en la gestión de información sobre amenazas y la respuesta a incidentes. Está definido por un esquema XML y aunque en un primer momento era una herramienta interna de sus creadores, a día de hoy está abierto su uso. Ventajas: • Está más orientado a los detalles técnicos, lo que lo hace muy útil para describir los resultados de un análisis de malware. • Hay disponibles herramientas libres para facilitar su uso desarrolladas por los propios creadores: o IOC Editor: Facilita la edición de los XML para generar y modificar indicadores de compromiso. o IOC Finder: Busca en el sistema cualquier rastro de los indicadores de compromiso que se le faciliten en una lista y reporta su presencia si los encuentra. Inconvenientes: • No sirve para detallar aspectos a más alto nivel como vectores de ataque y tácticas seguidos por el malware. • Menos flexibilidad de integración. Queda patente que en sus inicios estaba enfocado en detallar la información de los productos de un solo fabricante. 2.7.2 CybOX – MAEC – STIX Son formatos que tienen su origen en MITRE, una organización sin ánimo de lucro centrada en desarrollos tecnológicos colaborativos. Se ha apoyado en organizaciones gubernamentales de Norte América, como el CERT de los Estados Unidos, para ir planteando diversos intentos de conseguir un estándar a lo largo de los últimos años. Comenzaron con CybOX (Cyber Observable eXpression), definido en JSON, y posteriormente desarrollaron STIX (Structured Threat Information Expression). Éste estaba basado principalmente en el primero, pero mejoraba la representación de los objetos y de las relaciones existentes entre ellos. En la actualidad, CybOX ha sido integrado por completo en STIX y ya no se recomienda su uso. En paralelo a STIX, también se basaron en CybOX para desarrollar MAEC (Malware Attribute Enumeration Diseño de la Arquitectura 48 disponibles en los siguientes enlaces: https://github.com/cuckoosandbox/cuckoo https://cuckoosandbox.org 3.1.4 Gestión e intercambio de información de amenazas Con la información obtenida de los distintos tipos de análisis surgen dos grandes necesidades en cuanto a la automatización de la gestión que se hace de ella. Por un lado, la recolección de la información. Por otro, su adaptación y normalización en los formatos adecuados para compartirla tanto con el resto de herramientas de la infraestructura como con otras organizaciones. Ante esta tesitura, también se empieza a pensar en enriquecer la información disponible a la hora de hacer análisis con la que puedan aportar organizaciones y comunidades de confianza. Para hacerse una idea de la relevancia que está empezando a obtener en el sector esta idea, incluso multinacionales, como IBM con su producto QRadar, están adoptando algunos de los formatos estándares descritos en el capítulo anterior (STIX / TAXII, etc.). Por ello, es de vital importancia que en el entorno que se está diseñando haya un elemento capaz de gestionar todas las tareas relativas al tratamiento de la información de amenazas. Tras estudiar las posibles alternativas dentro del ámbito Open Source, se encuentran algunos frameworks y herramientas enfocados en este rol. Se decide usar MISP (Malware Information Sharing Platform) por las funcionalidades que ofrece y por las organizaciones que ya hacen uso intensivo de este proyecto. Lo relevante no es ya sólo que un gran número de organizaciones lo utilicen, más de 2500 según su página web oficial, sino el principal tipo de éstas que lo promocionan y lo han incluido dentro de su flujo de trabajo. Se trata de los CSIRTs más importantes a nivel global como, por ejemplo, CERT-EU, CIRCL, etc. Un CSIRT (Computer Security Incident Response Team) es un equipo encargado de monitorizar los activos y de dar respuesta a incidentes relacionados con la seguridad de la información. MISP tiene un desarrollo modular y una documentación oficial detallada, por lo que aporta facilidad a la hora implementar modificaciones para que se integre con cualquier tipo de herramienta y formato que se necesite. No obstante, ya cuenta por defecto con un amplio número de módulos y extensiones oficiales. A parte de sus funcionalidades principales enfocadas en el intercambio de información entre organizaciones, se han encontrado realmente útil dos de las capacidades con las que cuenta: • Exportar reglas consumibles por IDS/IPS basadas en los indicadores de compromiso disponibles en la plataforma. • Consumir feeds de listas negras, de indicadores de compromiso o de cualquier tipo de información sobre malware y parsearlos para distribuir las actualizaciones entre las herramientas de seguridad en los formatos adecuados. Su funcionamiento está orientado a eventos. Cada muestra subida a la plataforma, cada resultado de análisis compartido, en definitiva, cada aporte de información aparece como un evento en MISP para ser tratado por los operadores. De forma automatizada, realiza una correlación entre ellos y es capaz de relacionarlos en función de los indicadores de compromiso que posean. Cuenta con un sistema de notificaciones personalizable para estar constantemente al tanto de las actualizaciones que suceden en la plataforma. En la figura facilitada a continuación se muestran posibles usos de MISP. La imagen original pertenece a la documentación sobre MISP en la página web de CIRCL. 49 49 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Figura 3-2. Ejemplos de uso de MISP Por último, indicar que organizaciones como CIRCL disponen de formación para sacarle el máximo partido a su uso diario, a sus capacidades de integración, etc. El código fuente, la documentación oficial, formación y demás información relevante relacionada con el proyecto se pueden encontrar en los siguientes enlaces: https://github.com/MISP/MISP http://www.misp-project.org https://www.circl.lu/doc/misp https://www.circl.lu/services/misp-training-materials 3.2 Disposición de componentes Se le asigna un rol dentro del entorno a las herramientas seleccionadas en base a las funciones para las que han sido desarrolladas y se obtienen cuatro componentes: • Sensor de red  Bro Network Security Monitor • Analizador estático  Múltiples motores de antivirus orquestados por Malice • Analizador dinámico  Cuckoo Sandbox • Gestor de información de amenazas  MISP Diseño de la Arquitectura 50 A continuación, se representan los componentes junto con las interacciones entre ellos. Esta automatización del ciclo de tratamiento de cada muestra corre a cargo de la solución detallada en el próximo capítulo. Figura 3-3. Componentes del entorno y sus interacciones 3.3 Modelo para pruebas Una vez que las piezas claves se definen por completo, se procede a la implementación de una maqueta usando Oracle VirtualBox para llevar a la práctica todos los conceptos adquiridos. Posee una doble finalidad. Por un lado, experimentar y obtener conclusiones sobre el trabajo realizado. Por otro, servir de apoyo en pruebas de concepto y demostraciones. Mientras se lleva cabo, se van realizando guías de los aspectos más específicos y claves. En general, siguen buenas prácticas y recomendaciones de los proyectos; así como los procedimientos más optimizados para evitar la aparición de errores comunes a la hora de instalar, configurar o poner a punto una determinada herramienta. Dichas guías se encuentran repartidas entre los anexos incluidos en la última parte de este documento. 3.3.1 Máquinas Virtuales El modelo consta de tres máquinas virtuales entre las que se agrupan los cuatro componentes descritos en el apartado anterior. Se opta por implementar en el mismo sistema el sensor de red y el analizador estático. Esta decisión se toma para optimizar los recursos del equipo anfitrión. 51 51 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Para poner en contexto la toma de dicha decisión, hay que indicar que esta implementación es un entorno de desarrollo y que la red monitorizada solo llevará tráfico cuando se vaya a realizar alguna prueba. Se ve viable que los recursos que quedan disponibles en el sensor de red asuman el consumo de Malice cuando ejecuta escáneres de antivirus sobre las muestras facilitadas. Para las elecciones de los sistemas operativos se tienen en cuenta las recomendaciones de las diferentes herramientas. No obstante, dentro de esas recomendaciones y siempre que sea posible, se han seguido preferencias personales. En este caso, la distribución de Linux Debian y, en su defecto, derivadas de ella como Ubuntu. 3.3.1.1 Sensor de red + Analizador estático Sistema Operativo: Ubuntu 14.04.5 LTS - Trusty CPU Cores: 1 Memoria: 4 GB Disco: 60 GB Incluye: • Bro Network Security Monitor • Docker Community Edition • Malice – Malware Analysis Framework • Contenedores de Docker con motores de antivirus 3.3.1.2 Analizador dinámico Sistema Operativo: Debian GNU/Linux 8.9 - Jessie CPU Cores: 2 Memoria: 4 GB Disco: 80 GB Incluye: • Cuckoo Sandbox Host: Analizador, aplicación web y REST API • Cuckoo Sandbox Guest: Máquina virtual para ejecutar muestras de malware o Sistema Operativo: Windows 7 SP1 o CPU Cores: 1 o Memoria: 1 GB o Disco: 20 GB 3.3.1.3 Gestor de información de amenazas Sistema Operativo: Ubuntu 16.04.2 LTS - Xenial CPU Cores: 1 Memoria: 2 GB Disco: 40 GB Incluye: Diseño de la Arquitectura 52 • Malware Information Sharing Platform 3.3.2 Redes virtuales Los requisitos en cuanto a conexiones son: • Conexión a Internet de cada una de las máquinas. o Actualizaciones de información sobre las amenazas. • Conexión entre las herramientas alojadas en diferentes máquinas y el anfitrión. o Trabajar de manera conjunta con la ayuda de la solución a desarrollar más adelante. • Conexión interna en exclusiva entre las máquinas virtuales. o Monitorizar la actividad en esta conexión aislada de cara a la realización de pruebas y presentaciones Teniendo en cuenta los dos primeros puntos a cumplir, se pensó en aprovechar una de las últimas incorporaciones de Oracle VirtualBox en cuanto a funcionalidades de red se refiere, “NAT Network”. Consiste en crear una red que toma al anfitrión como router haciendo NAT para salir hacia el exterior e incluye a todas las máquinas virtuales permitiendo visibilidad entre ellas. Finalmente, tras implementar dicha opción, no se consigue la estabilidad deseada debido a esporádicos errores relacionados con la memoria del anfitrión y el servicio “NAT Network”. Por lo tanto, se opta por una alternativa más clásica que aporta las mismas funcionalidades, pero que añade complejidad a la configuración de las interfaces de red en las máquinas virtuales. Consiste en lo siguiente: • Crear tantas redes de tipo “NAT” como máquinas haya que les permita salir a internet a través del anfitrión sin tener visibilidad entre ellas. • Crear una red de tipo “Host-Only” que permita la visibilidad entre todas las máquinas virtuales y el anfitrión sin salida al exterior. Por otra parte, para cumplir el tercer requisito en cuanto a redes virtuales, se crea una de tipo “Internal” que permite la visibilidad entre las máquinas virtuales, pero no con el anfitrión ni con el exterior. 3.3.3 Esquema del modelo A continuación, se muestra la primera implementación mediante el uso de las funcionalidades “NAT Network” e “Internal Network” en Oracle VirtualBox: 53 53 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Figura 3-4. Esquema de red del modelo virtual 4 DISEÑO DE LA SOLUCIÓN ste primer diseño para la solución que integra las herramientas del entorno creado se ve muy condicionado por tratar de sacar el máximo partido de las actuales limitaciones de Malice. El problema reside en el envío de los archivos desde el sensor de red hacia la máquina donde se encuentre Malice. Al carecer todavía de API en el momento en el que se lleva a cabo este proyecto, la mejor opción sería enviárselos por SCP a un directorio que estuviese monitorizado ejecutando un escáner por cada nuevo archivo. No obstante, por los motivos ya detallados en el capítulo anterior se decidió poner la instancia de Malice en la misma máquina que el sensor de red y en ese escenario se basa la versión de la solución implementada. Se trata de que la interacción humana necesaria para que el programa realice todas sus funciones sea nula desde el momento en el que se arranca con una determinada configuración inicial. Por lo tanto, se quedará a la espera de tratar nuevas muestras indefinidamente hasta que se le mande alguna de las señales del sistema operativo, por ejemplo, SIGINT usando CTRL+C. Para que el programa sea lo más flexible posible en cuanto a las herramientas con las que ha sido diseñado para trabajar, no es obligatorio el uso de ninguna de ellas para que pueda ejecutarse correctamente. Una vez elegidos los tipos de análisis a realizar (grupo de diferentes motores de antivirus y/o una sandbox virtual), se puede incluir opcionalmente en el flujo de trabajo la creación de eventos en MISP. En la sección de anexos al final de este documento se puede encontrar una copia íntegra del código del programa, “ninjaMind”. E Remember when you were young, you shone like the sun. Shine on you crazy diamond! Roger Waters, Pink Floyd Diseño de la Solución 56 4.1 Características De los objetivos marcados y del diseño de la arquitectura se desprenden las características a implementar: • Posibilidad de elegir entre realizar análisis estáticos, dinámicos o ambos. • Monitorizar el directorio especificado donde se extraen los archivos de la red. • Automatización completa del intercambio de información entre herramientas. 4.2 Atributos de calidad Durante el proceso de diseño del programa se decide añadir una serie de atributos no recogidos en las características anteriores. En definitiva, detalles que sirven para obtener un mejor y más completo resultado final: • Monitorización del directorio mediante las llamadas al sistema y no en base a una comprobación periódica del mismo. • Procesamiento en paralelo de las diferentes tareas. • Gestión de la salida estándar y de la salida de error. • Gestión de errores. • Gestión de subprocesos. • Gestión de contenedores de Docker. • Gestión del cierre del programa – Señales del sistema. 4.3 Diagrama de flujo A continuación, se proporciona el diagrama de flujo del programa a alto nivel. Es decir, centrado en el tratamiento que se le realiza a cada nueva muestra. No se tienen en cuenta aspectos adyacentes recogidos en el código como el parseo y la validación de la configuración al iniciar el programa, la gestión de subprocesos ante una señal de terminación, la gestión errores producidos en cualquiera de los procesos, etc.: 57 57 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Figura 4-1. Diagrama de flujo de la solución Diseño de la Solución 64 # If the container exists, but it is not running: remove it docker rm malice-elastic &>/dev/null fi else # If only this container is running, stop it and remove it docker stop malice-elastic &>/dev/null docker rm malice-elastic &>/dev/null fi if [[ "$kibStatus" != "running" ]]; then if [[ -n "$kibStatus" ]]; then # If the container exists, but it is not running: remove it docker rm malice-kibana &>/dev/null fi else # If only this container is running, stop it and remove it docker stop malice-kibana &>/dev/null docker rm malice-kibana &>/dev/null fi if ! malice elk &>/dev/null; then err "Cannot start Malice ELK Docker containers" return 1 fi fi } Se revisan los contenedores asociados a los motores de antivirus activados. Si alguno existiese, es porque no se ha eliminado correctamente después del último escáner, por lo que se fuerza su eliminación: ##################################### # Check and clean up antivirus Docker containers # Globals: # None # Arguments: # None # Returns: # 0 --> Success # 1 --> Error #------------------------------------- checkAVContainers() { local avContList="" local avCont="" local avContStatus="" # Get names of all antivirus containers avContList="$(malice plugin list 2>/dev/null)" if [[ $? -ne 0 ]]; then err "Cannot list Malice plugins" return 1 else # If a container exists, force the removal for avCont in $avContList; do avContStatus="$(docker inspect -f {{.State.Status}} $avCont 2>/dev/null)" if [[ -n "$avContStatus" ]]; then 65 65 Diseño de un Entorno Open Source para Análisis Automatizados de Malware docker rm -f $avCont &>/dev/null fi done fi } 4.5.6 Gestión del cierre del programa – Señales Se capturan ciertas señales del sistema para eliminar los motores de antivirus insertados en los contenedores de Docker y los subprocesos que estén ejecutándose antes de salir por completo. Tanto si es un error como si el usuario cancela la ejecución del programa se llevan a cabo estas acciones: # Control exit properly trap 'manageExit "$avResDir" "$nmPIDs"' SIGHUP SIGINT SIGQUIT SIGTERM 4.6 Licencia del programa El programa desarrollado se distribuye bajo la licencia GNU GPL v3. En las siguientes líneas se facilita una breve descripción de dicha licencia. La Licencia Pública General de GNU es una licencia libre, sin derechos para software y otros tipos de trabajos. Las licencias para la mayoría del software y otros trabajos prácticos están diseñadas para suprimir la libertad de compartir y modificar los trabajos. Por el contrario, la Licencia Pública General de GNU pretende garantizar su libertad para compartir y modificar todas las versiones de un programa -- y garantizar que siga siendo software libre para todos sus usuarios. Nosotros, la Fundación para el Software Libre, utilizamos la Licencia Pública General de GNU para la mayoría de nuestro software; se aplica también a cualquier otro trabajo publicado de esta manera por sus autores. También puede aplicarlo a sus programas. Cuando hablamos de software libre, nos referimos a la libertad, no al precio. Nuestras Licencias Públicas Generales están diseñadas para asegurar que tiene la libertad de distribuir copias de software libre (y cobrar por ellas si lo desea), de recibir el código fuente o de poder obtenerlo si lo desea, de modificar el software o usar partes del mismo en nuevos programas libres y de saber que puede hacer estas cosas. Para conseguir más información sobre la licencia y sus términos se pueden seguir los siguientes enlaces: • Información general en castellano: https://www.gnu.org/licenses/licenses.es.html • Licencia original en inglés: https://www.gnu.org/licenses/gpl.html Diseño de la Solución 66 Figura 4-3. Logo licencia GNU GPL v3 5 VALIDACIÓN Y RESULTADOS as pruebas llevadas a cabo han sido desarrolladas para verificar si se ha logrado solucionar el problema a resolver, ese que motiva la realización de este trabajo. Por dicho motivo es importante recordar lo recogido en el primer capítulo, Introducción, antes de comenzar de lleno a analizar los resultados. En última instancia lo que se buscaba era crear un entorno Open Source y estable que fuese capaz de automatizar el ciclo de tratamiento de las muestras. 5.1 Objetivo del Proyecto – Problema Inicial a Resolver Se conciben las pruebas como herramientas para validar si el desarrollo expuesto en el capítulo anterior, Diseño de la Solución, cumple con los tres pilares fundamentales del problema a resolver: Open Source, estabilidad y automatización. Por otra parte, se tienen en cuenta otros aspectos menores relacionados con decisiones de diseño que la solución desarrollada debe ofrecer. Se enumeran a continuación: • Flexibilidad para elegir qué tipos de análisis se quieren ejecutar: L Tell me is something eluding you sunshine? Is this not what you expected to see? Roger Waters, Pink Floyd Validación y Resultados 68 o Estático + Dinámico (Combinar ambas técnicas para aprovechar las ventajas de cada una) o Sólo estático o Sólo dinámico • Independencia de los métodos y productos usados para extraer las muestras. De esta forma, se aporta libertad para facilitar la integración con infraestructuras que ya cuenten con dispositivos IDS/IPS disponibles o productos capaces de extraer los archivos del tráfico de red. 5.2 Requisitos En base a los objetivos descritos anteriormente se generaron al inicio del proyecto los requisitos (RQ) a verificar: • Licencia – Open Source (L): o RQ-L-001: La solución usará la licencia GNU GPL v3. • Estabilidad (E): o RQ-E-001: La solución hará uso del concepto de programación defensiva. o RQ-E-002: La solución gestionará de forma propia las salidas estándar y de error del sistema Linux. o RQ-E-003: La solución gestionará los errores y las excepciones que surjan durante su ejecución. o RQ-E-004: La solución gestionará la creación y terminación de subprocesos. o RQ-E-005: La solución gestionará la ejecución y eliminación de contenedores de Docker. o RQ-E-006: La solución gestionará el cierre del programa haciendo uso de las Señales del sistema Linux. • Automatización (A): o RQ-A-001: La solución automatizará el envío en tiempo real a los analizadores de malware de las muestras extraídas de la red. o RQ-A-002: La solución será independiente del producto usado para extraer las muestras del tráfico de red. o RQ-A-004: La solución usará los diferentes tipos de analizadores de malware según la configuración establecida incluyendo las siguientes opciones: estático + dinámico, sólo estático y sólo dinámico. o RQ-A-004: La solución automatizará la generación en tiempo real de eventos en el gestor de información de amenazas con los resultados de los análisis de malware. 5.3 Riesgos Potenciales De los requisitos a verificar, se desprenden los siguientes riesgos potenciales (RS) asociados a este desarrollo: • Licencia – Open Source (L): o RS-L-001: La solución no se distribuye bajo la licencia especificada, GNU GPL v3. • Estabilidad (E): o RS-E-001: El código de la solución distribuida no implementa las medidas pertenecientes al concepto de programación defensiva. 69 69 Diseño de un Entorno Open Source para Análisis Automatizados de Malware o RS-E-002: La solución distribuida no hace uso de funciones propias para escribir mensajes adaptados por las salidas del sistema Linux. o RS-E-003: El código de la solución distribuida no captura los errores y excepciones que puedan surgir durante la ejecución. o RS-E-004: La solución distribuida no termina todos los subprocesos antes de finalizar la ejecución del proceso padre. o RS-E-005: La solución distribuida no elimina todos los contenedores de Docker utilizados antes de finalizar la ejecución. o RS-E-006: La solución distribuida no captura las Señales del sistema Linux para gestionar el cierre del programa. • Automatización (A): o RS-A-001: La solución distribuida no envía en tiempo real las muestras extraídas de la red a los analizadores de malware. o RS-A-002: El código de la aplicación distribuida hace uso de métodos de integración con dispositivos de red específicos para obtener las muestras extraídas del tráfico. o RS-A-003: La solución distribuida no permite la configuración de una o varias de las siguientes opciones de analizadores de malware: estático + dinámico, sólo estático y sólo dinámico. o RS-A-004: La solución distribuida no genera en tiempo real eventos en el gestor de información de amenazas con los resultados de los análisis de malware. Como se puede comprobar en la siguiente tabla, los identificadores de los riesgos siguen la numeración del requisito al que están asociados. Tabla 5-1. Relación requisitos-riesgos Requisito ID Riesgo ID RQ-L-001 RS-L-001 RQ-E-001 RS-E-001 RQ-E-002 RS-E-002 RQ-E-003 RS-E-003 RQ-E-004 RS-E-004 RQ-E-005 RS-E-005 RQ-E-006 RS-E-006 RQ-A-001 RS-A-001 RQ-A-002 RS-A-002 RQ-A-003 RS-A-003 RQ-A-004 RS-A-004 Validación y Resultados 70 5.4 Análisis de Riesgos El análisis de los riesgos de la solución está compuesto por dos bloques principales. Se comienza clasificándolos en función de la prioridad que requiere cada uno a la hora de ser controlado y validado. Una vez clasificados, se procede a tomar medidas para poder mitigarlos en base a los métodos de control definidos. 5.4.1 Clasificación de Riesgos Para llegar a obtener la prioridad asociada de todos los riesgos, se utiliza una combinación de cuatro diferentes parámetros junto con tres niveles de valores posibles por cada uno de ellos. A continuación, se encuentran las definiciones y la relación que hay entre estos y la prioridad de los riesgos. • Severidad: Impacto en la seguridad, calidad y funcionalidades de la solución. • Probabilidad: Posibilidad de que ocurra el riesgo potencial. • Clase: Severidad x Probabilidad • Detectabilidad: Posibilidad de identificar la presencia del riesgo antes de que tenga impacto sobre la solución. Tabla 5-2. Clasificación de riesgos: Clase Probabilidad Baja Media Alta Severidad Alta 2 1 1 Media 3 2 1 Baja 3 3 2 Tabla 5-3. Clasificación de riesgos: Prioridad Detectabilidad Alta Media Baja Clase 1 Media Alta Alta 2 Baja Media Alta 3 Baja Baja Media Se parte de la definición de los requisitos y de los riesgos en las secciones anteriores para evaluar la naturaleza de los mismos. En la siguiente tabla se puede apreciar con detalle los valores tomados para cada parámetro y el resultado final de la clasificación. 71 71 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Tabla 5-4. Clasificación de riesgos ID Severidad Probabilidad Clase Detectabilidad Prioridad RS-L-001 Alta Baja 2 Baja Alta RS-E-001 Alta Media 1 Baja Alta RS-E-002 Baja Media 3 Media Baja RS-E-003 Media Media 2 Baja Alta RS-E-004 Media Media 2 Media Media RS-E-005 Media Media 2 Media Media RS-E-006 Media Media 2 Media Media RS-A-001 Alta Baja 2 Media Media RS-A-002 Alta Baja 2 Baja Alta RS-A-003 Alta Baja 2 Media Media RS-A-004 Alta Baja 2 Media Media Para terminar con la clasificación, se facilita un gráfico a modo de sumario recogiendo el número de riesgos asociados a cada nivel de prioridad. Figura 5-1. Prioridad de los riesgos: Sumario 5.4.2 Control de Riesgos Con la clasificación de la sección anterior ya realizada, es momento de buscar formas de mitigar los riesgos. Antes de comenzar a desarrollar medidas y controlarlos, es necesario definir los métodos de control. Estos son usados como base sobre la que partir a la hora de diseñar las diferentes mitigaciones. • Test (T): Validación y Resultados 72 o Este método conlleva la ejecución de una prueba en la que el resultado obtenido muestre el cumplimiento de uno o más requisitos. Se definirán condiciones específicas para cada procedimiento de prueba a ejecutar. • Inspección (I): o Por una parte, este método sirve para validar aquellos requisitos en los que realizar un test no es posible porque la comprobación solo puede hacerse a través de una inspección visual (Ej.: validar que cierta documentación o licencia está disponible). Por otra, es útil para realizar una comprobación en profundidad de código cuando la detectabilidad del riesgo asociado al requisito es baja. En la siguiente tabla se encuentran cada una de las medidas ideadas, junto con el método en el que se basan, y la asociación de éstas con la prioridad de su correspondiente riesgo. Tabla 5-5. Control de Riesgos Riesgo ID Riesgo Prioridad Control Método Control Medida RS-L-001 Alta Inspección Comprobar en el código de la solución que existe un aviso legal sobre la licencia utilizada incluyendo una copia de la misma o una referencia para conseguirla. RS-E-001 Alta Inspección Comprobar en el código de la solución que se han implementado cada una de las medidas descritas en la sección 4.4.1 de este documento. RS-E-002 Baja Test Comprobar que todos los mensajes enviados por las salidas del sistema Linux utilizan el mismo formato establecido por la solución. RS-E-003 Alta Inspección Comprobar en el código de la solución que se han implementado las medidas descritas en la sección 4.5.3 de este documento. RS-E-004 Media Test Comprobar que no queda ninguno de los subprocesos en ejecución después del cierre del programa, proceso padre. RS-E-005 Media Test Comprobar que no queda ninguno de los contenedores de Docker utilizados después del cierre del programa. RS-E-006 Media Test Comprobar que el programa inicia la limpieza de subprocesos y contenedores Docker ante la recepción de las señales del sistema Linux. RS-A-001 Media Test Comprobar que las muestras se envían a los analizadores de malware en cuanto son extraídas. RS-A-002 Alta Inspección Comprobar en el código de la solución que se han implementado las medidas descritas en la sección 4.5.1 de este documento para obtener las muestras extraídas de la red. RS-A-003 Media Test Comprobar que se pueden configurar las 3 opciones de analizadores de malware. RS-A-004 Media Test Comprobar que los resultados de los analizadores de malware se envían al gestor de información de amenazas en cuanto son generados. 73 73 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Como se puede apreciar, para cada riesgo con prioridad alta se ha optado por realizar una inspección en profundidad del código fuente. Este tipo de tarea exhaustiva requiere muchos más recursos que la realización de un test, por lo que se ha reservado en exclusiva para controlar aquellos riesgos altamente prioritarios. 5.5 Validación de la Solución Esta sección incluye la información necesaria para comprobar que la solución se ajusta a los objetivos con los que fue diseñada. Los casos y procedimientos de pruebas descritos son suficientes para validar todos los requisitos y, por tanto, la solución. Todos y cada uno de ellos cuentan con un identificador único que se utiliza para generar a posteriori la matriz de trazabilidad. 5.5.1 Tareas de la sesión de validación Las siguientes tareas se llevan a cabo durante la sesión de validación: • Desplegar el escenario de las pruebas con los sistemas configurados y la comunicación entre los mismos disponible. • Comprobar que todos los elementos que componen las pruebas están configurados adecuadamente. • Ejecutar los procedimientos. • Comparar los resultados obtenidos con los resultados esperados. 5.5.2 Criterio de aceptación Como punto de partida, el criterio de aceptación para la validación de cada uno de los requisitos se basa en la comparación entre el resultado obtenido al ejecutar los procedimientos y los resultados esperados. Si ambos son iguales, se puede considerar como validado el/los requisito/s asociado/s. Un hecho a tener en cuenta, aunque pueda parecer trivial, es que los resultados esperados deben ser definidos con el objetivo de cumplir con los requisitos y con anterioridad a la fase de ejecución de los procedimientos. El criterio de aceptación se detalla por separado para cada uno de los diferentes procesos a ejecutar. 5.5.3 Escenario de las Pruebas El escenario en el que se lleva a cabo la validación es el descrito en la sección 3.3, Modelo para pruebas. En la siguiente figura se ilustra la disposición tanto de las redes como de los sistemas utilizados. Validación y Resultados 80 5.5.5.5.6 PR-T-01-006 Tabla 5-22. Procedimiento PR-T-01-006 Id. Procedimiento PR-T-01-006 Id. Req. RQ-A-003 Prerrequisitos Ninguno adicional. Criterio de aceptación El procedimiento debe ser considerado como exitoso si se pueden configurar las 3 opciones de analizadores de malware. Resultado del procedimiento Exitoso Fallido 5.5.5.5.7 PR-T-01-007 Tabla 5-23. Procedimiento PR-T-01-007 Id. Procedimiento PR-T-01-007 Id. Req. RQ-A-004 Prerrequisitos Ninguno adicional Criterio de aceptación El procedimiento debe ser considerado como exitoso si los resultados de los analizadores de malware se envían al gestor de información de amenazas en cuanto son generados. Resultado del procedimiento Exitoso Fallido Resultado del caso Exitoso Fallido Fin de la sesión de validación 81 81 Diseño de un Entorno Open Source para Análisis Automatizados de Malware 5.6 Aceptación de la Solución Tras haber realizado el proceso completo de análisis de los riesgos y validación de la solución, se tiene toda la información necesaria para poder decidir si la aplicación distribuida en esta entrega cumple con los objetivos del proyecto. En otras palabras, confirmar si el problema inicial a resolver que motiva este trabajo queda resuelto. En la siguiente tabla se muestra el resumen con los resultados de cada uno de los puntos anteriores. De izquierda a derecha se puede apreciar de forma rápida el proceso que se ha seguido con cada requisito durante su validación y el resultado final de ésta. Tabla 5-24. Aceptación de la solución: Matriz de trazabilidad Requisito ID Riesgo ID Riesgo Prioridad Control Método Control Medida Validación Procedimiento Validación Resultado RQ-L-001 RS-L-001 Alta Inspección Comprobar en el código de la solución que existe un aviso legal sobre la licencia utilizada incluyendo una copia de la misma o una referencia para conseguirla. PR-I-01-001 Exitoso RQ-E-001 RS-E-001 Alta Inspección Comprobar en el código de la solución que se han implementado cada una de las medidas descritas en la sección 4.4.1 de este documento. PR-I-02-001 Exitoso RQ-E-002 RS-E-002 Baja Test Comprobar que todos los mensajes enviados por las salidas del sistema Linux utilizan el mismo formato establecido por la solución. PR-T-01-001 Exitoso RQ-E-003 RS-E-003 Alta Inspección Comprobar en el código de la solución que se han implementado las medidas descritas en la sección 4.5.3 de este documento. PR-I-03-001 Exitoso RQ-E-004 RS-E-004 Media Test Comprobar que no queda ninguno de los subprocesos en ejecución después del cierre del programa, proceso padre. PR-T-01-002 Exitoso RQ-E-005 RS-E-005 Media Test Comprobar que no queda ninguno de los contenedores de Docker utilizados después del cierre del programa. PR-T-01-003 Exitoso RQ-E-006 RS-E-006 Media Test Comprobar que el programa inicia la limpieza de subprocesos y contenedores Docker ante la recepción de las señales del sistema Linux. PR-T-01-004 Exitoso RQ-A-001 RS-A-001 Media Test Comprobar que las muestras se envían a los analizadores de malware en cuanto son extraídas. PR-T-01-005 Exitoso RQ-A-002 RS-A-002 Alta Inspección Comprobar en el código de la solución que se han implementado las medidas descritas en la sección 4.5.1 de este documento para obtener las muestras extraídas de la red. PR-I-04-001 Exitoso RQ-A-003 RS-A-003 Media Test Comprobar que se pueden configurar las 3 opciones de analizadores de malware. PR-T-01-006 Exitoso RQ-A-004 RS-A-004 Media Test Comprobar que los resultados de los analizadores de malware se envían al gestor de información de amenazas en cuanto son generados. PR-T-01-007 Exitoso Como punto final de este proceso, se muestra a continuación un gráfico a modo de sumario sobre los resultados de la validación. Figura 5-3. Validación de los requisitos: Sumario Cada uno de los requisitos ha sido validado con éxito. Por lo tanto, se puede afirmar que esta entrega de la solución cumple con todos los requisitos y que todos los riesgos han sido controlados en función de su prioridad. Además, de este hecho se deduce que cada uno de los objetivos del proyecto se ven satisfechos y que se ha resuelto el problema inicial. 6 LÍNEAS DE MEJORA esde un primer momento, la idea era usar los conocimientos adquiridos y el entorno diseñado como base para desarrollar una futura solución Open Source. Un producto apto para ser usado en el ámbito empresarial. Una vez alcanzados los objetivos propuestos, no se acaba el trabajo, comienza el trazado de la hoja de ruta. 6.1 Funcionalidades de la solución desarrollada Para aumentar la utilidad de la solución, se considera interesante implementar las siguientes evoluciones sobre el funcionamiento de ninjaMind explicado en apartados anteriores. • Extraer también las URLs desde los sensores de red e incluirlas en el flujo de análisis. Por una parte, comparándolas con feeds de listas negras debidamente actualizados y por otra, analizando el comportamiento al acceder a ellas dentro de la sandbox. • Dar la opción de configurar los parámetros desde un archivo además de poder usar los argumentos en la línea de comandos como sucede ahora mismo. D When at last the work is done, don't sit down. It’s time to dig another one. Roger Waters, Pink Floyd Líneas de Mejora 86 • Implementar nuevas posibilidades de configuración: o Indicar la ruta hacia un fichero de log para dejar constancia de los detalles de la ejecución. Esta configuración debe ser independiente de que se haya activado o no la opción para que se muestren los mensajes por la salida estándar. o Indicar el número mínimo de análisis de antivirus que deben concluir con “infectado” para crear un evento en MISP. Por tanto, si se activa el análisis de comportamiento, también se establecería el número mínimo de resultados indicando “infectado” que evitaría reenviar el archivo o la URL a Cuckoo Sandbox. • Usar la futura API de Malice, que está actualmente en desarrollo, para poder interactuar mejor con la información generada por los motores de antivirus. • Indicar en los eventos creados en MISP la relación entre el número de resultados que indiquen “infectado” y el total de análisis antivirus realizados a la muestra. Ej.: “1 / 13”. 6.2 Funcionalidades de las herramientas del entorno Además, para mejorar integración de las herramientas utilizadas con el entorno se pretende: • Crear un nuevo módulo para Malice que consulte el registro de muestras almacenado en MISP y devuelva “infectado” si encuentra una coincidencia. Es decir, se trata de que la comunicación entre MISP y Malice no sea unidireccional y éste último pueda realimentarse de toda la información sobre amenazas disponibles en la instancia de MISP. • Modificar los módulos tanto de “reporting” como de “processing” que posee Cuckoo Sandbox relacionados con MISP. Esta modificación tiene como objetivo poder utilizar más parámetros de PyMISP en los archivos de configuración de Cuckoo Sandbox. De esta manera se conseguiría añadir más flexibilidad a la hora de personalizar la integración entre ambos productos. Ejemplos de ello serían: el nivel de distribución y la etiqueta del evento, la lista de direcciones IP y URLs almacenadas en MISP que no se quieren procesar, etc. 6.3 Arquitectura El principal cambio es introducir Apache Kafka como hilo conductor en el intercambio de información consiguiendo así separar completamente las funciones de sensor de red y de analizador de malware. Por una parte, integrar un productor de Apache Kafka en cada sensor para que envíe las URLs y los archivos codificados en base64 al broker. Por otra parte, tener un consumidor de Apache Kafka en cada instancia de analizador que reciba del broker las URLs y archivos decodificando estos últimos para ejecutar los análisis correspondientes. De esta forma se consigue flexibilidad a la hora de decidir en qué partes de la red desplegar qué funciones y escalabilidad a la hora de decidir cuantas instancias de cada tipo usar en paralelo. Dicha evolución iría enfocada a despliegues en infraestructuras con un gran volumen de tráfico y/o con alta probabilidad de encontrar muestras potencialmente peligrosas. 6.4 Apariencia En el ámbito empresarial, es una práctica habitual realizar una prueba de concepto de una solución y sus alternativas antes de decidirse por implantar una de ellas. Durante la realización de estas pruebas, se evalúa principalmente su utilidad. Ante una posible equidad en los resultados, algunos de los aspectos a tener en 87 87 Diseño de un Entorno Open Source para Análisis Automatizados de Malware cuenta para decantarse finalmente por una opción u otra son la facilidad de uso para los operadores y la sensación de estar ante un producto “maduro”. Teniendo en cuenta este hecho, se plantea modificar las diferentes interfaces gráficas para ofrecer una imagen homogénea de la solución. En definitiva, mostrar una identidad propia incluyendo nombre, eslogan, logotipo y colores. 7 CONCLUSIONES urante la realización de este trabajo, he puesto en práctica una amplia gama de conocimientos adquiridos durante el Grado de Ingeniería de las Tecnologías de Telecomunicación. En concreto, los relacionados con el departamento de Ingeniería Telemática. Ésta fue una de las razones por las que me sentí tan motivado al plantear la organización del proyecto; debería aunar conocimientos sobre redes, sobre sistemas operativos y sobre programación. La ciberseguridad es un ámbito multidisciplinar y así se ha hecho constar a lo largo del trabajo. Estar familiarizado con la distribución del sistema de capas OSI, por ejemplo, es esencial. De ahí que la idea inicial fuese un punto de partida perfecto para abrir el abanico de materias de las que nutrirme al comenzar mi investigación. Aspectos de vital importancia en el mundo laboral se han visto potenciados debido a los retos afrontados para conseguir los objetivos propuestos. Un ejemplo de ello es la mejora de la autonomía, la capacidad de autocrítica y, sobre todo, la capacidad de resolver problemas a la hora de sacar el trabajo adelante. El paquete formado por el entorno y la solución diseñados cumple con las expectativas iniciales. Si se modifica éste en los puntos detallados en la hoja de ruta y se adapta a la infraestructura de cada organización interesada, se podría comercializar ofreciendo los servicios profesionales necesarios para su instalación, configuración, puesta a punto y/o administración. D The time is gone, the song is over. Thought I'd something more to say. Roger Waters, Pink Floyd ANEXO A: DOCKER COMMUNITY EDITION Las guías y procedimientos de este anexo están probados para Ubuntu en las versiones de Trusty en adelante. Instalación de Docker Community Edition Se opta por la instalación desde el repositorio oficial de Docker, ya que facilita la gestión de futuras actualizaciones. Actualizar el índice de paquetes: $ sudo apt-get update Instalar paquetes adicionales sólo necesarios en Ubuntu Trusty 14.04 y no en versiones posteriores: $ sudo apt-get install linux-image-extra-$(uname -r) linux-image-extra- virtual Instalar los paquetes que permiten usar repositorios sobre HTTPS: $ sudo apt-get install apt-transport-https ca-certificates curl softwareproperties-common Añadir la clave oficial de Docker: $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add – Verificar que el ID de la clave es 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88: Anexo A: Docker Community Edition 98 $ sudo apt-key fingerprint 0EBFCD88 […] pub 4096R/0EBFCD88 2017-02-22 Key fingerprint = 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88 uid Docker Release (CE deb) <[email protected]> sub 4096R/F273FCD8 2017-02-22 […] Establecer el repositorio de la versión estable de Docker: $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" Actualizar el índice de paquetes con el nuevo repositorio configurado: $ sudo apt-get update Instalar la última versión estable de Docker Community Edition: $ sudo apt-get install docker-ce Verificar que se ha instalado correctamente Docker: $ sudo docker run hello-world Para poder usar Docker como un usuario no administrador se incluye dentro del grupo correspondiente. Es necesario cerrar la sesión y volver a abrirla para que se apliquen los cambios: $ sudo groupadd docker $ sudo usermod -aG docker $USER Docker se configura automáticamente para ejecutarse al inicio si se usa upstart, pero es necesario habilitar esta opción si se usa systemd: $ sudo systemctl enable docker Cambiar el controlador de almacenamiento de Docker a Overlay2 Hacer un backup de /var/lib/docker teniendo el servicio de Docker detenido: 99 99 Diseño de un Entorno Open Source para Análisis Automatizados de Malware $ cp -au /var/lib/docker /var/lib/docker.bk Modificar el archivo /etc/docker/daemon.json o crearlo si no existe añadiendo el siguiente contenido: { "storage-driver": "overlay2" } Comprobar que los cambios se han efectuado de forma correcta después de haber arrancado Docker de nuevo: $ docker info […] Storage Driver: overlay2 […] ANEXO B: MALICE - MALWARE ANALYSIS FRAMEWORK Las guías y procedimientos de este anexo están probados para Ubuntu en las versiones de Trusty en adelante. Instalación de Malice - Malware Analysis Framework Es necesario tener instalado Docker antes de seguir. El desarrollo de Malice está aún en fase beta, por lo que se opta por instalar desde un binario precompilado de la versión probada. A la hora de actualizar, se elimina el binario siguiendo el procedimiento indicado en el siguiente apartado para después volver a instalar la versión deseada. Descargar el binario de la versión 0.3.11: $ wget https://github.com/maliceio/malice/releases/download/v0.3.11/malice_0.3.1 1_linux_amd64.tar.gz -O /tmp/malice.tar.gz Extraer en la ruta adecuada para su posterior ejecución: $ sudo tar -xzf /tmp/malice.tar.gz -C /usr/local/bin/ Desinstalación de Malice - Malware Analysis Framework Eliminar binario: Anexo B: Malice - Malware Analysis Framework 102 $ sudo rm /usr/local/bin/malice Eliminar configuraciones y muestras comprimidas de los archivos analizados: $ rm -rf ~/.malice Configuración Inicial Malice - Malware Analysis Framework Listar todos los plugins indicando de qué tipo es cada uno: $ malice plugin list –-all –-detail Eliminar los plugins que no sean de tipo antivirus o identificador de firmas maliciosas, como por ejemplo los analizadores de metadatos y cadenas de caracteres: $ malice plugin remove [plugin_name] Otra forma de realizar el paso anterior es modificando el archivo de configuración ~/.malice/plugins/plugins.toml dejando en él solo los plugins que nos interesen. De igual manera, se debe acceder a dicho archivo para habilitar los plugins [enabled = true] que por defecto aparecen deshabilitados. En este caso, un ejemplo del mismo es: [[plugin]] enabled = true name = "fileinfo" description = "ssdeep/TRiD/exiftool" category = "metadata" image = "malice/fileinfo" repository = "https://github.com/malice-plugins/fileinfo.git" build = false mime = "*" env = ["MALICE_TIMEOUT"] [[plugin]] name = "nsrl" enabled = true category = "intel" description = "NSRL Database Hash Search" image = "malice/nsrl:sha1" repository = "https://github.com/malice-plugins/nsrl.git" build = false apikey = "" mime = "hash" hashtypes = ["sha1"] cmd = "lookup" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "virustotal" enabled = true category = "intel" 103 103 Diseño de un Entorno Open Source para Análisis Automatizados de Malware description = "VirusTotal - files scan and hash lookup" image = "malice/virustotal" repository = "https://github.com/malice-plugins/virustotal.git" build = false apikey = "2539516d471d7beb6b28a720d7a25024edc0f7590d345fc747418645002ac47b" mime = "hash" hashtypes = ["md5", "sha1", "sha256"] cmd = "lookup" env = ["MALICE_VT_API", "MALICE_TIMEOUT"] Installed = false [[plugin]] name = "totalhash" enabled = true category = "intel" description = "#totalhash - hash lookup" image = "malice/totalhash" repository = "https://github.com/malice-plugins/totalhash.git" build = false apikey = "" mime = "hash" hashtypes = ["sha1"] cmd = "" env = ["MALICE_TH_USER", "MALICE_TH_KEY", "MALICE_TIMEOUT"] Installed = false [[plugin]] name = "shadow-server" enabled = true category = "intel" description = "ShadowServer - hash lookup" image = "malice/shadow-server" repository = "https://github.com/malice-plugins/shadow-server.git" build = false apikey = "" mime = "hash" hashtypes = ["md5", "sha1"] cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "team-cymru" enabled = true category = "intel" description = "TeamCymru - hash lookup" image = "malice/team-cymru" repository = "https://github.com/malice-plugins/team-cymru.git" build = false apikey = "" mime = "hash" hashtypes = ["md5", "sha1"] cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] Anexo B: Malice - Malware Analysis Framework 104 name = "avast" enabled = true category = "av" description = "Avast AntiVirus" image = "malice/avast" repository = "https://github.com/malice-plugins/avast.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "avg" enabled = true category = "av" description = "AVG AntiVirus" image = "malice/avg" repository = "https://github.com/malice-plugins/avg.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "avira" enabled = true category = "av" description = "Avira AntiVirus" image = "malice/avira" repository = "https://github.com/malice-plugins/avira.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "bitdefender" enabled = true category = "av" description = "Bitdefender AntiVirus" image = "malice/bitdefender" repository = "https://github.com/malice-plugins/bitdefender.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "clamav" enabled = true 105 105 Diseño de un Entorno Open Source para Análisis Automatizados de Malware category = "av" description = "ClamAV" image = "malice/clamav" repository = "https://github.com/malice-plugins/clamav.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "comodo" enabled = true category = "av" description = "Comodo AntiVirus" image = "malice/comodo" repository = "https://github.com/malice-plugins/comodo.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "escan" enabled = true category = "av" description = "eScan AntiVirus" image = "malice/escan" repository = "https://github.com/malice-plugins/escan.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "fprot" enabled = true category = "av" description = "F-PROT AntiVirus" image = "malice/fprot" repository = "https://github.com/malice-plugins/fprot.git" build = false apikey = "" mime = "*" cmd = "" env = ["MALICE_TIMEOUT"] Installed = false [[plugin]] name = "fsecure" enabled = true category = "av" description = "F-Secure AntiVirus" Anexo C: Cuckoo Sandbox 2.0 112 $ sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump Validar la configuración de tcpdump: $ /sbin/getcap /usr/sbin/tcpdump /usr/sbin/tcpdump = cap_net_admin,cap_net_raw+eip Instalar Volatility 2.5: $ sudo pip install openpyxl $ sudo pip install ujson $ sudo pip install pycrypto $ sudo pip install distorm3 $ sudo pip install pytz $ wget https://github.com/volatilityfoundation/volatility/archive/2.5.tar.gz -O volatility-2.5.tar.gz $ tar -xzf volatility-2.5.tar.gz $ cd volatility-2.5.tar.gz $ python setup.py build $ sudo python setup.py install Validar la instalación de Volatility: $ python vol.py –h Volatility Foundation Volatility Framework 2.5 Usage: Volatility - A memory forensics analysis platform. […] Instalar SWIG. Necesaria para que Cuckoo instale automáticamente la dependencia M2Crypto durante su instalación: $ sudo apt-get install swig Crear el usuario para Cuckoo Sandbox: $ sudo adduser cuckoo Agregar el usuario de Cuckoo Sandbox al grupo de VirtualBox: 113 113 Diseño de un Entorno Open Source para Análisis Automatizados de Malware $ sudo usermod -a -G vboxusers cuckoo Instalar Cuckoo Sandbox 2.0.3 usando el usuario cuckoo. Se recomienda usar un entorno virtual para evitar problemas con las versiones de las dependencias y no necesitar privilegios de superusuario para actualizar Cuckoo o para añadir nuevos paquetes. Sin entorno virtual: $ pip install -U pip setuptools $ pip install -U cuckoo Con entorno virtual: $ virtualenv venv $ . venv/bin/activate (venv)$ pip install -U pip setuptools (venv)$ pip install -U cuckoo Crear la interfaz de tipo “host-only” para las máquinas virtuales de los “guests” $ sudo vboxmanage hostonlyif create $ sudo vboxmanage hostonlyif ipconfig vboxnet0 --ip 192.168.13.1 Crear un “Cuckoo Working Directory” para generar la configuración base de la instancia. Se deberá usar el usuario cuckoo para realizar el siguiente paso: $ cuckoo –d Instalación y configuración de Cuckoo Sandbox Guests En este apartado se describen los procedimientos para crear máquinas virtuales con una configuración estándar. Se recomienda usar un sistema lo más parecido posible al que queremos proteger incluyendo aplicaciones instaladas. Para más información sobre cómo evitar que el malware detecte que está en una máquina virtual, acudir al apartado relacionado con Cuckoo Sandbox en capítulos anteriores. Creación de Cuckoo Guests manualmente Es necesario ejecutar los siguientes pasos con el usurio cuckoo. Crear la máquina virtual: $ vboxmanage createvm --name "win7x64" --ostype Windows7_64 –register $ cd "VirtualBox VMs/win7x64/" Anexo C: Cuckoo Sandbox 2.0 114 $ vboxmanage modifyvm "win7x64" --memory 1000 --acpi on --boot1 dvd -- nic1 nat $ vboxmanage createhd --filename "win7x64.vdi" --size 256000 $ vboxmanage storagectl "win7x64" --name "IDE Controller" --add ide -- controller PIIX4 $ vboxmanage storageattach "win7x64" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium "win7x64.vdi" $ vboxmanage storageattach "win7x64" --storagectl "IDE Controller" --port 0 --device 1 --type dvddrive --medium /home/cuckoo/en_windows_7_professional_with_sp1_x64_dvd_u_677056.iso $ vboxmanage modifyvm "win7x64" --nic1 hostonly $ vboxmanage modifyvm "win7x64" --hostonlyadapter1 vboxnet0 Instalar el sistema operativo: $ vboxmanage startvm "win7x64" Una vez que termine el proceso de instalación mediante la interfaz gráfica, configurar la red: IP: 192.168.13.23 Máscara de red: 255.255.255.0 Puerta de enlace predeterminada: 192.168.13.1 DNS primario: 8.8.8.8 DNS secundario: 8.8.4.4 Deshabilitar las actualizaciones automáticas, el firewall de Windows y el UAC (User Account Control). Instalar aplicaciones como Adobe Reader, Microsoft Office, Firefox, java, etc. Para encontrar versiones anteriores de ciertas aplicaciones: [http://www.oldapps.com/] Descargar la versión correspondiente de Python desde: [https://www.python.org/downloads/release/python- 2711/] $ wget https://www.python.org/ftp/python/2.7.11/python-2.7.11.msi Descargar Python Imaging Library para Windows: $ wget http://effbot.org/downloads/PIL-1.1.7.win32-py2.7.exe Copiar el agente de Cuckoo a la carpeta donde se hayan descargados los archivos anteriores cambiando su extensión por .pyw: $ cp /home/cuckoo/.cuckoo/agent/agent.py /home/cuckoo/Downloads/agent.pyw 115 115 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Pasar los archivos descargados junto con el agente de Cuckoo al Guest: $ python -m SimpleHTTPServer Desde el Guest acceder a http://192.16813.1:8000 y descargar los archivos. Instalar Python y PIL Colocar el agente de Cuckoo en la carpeta de arranque al inicio, en Windows 7: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup Reiniciar la máquina virtual. Ejecutar el agente de Cuckoo, agent.pyw, como administrador. Realizar un snapshot de la máquina virtual con la máquina arrancada y el agente corriendo: $ vboxmanage snapshot "win7x64" take "snapshot1" --pause $ vboxmanage controlvm "win7x64" poweroff $ vboxmanage snapshot "win7x64" restorecurrent Creación de Cuckoo Guests mediante VMCloak Instalar VMCloak 0.4.4: $ wget https://github.com/jbremer/vmcloak/archive/0.4.4.tar.gz -O vmcloak-0.4.4.tar.gz $ tar -xzf vmcloak-0.4.4.tar.gz $ cd vmcloak-0.4.4/ $ sudo pip install -r requirements.txt $ sudo python setup.py install Crear un punto de montaje para la imagen del SO a utilizar. En este ejemplo será Windows 7 Professional x64: $ sudo mkdir -p /mnt/win7x64 $ sudo mount -o loop,ro /home/cuckoo/en_windows_7_professional_with_sp1_x64_dvd_u_677056.iso /mnt/win7x64/ Es necesario ejecutar vmcloak con el usuario cuckoo para evitar posibles problemas de permisos en las máquinas virtuales durante los análisis. Para ello hay que incluir al usuario cucko en el archivo sudoers antes de seguir con los siguientes pasos. Crear la máquina virtual con vmcloak y finalizar la instalación del sistema operativo. Configurar IP estática y máscara acordes con las creadas anteriormente y comprobar conectividad con el Cuckoo Host (192.168.13.1): Anexo C: Cuckoo Sandbox 2.0 116 $ sudo -E vmcloak init --win7x64 --iso-mount /mnt/win7/ --cpus 1 -- ramsize 1024 --vm-visible -d win7x64 Instalar algunas aplicaciones básicas en la máquina virtual: $ sudo -E vmcloak install --vm-visible –d win7x64 adobe9 wic pillow dotnet40 firefox_41 java7 silverlight5 pil chrome iexplore Hacer un snapshot de la máquina virtual: $ sudo -E vmcloak snapshot --vm-visible –d win7x64 snapshot1 192.168.13.23 Configuración inicial Cuckoo Host Asegurar que todo el contenido del directorio del usuario cuckoo le pertenece: $ sudo chown -R cuckoo:cuckoo /home/cuckoo La configuración de Cuckoo Sanbox es altamente personalizable, por lo que en las siguientes indicaciones se tratan únicamente los parámetros esenciales para su funcionamiento básico. Editar el archivo cuckoo.conf: $ vim /home/cuckoo/.cuckoo/conf/cuckoo.conf […] # Specify the name of the machinery module to use, this module will # define the interaction between Cuckoo and your virtualization software # of choice. machinery = virtualbox # Enable creation of memory dump of the analysis machine before shutting # down. Even if turned off, this functionality can also be enabled at # submission. Currently available for: VirtualBox and libvirt modules (KVM). memory_dump = yes […] [resultserver] # The Result Server is used to receive in real time the behavioral logs # produced by the analyzer. # Specify the IP address of the host. The analysis machines should be able # to contact the host through such address, so make sure it's valid. # NOTE: if you set resultserver IP to 0.0.0.0 you have to set the option # `resultserver_ip` for all your virtual machines in machinery configuration. ip = 192.168.13.1 117 117 Diseño de un Entorno Open Source para Análisis Automatizados de Malware […] Editar el archivo auxiliary.conf: $ vim /home/cuckoo/.cuckoo/conf/auxiliary.conf […] [sniffer] # Enable or disable the use of an external sniffer (tcpdump) [yes/no]. enabled = yes # Specify the path to your local installation of tcpdump. Make sure this # path is correct. tcpdump = /usr/sbin/tcpdump […] Editar el archivo virtualbox.conf: $ vim /home/cuckoo/.cuckoo/conf/virtualbox.conf […] # Default network interface. interface = vboxnet0 # Specify a comma-separated list of available machines to be used. For each # specified ID you have to define a dedicated section containing the details # on the respective machine. (E.g. cuckoo1,cuckoo2,cuckoo3) machines = win7x64 [win7x64] # Specify the label name of the current machine as specified in your # VirtualBox configuration. label = win7x64 # Specify the operating system platform used by current machine # [windows/darwin/linux]. platform = windows # Specify the IP address of the current virtual machine. Make sure that the # IP address is valid and that the host machine is able to reach it. If not, # the analysis will fail. ip = 192.168.13.23 # (Optional) Specify the snapshot name to use. If you do not specify a snapshot # name, the VirtualBox MachineManager will use the current snapshot. # Example (Snapshot1 is the snapshot name): snapshot = snapshot1 Anexo C: Cuckoo Sandbox 2.0 118 […] Editar el archivo processing.conf: $ vim /home/cuckoo/.cuckoo/conf/processing.conf […] [memory] # Create a memory dump of the entire Virtual Machine. This memory dump will # then be analyzed using Volatility to locate interesting events that can be # extracted from memory. enabled = yes […] Obtener la lista de perfiles disponibles para Volatility: $ vol.py --info |grep Profiles -A48 Volatility Foundation Volatility Framework 2.5 Profiles -------- VistaSP0x64 - A Profile for Windows Vista SP0 x64 VistaSP0x86 - A Profile for Windows Vista SP0 x86 VistaSP1x64 - A Profile for Windows Vista SP1 x64 VistaSP1x86 - A Profile for Windows Vista SP1 x86 VistaSP2x64 - A Profile for Windows Vista SP2 x64 VistaSP2x86 - A Profile for Windows Vista SP2 x86 Win10x64 - A Profile for Windows 10 x64 Win10x86 - A Profile for Windows 10 x86 Win2003SP0x86 - A Profile for Windows 2003 SP0 x86 Win2003SP1x64 - A Profile for Windows 2003 SP1 x64 Win2003SP1x86 - A Profile for Windows 2003 SP1 x86 Win2003SP2x64 - A Profile for Windows 2003 SP2 x64 Win2003SP2x86 - A Profile for Windows 2003 SP2 x86 Win2008R2SP0x64 - A Profile for Windows 2008 R2 SP0 x64 Win2008R2SP1x64 - A Profile for Windows 2008 R2 SP1 x64 119 119 Diseño de un Entorno Open Source para Análisis Automatizados de Malware Win2008SP1x64 - A Profile for Windows 2008 SP1 x64 Win2008SP1x86 - A Profile for Windows 2008 SP1 x86 Win2008SP2x64 - A Profile for Windows 2008 SP2 x64 Win2008SP2x86 - A Profile for Windows 2008 SP2 x86 Win2012R2x64 - A Profile for Windows Server 2012 R2 x64 Win2012x64 - A Profile for Windows Server 2012 x64 Win7SP0x64 - A Profile for Windows 7 SP0 x64 Win7SP0x86 - A Profile for Windows 7 SP0 x86 Win7SP1x64 - A Profile for Windows 7 SP1 x64 Win7SP1x86 - A Profile for Windows 7 SP1 x86 Win81U1x64 - A Profile for Windows 8.1 Update 1 x64 Win81U1x86 - A Profile for Windows 8.1 Update 1 x86 Win8SP0x64 - A Profile for Windows 8 x64 Win8SP0x86 - A Profile for Windows 8 x86 Win8SP1x64 - A Profile for Windows 8.1 x64 Win8SP1x86 - A Profile for Windows 8.1 x86 WinXPSP1x64 - A Profile for Windows XP SP1 x64 WinXPSP2x64 - A Profile for Windows XP SP2 x64 WinXPSP2x86 - A Profile for Windows XP SP2 x86 WinXPSP3x86 - A Profile for Windows XP SP3 x86 Address Spaces -------------- […] Editar el archivo memory.conf: $ vim /home/cuckoo/.cuckoo/conf/memory.conf […] # Basic settings [basic] # Profile to avoid wasting time identifying it guest_profile = Win7SP1x64 […] Anexo C: Cuckoo Sandbox 2.0 120 Editar el archivo reporting.conf: $ /home/cuckoo/.cuckoo/conf/reporting.conf […] # Enable creation of report.html? html = yes […] [mongodb] enabled = yes host = 127.0.0.1 port = 27017 db = cuckoo store_memdump = yes paginate = 100 # MongoDB authentication (optional). username = password = […] Arranque inicial Cuckoo Sandbox Descargar la versión actualizada de todas las “Cuckoo Signatures”, las reglgas de Yara, etc.: $ cuckoo community Lanzar los siguientes comandos en diferentes shells. Ejecutar el analizador de Cuckoo Sandbox en modo debug: $ cuckoo –d Ejecutar la interfaz gráfica de Cuckoo Sandbox, aplicación web: $ cuckoo web Ejecutar el servicio REST API de Cuckoo Sandbox: $ cuckoo api Integración con MISP Cuckoo Sandbox 2.0 hace uso de la REST API de MISP a través de dos módulos de los tipos “processing” y “reporting”. Editar el archivo processing.conf: 121 121 Diseño de un Entorno Open Source para Análisis Automatizados de Malware $ vim /home/cuckoo/.cuckoo/conf/processing.conf […] [misp] enabled = yes url = http://misp.etsi.us apikey = your_api_key # Maximum amount of IOCs to look up (hard limit). maxioc = 100 […] Editar el archivo reporting.conf: $ vim /home/cuckoo/.cuckoo/conf/reporting.conf […] [misp] enabled = yes url = http://misp.etsi.us apikey = your_api_key # The various modes describe which information should be submitted to MISP, # separated by whitespace. Available modes: maldoc ipaddr hashes url. mode = maldoc ipaddr hashes url […] La API Key se puede obtener en la interfaz web de MISP después de haber iniciado sesión usando un usuario con permisos de automatización. Dentro del menú “Event Actions” hacer click en “Automation”: Figura C-1. Obtener API key de MISP Anexo E: ninjaMind 128 ################################# ### Global Variables ### ################################# readonly programName=${0##*/} readonly programVersion="0.1" quietMode="" ##################################### ### Functions ### ##################################### ##################################### # Print help/usage # Globals: # programName # Arguments: # None # Returns: # None #------------------------------------- usage() { cat <<- EOF Usag e: $programName -e <dir> [-a <dir> [-m <url[:port]>]] [-b <url[:port]>] [-q] Prog ram monitors the specified directory to perform malware analyses of all new files. Malw are analyses can be static (antivirus), dynamic (behavior) or both. At least one type is required. If static and dynamic are set, behavioral anal ysis is only available for undetected files by antiviruses. It is possible to create an event in the specified MISP (Malware Information Shar ing Platform) instance when one of the antiviruses detects an infection. Opti ons: -e <dir> Extracted files from network traffic directory -a <dir> Malice Multi-engine Antivirus results directory -m <url[:port]> Malware Information Sharing Platform API URL Only if -a option is set 129 129 Diseño de un Entorno Open Source para Análisis Automatizados de Malware -b <url[:port]> Cuckoo Sanbodx API URL -q Quiet mode -v Show version -h Show this message Exam ples: Run static and dynamic analysis with MISP integration: $ $programName -e ./files/ -a ./results/ -m http://misp.etsi.us \\ -b http://cuckoo.etsi.us:1301 Run static and dynamic analysis: $ $programName -e ./files/ -a ./results/ -b http://cuckoo.etsi.us:1301 Run static analysis with MISP integration: $ $programName -e ./files/ -a ./results/ -m http://misp.etsi.us Run static analysis: $ $programName -e ./files/ -a ./reesults/ Run dynamic analysis: $ $programName -e ./files/ -b http://cuckoo.etsi.us:1301 EOF } ##################################### # Print ninjaMind logo # Globals: # None # Arguments: # None # Returns: # None #------------------------------------- logo() { cat <<- EOF _ _ _ _ _ __ (_)_ __ (_) __ _ /\/\ (_)_ __ __| | | '_ \| | '_ \ | |/ _\` |/ \| | '_ \ / _\` | | | | | | | | || | (_| / /\/\ \ | | | | (_| | |_| |_|_|_| |_|/ |\__,_\/ \/_|_| |_|\__,_| Anexo E: ninjaMind 130 There is |__/ nothing so stable as change EOF } ##################################### # Print error messages along with date and time # Globals: # quietMode # Arguments: # 1 Error message to print # Returns: # None #------------------------------------- err() { if [[ -z "$quietMode" ]]; then echo "[ERR][$(date +'%Y/%m/%d-%H:%M:%S%z')]: $1" >&2 fi } ##################################### # Print information messages along with date and time # Globals: # quietMode # Arguments: # 1 Information message to print # Returns: # None #------------------------------------- inf() { if [[ -z "$quietMode" ]]; then echo "[INF][$(date +'%Y/%m/%d-%H:%M:%S%z')]: $1" fi } ##################################### # Create a new task in Cuckoo Sandbox uploading extracted file # Globals: # None # Arguments: # 1 Cuckoo Sandbox API URL # 2 Path to extracted file # Returns: # 0 --> Success # 1 --> Error #------------------------------------- sendFileCuckoo() { local fileName="" fileName="${2##*/}" curl -F file=@${2} "$1"tasks/create/file &>/dev/null if [[ $? -ne 0 ]]; then err "Cannot send file to Cuckoo Sandbox: $fileName" return 1 else inf "Cuckoo Sandbox - File sent: $fileName" 131 131 Diseño de un Entorno Open Source para Análisis Automatizados de Malware fi } ##################################### # Create a new event in MISP uploading malware sample # Globals: # mispApiKey # Arguments: # 1 MISP instance API URL # 2 Path to extracted file # 3 Malice detection details # Returns: # 0 --> Success # 1 --> Error #------------------------------------- createEventMISP() { local fileName="" local fileB64="" local fileInfo="" local fileComment="" if [[ -z "$mispApiKey" ]]; then err "mispApiKey global variable is unset or empty" return 1 else fileName="${2##*/}" fileB64="$(base64 $2)" fileInfo="$(echo -n "[MALWARE][$(date +'%Y/%m/%d-%H:%M:%S%z')]")" fileComment="$3" # Data must be read from stdin because argument list is too long curl --header "Accept: application/json" --header "Content-type: application/json" --header "Authorization: $mispApiKey" --request POST --data @- "$1"events/upload_sample/ &>/dev/null << CURL_DATA {"request":{"files": [{"filename": "$fileName", "data": "$fileB64"}], "distribution": 0, "category":"Payload delivery", "info" : "$fileInfo", "comment":"$fileComment"}} CURL_DATA if [[ $? -ne 0 ]]; then err "Cannot create MISP Event: $fileName" return 1 else inf "MISP - Event created: $fileName" fi fi } ##################################### # Parse Malice result file # Globals: # None # Arguments: # 1 Path to Malice result file # Returns: # 0 --> Success # 1 --> Error #------------------------------------- Anexo E: ninjaMind 132 parseMaliceResults() { local fileName="" fileName="${1##*/}" fileName="${fileName%.mr}" grep -B 3 "| true |" $1 2>/dev/null if [[ $? -ge 2 ]]; then err "Cannot parse Malice result: $fileName" return 1 else return 0 fi } ##################################### # Check and clean up antivirus Docker containers # Globals: # None # Arguments: # None # Returns: # 0 --> Success # 1 --> Error #------------------------------------- checkAVContainers() { local avContList="" local avCont="" local avContStatus="" # Get names of all antivirus containers avContList="$(malice plugin list 2>/dev/null)" if [[ $? -ne 0 ]]; then err "Cannot list Malice plugins" return 1 else # If a container exists, force the removal for avCont in $avContList; do avContStatus="$(docker inspect -f {{.State.Status}} $avCont 2>/dev/null)" if [[ -n "$avContStatus" ]]; then docker rm -f $avCont &>/dev/null fi done fi } ##################################### # Check and start Malice ELK Docker containers # Globals: # None # Arguments: # None # Returns: # 0 --> Success # 1 --> Error #------------------------------------- 133 133 Diseño de un Entorno Open Source para Análisis Automatizados de Malware checkMaliceELKContainers() { local elaStatus local kibStatus # Get containers information elaStatus="$(docker inspect -f {{.State.Status}} malice-elastic 2>/dev/null)" kibStatus="$(docker inspect -f {{.State.Status}} malice-kibana 2>/dev/null)" #Check containers information # If both containers are running, do not start Malice ELK if [[ "$elaStatus" != "running" || "$kibStatus" != "running" ]]; then if [[ "$elaStatus" != "running" ]]; then if [[ -n "$elaStatus" ]]; then # If the container exists, but it is not running: remove it docker rm malice-elastic &>/dev/null fi else # If only this container is running, stop it and remove it docker stop malice-elastic &>/dev/null docker rm malice-elastic &>/dev/null fi if [[ "$kibStatus" != "running" ]]; then if [[ -n "$kibStatus" ]]; then # If the container exists, but it is not running: remove it docker rm malice-kibana &>/dev/null fi else # If only this container is running, stop it and remove it docker stop malice-kibana &>/dev/null docker rm malice-kibana &>/dev/null fi if ! malice elk &>/dev/null; then err "Cannot start Malice ELK Docker containers" return 1 fi fi } ##################################### # Monitor spcified directory and send each new file to Cuckoo Sandbox # Globals: # None # Arguments: # 1 Extracted files directory to monitor # 2 Cuckoo Sandbox API URL # Returns: # 0 --> Success # 1 --> Error #------------------------------------- # extrFilesMonCuckoo() { local extrFile="" Anexo E: ninjaMind 134 ### NOTE: Follow "###" comments to manage exit properly inside intofywait loops ### Use "trap" to capture "PIPE" BEFORE inotifywait loops trap ':' PIPE # Monitor specified directory inotifywait -m -r -q -e close_write -e moved_to --format "%w%f" "$1" | while read extrFile; do ### Check errors: kill PIPE and then exit INSIDE inotifywait loops # Send the file to Cuckoo Sandbox if ! sendFileCuckoo "$2" "$extrFile"; then kill -PIPE 0 exit 1 fi done ### Use "trap" to capture "PIPE" AFTER inotifywait loops trap PIPE } ##################################### # Monitor specified directory and scan each new file with Malice # Globals: # None # Arguments: # 1 Extracted files directory to monitor # 2 Directory to save malice results # Returns: # 0 --> Success # 1 --> Error #------------------------------------- # extrFilesMonMalice() { local extrFile="" local extrFileName="" local extrFileDir="" local malResDir="" ### NOTE: Follow "###" comments to manage exit properly inside intofywait loops ### Use "trap" to capture "PIPE" BEFORE inotifywait loops trap ':' PIPE # Monitor specified directory inotifywait -m -r -q -e close_write -e moved_to --format "%w%f" "$1" | while read extrFile; do extrFileName="${extrFile##*/}" extrFileDir="${extrFile%$extrFileName}" # Check if extracted file is in a subdirectory if [[ "$1" != "$extrFileDir" ]]; then # Create the same subtree in Malice results directory # Use the same subtree to save result file malResDir="$2${extrFileDir##$1}" mkdir -p "$malResDir" &>/dev/null else 135 135 Diseño de un Entorno Open Source para Análisis Automatizados de Malware malResDir="$2" fi ### Check errors: kill PIPE and then exit INSIDE inotifywait loops # Check Docker daemon if ! docker info &>/dev/null; then err "Unable to communicate with docker daemon" kill -PIPE 0 exit 1 # Check and start Malice ELK Docker containers elif ! checkMaliceELKContainers; then kill -PIPE 0 exit 1 # Check and clean up antivirus Docker containers elif ! checkAVContainers; then kill -PIPE 0 exit 1 # Scan the file with Malice elif ! malice scan "$extrFile" >"${malResDir}${extrFileName}.mr" 2>/dev/null; then err "Cannot scan files with Malice" kill -PIPE 0 exit 1 fi done ### Use "trap" to capture "PIPE" AFTER inotifywait loops trap PIPE } ##################################### # Monitor specified directory and parse each new Malice result # Globals: # None # Arguments: # 1 Malice results directory to monitor # 2 Extracted files directory # 3 Cuckoo Sandbox API URL # 4 MISP API URL # Returns: # 0 --> Success # 1 --> Error #------------------------------------- maliceResultsMon() { local malResult="" local malResultName="" local malResultDir="" local extrFileName="" local extrFileDir="" ### NOTE: Follow "###" comments to manage exit properly inside intofywait loops ### Use "trap" to capture "PIPE" BEFORE inotifywait loops trap ':' PIPE # Monitor specified directory Anexo E: ninjaMind 136 inotifywait -m -r -q -e close_write --format "%w%f" "$1" | while read malResult; do ### Check errors: kill PIPE and exit INSIDE inotifywait loops malResultName="${malResult##*/}" malResultDir="${malResult%$malResultName}" extrFileName="${malResultName%.mr}" # Check if result file is in a subdirectory if [[ "$1" != "$malResultDir" ]]; then # Use the same subtree to locate extracted file extrFileDir="$2${malResultDir##$1}" else extrFileDir="$2" fi # Parse Malice Result malInfections="$(parseMaliceResults "$malResult")" if [[ $? -ne 0 ]]; then kill -PIPE 0 exit 1 elif [[ -n "$malInfections" ]]; then # Infection detected inf "AV - Infection detected: $extrFileName" if [[ -n "$4" ]]; then # Create an event if MISP option is set createEventMISP "$4" "${extrFileDir}${extrFileName}" "$malInfections" fi elif [[ -n "$3" ]]; then # Infection undetected # Send file if Cuckoo Sandbox option is set sendFileCuckoo "$3" "${extrFileDir}${extrFileName}" fi done ### Use "trap" to capture "PIPE" AFTER inotifywait loops trap PIPE } ##################################### # Manage exit cleaning up Docker containers and killing all subprocesses # Globals: # None # Arguments: # 1 Malice results directory # 2 PIDs of the subprocesses # Returns: # 0 --> Success # 1 --> Error #------------------------------------- manageExit() { if [[ -n "$1" ]]; then checkAVContainers &>/dev/null fi kill "$2" &>/dev/null echo 137 137 Diseño de un Entorno Open Source para Análisis Automatizados de Malware exit } ##################################### ### Main ### ##################################### main() { # Arguments variables local extFilDir="" local avResDir="" local mispURL="" local cuckooURL="" local hArg="" local vArg="" # List of subrocesses local nmPIDs="" # Check number of arguments if [[ $# -eq 0 ]]; then logo usage exit 1 fi # Extract options and their arguments into variables OPTIND=1 while getopts ":e:a:m:b:qvh" opt; do case "$opt" in e) [[ "$OPTARG" != */ ]] && OPTARG="$OPTARG/" extFilDir="$OPTARG" ;; a) [[ "$OPTARG" != */ ]] && OPTARG="$OPTARG/" avResDir="$OPTARG" ;; m) [[ "$OPTARG" != */ ]] && OPTARG="$OPTARG/" mispURL="$OPTARG" ;; b) [[ "$OPTARG" != */ ]] && OPTARG="$OPTARG/" cuckooURL="$OPTARG" ;; q) quietMode="-q" ;; v) vArg="-v" ;; h) hArg="-h" break ;; :) err "Option -$OPTARG requires an argument" Don’t be another brick in the wall. Manuel Martín González, 2011