Los mecanismos que realizan ejecución de funciones basados en eventos (triggers), han sido ampliamente aprovechados durante la fase de Installation del Cyber Kill Chain® (by Lockheed Martin), para ganar persistencia en los activos comprometidos por parte, tanto de pentesters y Red Teams como de actores reales en el teatro de operaciones del ciberespacio. Dichas técnicas son ampliamente documentadas en MITRE Att&ck bajo el identificador "T1546" [1], donde se exponen diversos métodos en los que se abusa de estos mecanismos, mayoritariamente en sistemas Windows. En las siguientes líneas se expone cómo sacar provecho del sistema Udev de Linux para precisamente esto, ganar persistencia, ampliando así las técnicas disponibles para tal fin.

Para poder entender bien de qué abusa esta técnica, es importante describir qué es exactamente Udev. Udev, a grandes rasgos, es el sistema que se encarga del manejo de dispositivos en el userland de los sistemas Linux desde la versión 2.6 del kernel. En la actualidad es parte de systemd. Entre sus principales responsabilidades está: la carga de los módulos de los dispositivos en el kernel o el manejo de los eventos de los dispositivos, mediante la interfaz uevent también del kernel; entre otras muchas. Es decir, al producirse un evento de dispositivo como conectar/desconectar un USB, este sistemas se encargará de manejar dicho evento y realizar las acciones que sean pertinentes, como por ejemplo: cargar el firmware del dispositivo para su correcto funcionamiento. Y es precisamente este el mecanismo del que nos aprovecharemos, para alcanzar nuestro objetivo.

Para poder cumplir con todo lo anteriormente descrito, Udev se basa en un sistema de reglas donde se definen esas acciones, proveyendo un mecanismo de reglas de coincidencia (match) entre los eventos y las acciones a realizar. Estas reglas se encuentran definidas en las rutas /usr/lib/udev/rules.d/ y /etc/udev/rules.d/. En caso de colisionar los nombres de algunas reglas, prevalecerán las definidas en /etc/. Estos archivos de reglas también deben acabar con una extensión .rules.

La técnica como tal es bien sencilla. Tan solo abusaremos de las funcionalidades provistas por el propio Udev.

Nos situamos en un contexto de postexplotación donde hemos alcanzado los privilegios suficientes, como para añadir reglas a alguna de las rutas anteriormente descritas, ya sea por escalada de privilegios o por una configuración/combinación insegura de permisos en dichas rutas.

En el siguiente ejemplo se muestra el contenido de una regla que lanzará nuestra carga útil a persistir (malware, implante, etc.) usando como disparador un evento de dispositivo USB, en este caso, la inserción del mismo. De esta forma al inserta un USB, nuestra carga útil entrará en ejecución.

ACTION=="add", SUBSYSTEM=="usb", RUN+="/bin/sh /tmp/payload.sh"

Para poder determinar qué disparadores nos puede interesar usar, como es obvio, podemos hacer uso de las mismas herramientas provistas por Udev, de esta manera no sólo podremos limitarnos al caso anteriormente descrito. Para ello te indicamos el camino a seguir y te sugerimos que profundices con los siguientes comandos y sus parámetros:

Adicionalmente te invitamos también a que profundices en la documentación de Udev [2].

$ udevadm monitor --environment

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[334578.418881] change   /devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight (backlight)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/intel_backlight
SUBSYSTEM=backlight
SOURCE=sysfs
SEQNUM=33473

En el bloque anterior se puede observar una traza sobre un evento obtenido con el primer comando arriba indicado, donde se muestra un evento lanzado al producirse una atenuación de la iluminación de la pantalla, en respuesta a la inactividad del usuario. Lo que significa que podríamos utilizar también este evento para disparar nuestra carga útil. De esta forma nos asegurariamos de que se lanzará nuestra carga útil cuando el usuario no estuviera enfrente de la máquina comprometida.

Una vez escrita la regla que nos interese, en la ruta adecuada, será necesario forzar una recarga de todas las reglas de Udev. Para ello es necesario que poseamos privilegios para lanzar la ya nombrada utilidad udevadm, mediante el comando udevadm control --reload. Otra forma de lograr esto es forzar un reinicio del sistema, bien sea porque tenemos privilegios para ello o porque podamos explotar algún fallo de denegación de servicio, que nos permita hacer que el sistema se reinicie. Contar con acceso físico también nos resolvería este problema.

¿Está tu EDR u otras soluciones observando Udev en busca de este tipo de persistencias? ¿Está tu organización y equipos de SecOps al tanto de está técnica de persistencia? Las técnicas de persistencia basadas en eventos (triggers) normalmente (como en este caso), eliminan la necesidad de tener nuestra carga útil en continua ejecución, lo que reduce considerablemente el ruido y la atención que podría atraer la ejecución continua de un proceso en el sistema, siempre y cuando claro, no se hiciera uso de otras técnicas de ocultación ya existentes. Si además a esto le sumamos el uso combinado que podríamos hacer de esta técnica de persistencia, con cargas útiles de tipo fileless o la utilización de GTFOBins, hacen estas técnicas especialmente interesantes para escenarios donde se requiera de una alta discreción y ocultación de nuestras cargas útiles, una vez comprometido el activo, aumentando probablemente el MTTD.

Para acabar, como hemos podido ver, esta técnica, lejos está de requerir grandes capacidades técnicas para su ejecución, un hecho que facilita que pueda ser utilizada por commodity attackers y no sólo por actores que dispongan de grandes recursos y capacidades operativas, como actores estatales y otros grupos APT, como si que podría llegar a ocurrir con otras TTPs.

[1] https://attack.mitre.org/techniques/T1546/
[2] https://linux.die.net/man/7/udev