Velociraptor. Parte 2: Clientes

por Alberto Jódar
0 comentario 18 minutos lectura
Artículos de la serie
Velociraptor
  1. Velociraptor. Parte 1: Servidor
  2. Velociraptor. Parte 2: Clientes
  3. Velociraptor. Parte 3: Funciones principales

En la entrada anterior pintamos el esquema del laboratorio y, sobre este, desplegamos un servidor de Velociraptor en una Ubuntu Desktop. En esta entrada se van a añadir clientes a este servidor para que puedan ser administrados remotamente por Velociraptor.

Laboratorio

Recordamos la infraestructura:

Conectividad con el servidor

Cada despliegue deberá ser adaptado a los requisitos y necesidades. En un despliegue habitual, los clientes deben poder alcanzar el servidor en el puerto 8000, pero muy probablemente no deberían acceder al puerto de la consola web (el 8889). la interfaz web estar reservada a los accesos por parte de los administradores y analistas de seguridad.

Cuando creamos el yaml del servidor, se despliega así. Desde la red vamos a poder llegar al puerto 8000 pero no al 8889.

En cambio, si nos conectamos desde la Windows 10 al 8889 desde el navegador para acceder a la GUI:

Aquí vemos que el yaml del servidor define la URL de acceso de la GUI como «127.0.0.1». Es decir, que solo es accesible desde la propia máquina.

Aunque no se recomienda para un entorno de producción, podemos editarlo para nuestro laboratorio y así conseguir que los clientes también accedan a la GUI.

Instalación de Velociraptor en cliente

Descargamos como en la entrada 1 el release, pero en este caso para el sistema operativo de esta máquina (Windows):

Ejecutamos el msi descargado en la máquina y nos saltamos el aviso de SmartScreen.

Una vez finalizado, nos ha creado una carpeta en «C:\ProgramFIles\Velociraptor».

El fichero yaml que se crea por defecto cuando ejecutamos el msi no es válido. Debemos rellenarlo con el yaml que generó el binario de Velociraptor cuando lanzamos el asistente en la entrada 1.

Una vez copiado, guardamos y volvemos a ejecutar el MSI. En la carpeta de Velociraptor debe haber aparecido un fichero con texto «writeback». Si esto es así es que está correcto

Si todo ha funcionado correctamente ya tenemos al cliente unido. Es posible que haya algo de demora hasta que lo vemos en la consola. Directamente, si pulsamos sobre la lupa en la interfaz web veremos el listado completo de clientes

Despliegue mediante GPO

Imaginemos la siguiente situación. Tenemos un incidente en uno de nuestros clientes y debemos desplegar Velociraptor en más de mil máquinas. Parece que ir una a una ejecutando el msi y copiando el yaml con la configuración no es la mejor opción. Vamos a ver como hacer un despliegue mediante GPO.

Nueva infraestructura

Vamos a mover el servidor de Velociraptor a una infraestructura de laboratorio donde hay un directorio activo desplegado. Este es el laboratorio que hemos ido creando en la serie sobre el laboratorio de detección. Este es el primer artículo de esa serie.

Ahora tenemos el server con la 192.168.100.110. Pero para no andarnos con jaleos de nombres, vamos a registrarlos en el DNS del DC, que para eso lo tenemos. Registramos una entrada con nombre «adminserver» para esta IP

Esto nos permite cambiar la configuración yaml tanto de cliente como de servidor de Velociraptor para que el puerto 8000 al que se conectan los clientes sea accesible por nombre:

GPO que instala el servicio

Podemos hacer una GPO que instale el msi en las máquinas. ¿Cómo se hace esto? Os dejo un enlace a la documentación oficial de Microsoft.

Pero hay un problema. Como hemos visto antes, primero hay que ejecutar el MSI y que se instale. Esto crea la carpeta en el equipo. Hay que copiar la configuración del cliente en yaml y ejecutar de nuevo el MSI. No podemos hacer todo este proceso mediante una GPO.

Hay formas de resolver esto. Podemos generar un MSI específico desde el servidor de Velociraptor. Abrimos la consola web y vamos a la sección «Server Artifacts».

Buscamos el artefacto «Server.Utils.CreateMSI».

Dejamos las opciones por defecto de momento. Ya entraremos en otras opciones de despliegue cuando veamos funcionalidades más avanzadas. Así que seleccionamos «Launch»

El fichero MSI lo tendremos en la sección «Uploaded Files». Si hacemos clic en su «vfs_path» nos lo descargamos.

Ya podemos mover el MSI al DC para comenzar a crear la GPO.

Crear ruta de red compartida

Lo primero que vamos a hacer es crear en el DC una ruta compartida de red donde dejar los binarios y los ficheros de configuración que se ejecutaran en los clientes. Creamos una carpeta en la ruta C:\ del DC con todos los ficheros necesarios para Velociraptor. Es decir, dejamos el msi que acabamos de generar

Y la hacemos accesible a través de la red:

Ya la tenemos accesible a todos los usuarios del dominio:

Crear GPO

Vamos al editor de políticas del DC y creamos una nueva GPO bajo la OU de equipos Windows (yo tengo las OUs organizadas así, cada uno que la despliegue donde quiere que la GPO aplique):

La he creado con nombre VeloClientMSI

La editamos con los siguientes parámetros. Añadimos en la edición de la GPO un nuevo paquete a la sección de la instalación de software.

Y seleccionamos el MSI desde la ruta de red:

Seleccionamos «Asignada» para que se instale automáticamente en los equipos de usuario:

Listo. Ya podemos guardar la GPO. En el cliente forzamos la actualización de políticas y (es posible que nos toque reiniciar):

GPO para ejecución sin agente

A veces vamos a querer que no se instale un servicio en la máquina, sino que se ejecute el ejecutable de Velociraptor hasta que ya no sea necesario. Este es un despliegue muy típico de un incidente, donde desplegamos mientras dura el incidente y luego dejamos de ejecutar Velociraptor en las máquinas dejándolas limpias. Para ello os propongo otro tipo de despliegue con GPO.

Contamos que en la carpeta compartida hemos dejado el ejecutable de Velociraptor y el yaml de configuración.

En la GPO básicamente lo que vamos a hacer es crear una tarea programada que lance Velociraptor con el yaml de configuración que hay en la careta compartida.

Lanzamos una tarea inmediata para que no tengamos que esperar a que se reinicien los equipos

Configuramos:

Añadimos dentro de acción una nueva que inicie un programa con las siguientes características:

  • Programa: \\DC01.dfir.pills\Velociraptor\velociraptor.exe
  • Argumentos: –config \\DC01.dfir.pills\Velociraptor\client.config.yaml client -v

En configuración podemos indicar que la tarea se ejecute por un tiempo determinado. Por ejemplo, podemos darle 3 días si calculamos que es lo que necesitamos para gestionar el incidente. Al ser entorno de laboratorio no le vamos a poner un tiempo máximo.

Consejo: Para evitar que el mismo cliente se ejecute muchas veces, podemos lanzar la ejecución con un flag «mutant» con un string que previene que el mismo ejecutable se ejecute más de una vez con el mismo flag. Editaríamos la tarea para:

  • Programa: \\DC01.dfir.pills\Velociraptor\velociraptor.exe
  • Argumentos: –config \\DC01.dfir.pills\Velociraptor\client.config.yaml client -v –mutant DFP

Conclusiones

Listo, ya tenemos el servidor y los agentes desplegados en las máquinas. En la siguiente entrada vamos a destripar las funcionalidades de Velociraptor.

Hasta la próxima.

Artículos relacionados

Deja un comentario

* Al utilizar este formulario usted acepta el almacenamiento y tratamiento de sus datos por parte de este sitio web.

Este sitio web utiliza cookies para mejorar su experiencia Aceptar Leer más