Marco forense de respuesta a incidentes
Aplicación personalizada para la presentación asíncrona de datos forenses sobre un backend Elasticsearch.
Esta aplicación está diseñada para ingerir un archivo de "collections" de Mandiant Redline y ofrecer flexibilidad en búsqueda/apilado y etiquetado.
La aplicación nació de la imposibilidad de controlar múltiples investigaciones (o cientos de endpoints) en un solo panel de control.
Para ingerir auditorías de Redline, creamos nightHawkResponse, una aplicación GOpher completamente funcional diseñada para acompañar a este framework. El código fuente de la aplicación está disponible en este repositorio; se ha compilado un binario que se ejecuta dentro del ISO listo para ingerir desde el primer arranque.
Actualmente estamos desarrollando una nueva versión importante y la lanzaremos en marzo de 2020. La nueva versión tiene como objetivo lograr lo siguiente:
Nos dimos cuenta de que había demasiadas partes móviles para operar eficazmente todo el repositorio, gestionar fácilmente las entidades y mantener todo actualizado. También creemos que los datos centrales que residen en Elastic deberían ser utilizados de manera más efectiva por Kibana, por lo que decidimos hacer esto realidad desarrollando un plugin que haga esto junto al increíble flujo de trabajo de Kibana.
Instalación
La documentación de la API se encontrará en la Wiki
01/09/2016: Versión 1.0.3
Funcionalidades:
Demostración en video: nightHawk Response Platform
Para facilitar las cosas a los usuarios de nightHawk, creamos un ISO con todo configurado listo para usar. Eso significa que obtienes lo siguiente:
/opt/nighthawk/etc/nightHawk.json. Iniciando el sistema:
Antes de construir su máquina virtual con el ISO proporcionado, tenga en cuenta lo siguiente:
Pendiente: Configurar el servicio Elastic como nodos duales con 1/4 de la memoria del sistema asignada por nodo. Esto significa que si le asignas 2GB de RAM, cada nodo ES tendrá 512mb y el sistema se quedará con 1GB para operar.
Si deseas configurarlo de otra manera, ingresa por SSH a la máquina y configúralo a tu gusto.
Se debe considerar un mínimo de 20GB. Un archivo de auditoría puede ser grande, por lo que se recomienda asignar mucho almacenamiento para manejar la ingesta de muchas colecciones.
Pendiente: Configuración de almacenamiento basado en usuario para instancias a gran escala. Si deseas configurar particiones adicionales, puedes hacerlo tú mismo; se pueden realizar algunos cambios para apuntar el almacenamiento de datos de ES a tu nueva partición.
Instalación:
Descargar ISO: nightHawk v1.0.3
Configure el hardware, monte el ISO en la VM, inicie el script de instalación.
Una vez completado, en su navegador (Chrome/FireFox), vaya a; https://192.168.42.173.
Inicie sesión en el sistema con 'nighthawk/nighthawk' - haga clic en 'goto site' para acceder a la aplicación
Si necesita acceder a Kibana, vaya a; https://192.168.42.173:8443.
Si necesita conectarse por SSH a la máquina, los detalles de inicio de sesión son; admin/nightHawk.
Si desea cambiar la dirección IP (reflejada en toda la aplicación); /opt/nighthawk/bin/nighthawkctl set-ip <new_ipaddress>
El script de recolección de auditorías de Redline se puede encontrar en la raíz de este repositorio. Úselo cuando utilice el recolector independiente de Redline, ya que devolverá los documentos que necesita para poblar nightHawk correctamente.
Carga:
IMPORTANTE:
Creación del archivo zip de auditoría para cargar (Recolector independiente de Redline):
paso_1: Navegue a Sessions\AnalysisSessionX\Audits<NombreDelEquipo> donde X es el número de análisis, que es 1 en la mayoría de los casos.
paso_2: Cree un zip de la carpeta que contiene los archivos de auditoría, por ejemplo, 20160708085733
paso_3: Cargue 20160708085733.zip
IMPORTANTE: Use el archivo de auditoría HX existente (Colector HX): Las auditorías de FireEye HX tienen una extensión que termina en .mans. La auditoría de HX difiere del recolector de Redline porque el .mans que devuelve es en realidad un archivo zip. Esto significa que se puede cargar directamente a diferencia de la auditoría de Redline, para la cual debe seguir las instrucciones anteriores.
Navegue al icono 'Upload' en la barra de navegación, seleccione un .zip de auditoría (o varios), un nombre de caso (de lo contrario, el sistema le proporcionará uno) y envíe. Si ha utilizado nuestro script de auditoría de Redline para construir su colección, siga las instrucciones del 'Recolector Redline' justo arriba.
Una vez procesado, el endpoint aparecerá en el nodo del árbol 'Current Investigations'. Debajo del endpoint se le presentarán todos los tipos de auditoría disponibles para ese endpoint. La función de carga de esta aplicación web genera subprocesos pOpen que llaman a la aplicación GO para analizar la auditoría de Redline y enviar los datos a Elasticsearch. Hay dos opciones para cargar: una es secuencial y la otra es concurrente.
Tenga en cuenta: las cargas concurrentes están limitadas a 5 a la vez y pueden consumir muchos recursos; si tiene una máquina con poca potencia, restrinja el uso de esta función a 2-3.
Etiquetado:
Puede hacer clic en cualquier fila de cualquier tabla (en la vista de respuesta) para etiquetar esos datos. Una vez etiquetados, puede ver los comentarios en la vista de comentarios.
Elasticsearch:
Hay asignaciones personalizadas (proporcionadas en la raíz del git) y comentarios de asesoramiento sobre lo siguiente:
Los documentos se indexan a través de la aplicación GO como relación padre/hijo. Esto se eligió porque proporciona una ruta relativamente lógica para ver los documentos, es decir, el padre es el nombre del endpoint y los hijos son los tipos de auditoría. Realizar agregaciones en un documento relacional padre/hijo a escala también parece tener sentido. El framework de apilado se basa en construir una matriz de padres para luego obtener todas las agregaciones de documentos hijos para ciertos tipos de auditoría.
Las configuraciones de Elasticsearch requieren ajuste y reconocimiento de diseño adecuado. La fragmentación es importante de entender debido a la forma en que estamos vinculando documentos padre/hijo. El hijo SIEMPRE se enruta al padre, no puede existir por sí solo. Esto significa que se debe considerar cuántos fragmentos residen en el índice. Por lo que entendemos, puede ser aconsejable elegir una configuración que incorpore muchos nodos con fragmentos únicos. Para obtener rendimiento de este tipo de configuración, estamos trabajando en búsquedas enrutadas por fragmentos.
Actualmente estamos trabajando en diseñar la mejor configuración posible para búsquedas rápidas.
Esta aplicación está diseñada para escalar enormemente. Desde el concepto de diseño inicial, pudimos ejecutarla sin problemas en una VM de Ubuntu de un solo CPU y 2GB con 3 nodos ES (Macbook Pro), con alrededor de 4 millones de documentos (o 50 endpoints ingeridos). Si se va a producción, ejecutando una configuración con 64/128GB de RAM y almacenamiento SAS, podría mantener un tiempo de respuesta ultrarrápido en la recuperación de documentos mientras muchos analistas trabajan en la aplicación a la vez.
Consideraciones:
Procesamiento mixto de DataTables:
Hay varios tipos de auditoría ingeridos que son demasiado grandes para devolver todos los documentos a la tabla. Por ejemplo, el historial de URL y el Registro pueden devolver 15k documentos al DOM, renderizar esto pondría presión en el navegador del cliente. Para combatir esto, estamos utilizando procesamiento del lado del servidor para paginar los resultados de ciertos tipos de auditoría. Esto significa que también puede buscar sobre documentos en un tipo de auditoría utilizando Elasticsearch en el backend.
Etiquetado:
Actualmente podemos etiquetar documentos y ver esos comentarios. Podemos actualizarlos o cambiarlos. El analista puede dar contexto como Fecha/Nombre del Analista/Comentario al documento.
Dependencias (todas preinstaladas):
elasticsearch-dsl.py
django 1.8
python requests
Pendientes:
Manejadores de procesos (en progreso).
Deslizadores de selección de tiempo para generadores basados en tiempo (en progreso).
Menú contextual para investigaciones actuales/anteriores.
Contexto de etiquetado. El sistema de etiquetado se integrará en un bucle de websocket para comentarios en vivo a través de los paneles de analistas (en progreso).
Contexto de la aplicación.
Capacidad de mover endpoints entre cualquiera de los contextos.
Posible rediseño del árbol de nodos para que esté impulsado por la fecha de investigación.
Apilado selectivo; actualmente el selector de nodo raíz está habilitado.
Búsquedas enrutadas por fragmentos.
Plantilla de script de auditoría de Redline.
Integración más extensa con AngularJS (en progreso).
Diseño responsive. (en progreso).
Página de control administrativo para la configuración de ajustes principales (en progreso).
Autores y notas:
Siempre estamos buscando personas de ideas afines que quieran contribuir a este proyecto; no somos gurús del diseño web de ninguna manera. Si cree que podemos hacer algo mejor, solicite un pull request y si nos gusta, lo fusionaremos.
Daniel Eden & Roshan Maskey
Créditos:
Mandiant Redline devs, AngularJS, Django devs, Angular-DataTables/DataTables, D3 (Bostock), Elasticsearch/ES-dsl.py, jsTree, qTip, GOlang, Python, Fahad Abdulaal (Logo/Video).
