Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
blackpill — Un rootkit del kernel de Linux escrito en Rust que utiliza un hipervisor tipo 2 hecho a medida, y programas eBPF XDP y TC. | Kitploit
Herramientas/GitHubGitHub/shard77/blackpill
Escalada de PrivilegiosMecanismos de PersistenciaEvasión de IDS/IPSMovimiento LateralShellcodePost-ExplotaciónComando y ControlRed TeamingDesarrollo de PayloadsExplotación de BinariosArchived
GitHub
34045hace 5 mesesRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
shard77/blackpill

blackpill

Un rootkit del kernel de Linux escrito en Rust que utiliza un hipervisor tipo 2 hecho a medida, y programas eBPF XDP y TC.

Ver Repositorio

BlackPill

BlackPill es un rootkit sigiloso para Linux hecho en Rust.

Open issues Commit activity License

Características

El rootkit está compuesto por múltiples módulos (hablando de módulos de Rust, no de módulos del kernel):

  • evasión de defensas: oculta archivos, procesos, conexiones de red, etc.
  • hooking: engancha syscalls e IDT
  • hipervisor: crea una máquina virtual para ejecutar código malicioso
  • persistencia: hace que el rootkit sea persistente tras el reinicio y resistente a la supresión
  • utilidades: varias utilidades

La arquitectura se ve de la siguiente manera:

Esquema simple de la arquitectura del rootkit

Y así es como se ejecuta el código malicioso desde el C2 hasta el invitado de la VM:

Diagrama de secuencia de ejecución de código del rootkit

El C2 envía mnemónicos x86_64 ensamblados y manipulados al rootkit, que luego los envía al invitado de la VM para ejecutarlos. El invitado de la VM está aislado del host y puede utilizarse para ejecutar código malicioso.

El kernel no ve los paquetes maliciosos entrantes, ya que son filtrados por el programa eBPF XDP y enviados al módulo LKM, y los paquetes salientes son modificados por el programa eBPF TC.

[!IMPORTANT]
Este proyecto aún está en desarrollo. ¡No todas las funciones funcionan!
No dudes en enviar issues o pull requests.

Hooking

El hooking es una capacidad fundamental del rootkit, implementada mediante kprobes en el kernel de Linux. Esta técnica intercepta y redirige la ejecución de funciones del sistema para monitorear o modificar su comportamiento. En el contexto de este rootkit, kprobes proporciona un mecanismo potente para interactuar con las funciones del kernel sin alterar directamente el código fuente.

Evasión de Defensas

Para garantizar el sigilo, el rootkit emplea dos mecanismos principales de detección anti-detección:

  1. Eliminación del Módulo de la Lista de Módulos del Kernel
    Cuando se carga un módulo del kernel, se añade a la lista de módulos del kernel, visible mediante herramientas como lsmod o /proc/modules. Para evitar la detección:

    • El rootkit se elimina manualmente de esta lista.
    • A pesar de ser eliminado de la lista, el módulo sigue operativo, lo que permite la ejecución continua de su funcionalidad.
  2. Hook de la Función filldir64 para Ocultar un Directorio Específico
    Para ocultar los archivos utilizados por el rootkit, se implementa un hook en la función filldir64. Esta función se invoca cuando un proceso lee el contenido de un directorio (por ejemplo, mediante las llamadas al sistema getdents o readdir).

    • Proceso de hooking:
      • El rootkit intercepta la función filldir64 usando kprobes.
      • Durante la ejecución, el manejador inspecciona las entradas de directorio devueltas al usuario.
      • Si una entrada coincide con el directorio /BLACKPILL-BLACKPILL (utilizado para almacenar archivos críticos del rootkit), se filtra y no se devuelve al usuario.

Hipervisor

Nuestro simple hipervisor se implementó siguiendo esto:

  1. Configuración inicial del sistema

    • Habilitar las extensiones de virtualización de hardware (Intel VT-x o AMD-V) en la BIOS/UEFI (el rootkit no hace esto, debe estar habilitado antes).
    • Configurar los registros de control (CR0, CR4 e IA32_EFER) para cambiar al modo VMX (Virtual Machine Extensions (Intel)) o SVM (Secure Virtual Machine (AMD)).
  2. Entrando en modo VMX o SVM

    • Inicializar las estructuras de datos específicas de la virtualización (VMCS para Intel o VMCB para AMD).
    • Programar las características del procesador, como las VM exits, para manejar las interacciones entre el invitado y el host.
  3. Gestión de Transiciones entre Host e Invitado

    • Configurar los puntos de entrada y salida para las máquinas virtuales (VM entry/exit).
    • Implementar lógica para interceptar llamadas al sistema sensibles realizadas por el invitado y analizar sus efectos.
  4. Creación del Sistema Invitado

    • Asignar memoria para el invitado e inicializar sus recursos (registros, pila, etc.).
  5. Comunicación

    • Usar canales de comunicación entre el rootkit y el hipervisor para transmitir comandos o datos.

Persistencia

La persistencia es una capacidad crítica de cualquier rootkit, ya que le permite mantener el control sobre el sistema objetivo incluso después de un reinicio.
En su implementación actual, el mecanismo de persistencia demuestra su funcionalidad creando un archivo de prueba en el sistema de archivos mediante el comando /bin/touch. Esta acción de marcador de posición muestra la capacidad del rootkit para ejecutar operaciones privilegiadas y puede extenderse para implementar estrategias de persistencia más avanzadas.

Ahora es inútil, ya que no es nuestra prioridad crear un rootkit de nivel APT, sino investigar más en torno a conceptos menos vistos.

Configurar el entorno de desarrollo

Se deben realizar varios pasos antes de compilar nuestro rootkit. El entorno de desarrollo se compone de:

  • una imagen de Alpine Linux que proporciona herramientas esenciales
  • un kernel compilado a medida con Rust activado
  • una máquina virtual QEMU acelerada por KVM

Comienza clonando el repositorio y sus submódulos superficiales:

root@kitploit:~
git clone [email protected]:DualHorizon/blackpill.git --recursive --depth 1

Dependencias importantes

En una distribución basada en Arch:

root@kitploit:~
sudo pacman -S qemu-base qemu-desktop docker grub

Kernel de Linux

En una distribución de Linux basada en Arch, instala Rust y otras dependencias:

root@kitploit:~
sudo pacman -S rust rust-src rust-bindgen
sudo pacman -S clang lld llvm

Luego necesitaremos las fuentes de Rust y bindgen:

root@kitploit:~
rustup component add rust-src clippy rustfmt
cargo install --locked bindgen-cli

Asegúrate de poder comenzar a compilar tu kernel con Rust ejecutando en la carpeta linux/:

root@kitploit:~
$ cd blackpill
$ pushd linux
$ make LLVM=1 rustavailable
Rust is available!
$ popd

Lanza la tarea de configuración de la primera vez, que configura y compila el kernel:

root@kitploit:~
make first-time-setup

[!IMPORTANT]
Si se te pide personalizar opciones, pulsa Enter cada vez.

Rootkit

Puedes compilar el módulo del kernel de Rust (out-of-tree) con:

root@kitploit:~
make

Lanza la VM con:

root@kitploit:~
make vm

Dentro de la VM, se inicia sesión automáticamente como root. Puedes habilitar el módulo:

root@kitploit:~
$ modprobe blackpill
# puedes revisar los registros del kernel con
$ dmesg

Uso

Escalada de Privilegios Local

Una vez iniciada la VM, puedes usar el comando anterior para escalar tus privilegios:

root@kitploit:~
mkdir ImFeelingRootNow_<PID>

Reemplaza <PID> con el ID de proceso del proceso al que quieres escalar el privilegio.

C2

Descripción

Este simple C2 envía opcodes x86-64 a la máquina infectada a través de UDP y recibe paquetes TCP. Sus funciones ahora se limitan a la interacción de bajo nivel con la máquina, pero pueden permitir muchos usos prácticos con más wrappers.

Uso

Configura el cliente de Python:

root@kitploit:~
cd blackpill-c2
poetry install
poetry shell
python client.py

Después de lanzar el cliente con tus argumentos ([ip] [port]) deberías obtener:

root@kitploit:~
$ python client.py 0.0.0.0 1339
Connected to rootkit!

Luego puedes usar el comando help para mostrar los comandos disponibles:

root@kitploit:~
blackpill: help
Available Commands
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Command                             ┃ Description                                             ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ read_virt_memory <address>          │ Read 4 bytes (32 bits) memory at 'address'              │
│ write_virt_memory <address> <value> │ Write 4 bytes (32 bits) memory at 'address'             │
│ launch_userland_binary <path>       │ Launch a userland binary at 'path'                      │
│ change_msr <msr> <value>            │ Change the value of a Model Specific Register (MSR)     │
│ read_phys_memory <address> <value>  │ Read 4 bytes (32 bits) of physical memory at 'address'  │
│ write_phys_memory <address> <value> │ Write 4 bytes (32 bits) of physical memory at 'address' │
│ stop_execution                      │ Stop the execution of the guest VM                      │
│ change_vmcs_field <field> <value>   │ Change a VMCS field to 'value'                          │
│ help                                │ Show this help message                                  │
└─────────────────────────────────────┴─────────────────────────────────────────────────────────┘

Créditos

Configuración del entorno:

  • Setting Up an Environment for Writing Linux Kernel Modules in Rust - The Linux Foundation
  • Kernel config qemu-busybox-min.config patch
  • Rust out-of-tree module
Descargar herramienta
  • Todas las demás entradas de directorio se devuelven con normalidad, garantizando la transparencia para las herramientas de espacio de usuario.
  • Uso de Programas eBPF XDP y TC para Modificar el Tráfico de Red Entrante y Saliente
    Para normalizar nuestras comunicaciones de red maliciosas, utilizamos programas eBPF XDP (eXpress Data Path) y TC (Traffic Control). De este modo, podemos:

    • Interceptar paquetes entrantes (ingress) específicos con el programa XDP en el nivel más bajo de la red, haciendo coincidir la firma del payload TCP manipulado de nuestro C2, que luego redirigimos a un mapa BPF personalizado para su procesamiento por la VM/LKM.
    • Interceptar paquetes salientes (egress) específicos con el programa TC, haciendo coincidir los paquetes TCP generados por la VM/LKM, que luego modificamos sobrescribiendo su payload con los datos de respuesta de nuestro C2. Los paquetes originales son retransmitidos automáticamente por TCP, manteniendo la apariencia de tráfico legítimo.