cenobyte-vincit/slot2UEFI-GRUB2-Bootkit, das über eine NVRAM-Bootoption ein Pre-Boot-Netzwerk-Implantat installiert, per Chainload eine UKI lädt, einen dracut-Payload ausführt und per kexec den Standard-Kernel startet.
slot2: ein zweistufiges UEFI-GRUB2-Bootkit, das ein Pre-OS-Netzwerk-Implantat auf Amazon Linux 2023 auf AWS EC2 UEFI x86_64 persistent macht.
von cenobyte [email protected] 2026
https://github.com/cenobyte-vincit/slot2
slot2 ist ein Bootkit für Amazon Linux 2023 auf EC2. Die AWS EC2 UEFI-Firmware lädt es zuerst. Ein eingebettetes Implantat läuft im Bootkit-UKI (Unified Kernel Image: eine EFI-Datei mit einem Bootkit-Kernel und initrd), bevor das Stock-Betriebssystem startet, Netzwerk inklusive, dann wird kexec verwendet, um den Stock-Kernel zu starten, den ein normaler Boot verwendet hätte. Das Betriebssystem, das hochkommt, ist das echte, unveränderte.
Die Persistenz erfolgt über eine UEFI-NVRAM-Ladeoption und zwei Dateien, eine Bootkit-ESP-Datei und ein Bootkit-UKI; es wird kein Userspace-Helfer-/Rootkit-Dienst verwendet/benötigt, und es handelt sich nicht um einen ersetzten Vendor-Bootloader. In slot2 ist 98-payload.sh das Implantat, das für Pre-Boot-C2/Infil/Exfil und beliebige Festplattenschreibvorgänge verwendet wird, um Payloads wie RATs oder kernelbasierte Rootkits auf den Dateisystemen des Ziels einzufügen. Das Implantat in diesem Tree ist eine Demonstration: Es schreibt /root/HELLO.TXT und bringt das Netzwerk hoch, um eine Internet-/Netzwerkverbindung herzustellen, was in einer Operation ein Netzwerk-Infil oder -Exfil sein könnte.
Die UEFI-Firmware wählt keinen Kernel von sich aus. Sie durchläuft eine BootOrder von NVRAM-Ladeoptionen, jede ein nummerierter Slot (Boot0001, Boot0002, ...), der auf eine EFI-Executable auf der ESP zeigt. Auf EC2 ist Boot0001 immer vorhanden: der Amazon-EBS-Eintrag, der das Stock-\EFI\BOOT\BOOTX64.EFI startet. slot2 fügt Boot0002 hinzu, der auf eine zweite Datei auf derselben ESP zeigt, und setzt Boot0002 an die erste Stelle der BootOrder. Die Firmware hat Boot0001 weiterhin als Fallback.
Diese zweite Datei muss etwas sein, das die Firmware ausführen kann, und sie muss das Bootkit-UKI auf dem Root-Dateisystem erreichen, das die Firmware nicht sehen kann. GRUB wird verwendet, weil es GPT und XFS lesen, das UKI finden und es chainloaden kann. Das Image ist ein benutzerdefiniertes grub2-mkimage, nicht das paketierte Amazon-GRUB; das Stock-BOOTX64.EFI bleibt dort, wo der Vendor es platziert hat. GRUBs einzige Aufgabe hier ist es, an das UKI zu übergeben.
Der UKI-Kernel führt dann 98-payload.sh aus, danach verwendet 99-kexec-stock.sh kexec, um den Stock-Kernel und initrd zu starten, den ein normaler BLS-Boot verwendet hätte.
EC2 UEFI NVRAM
├── Boot0001 -> stock \EFI\BOOT\BOOTX64.EFI (untouched)
└── Boot0002 -> bootkit \EFI\BOOT\.BOOTX64.EFI (created; first on BootOrder)
|
v
ESP (VFAT) /boot/efi
└── /EFI/BOOT/
├── BOOTX64.EFI stock (untouched) <- Boot0001
└── .BOOTX64.EFI bootkit GRUB2 PE --chainload--+ <- Boot0002
|
root FS (XFS, typical AL2023) |
└── /var/lib/systemd/boot/ |
└── uki.efi <------------------------------------------+
|
| 98-payload.sh, then 99-kexec-stock.sh
| resolve stock target under /sysroot/boot/:
| loader/entries/*.conf (BLS + grubenv; AL2023 primary)
| grub2/grub.cfg (legacy fallback)
|
+-- kexec ----------------------------------------+
|
/boot (stock, untouched) |
├── vmlinuz-* <--------------------------------------------+
└── initramfs-*.img
|
+-- stock initrd -> stage-2 stock userspace
Wenn kexec fehlschlägt, läuft Stage 1 auf dem UKI-Kernel weiter. Die Maschine bleibt bootfähig.
Das Implantat ist 98-payload.sh, ein dracut-pre-pivot-Hook innerhalb des Bootkit-UKI. Es ist kein Userspace-Dienst nach dem Boot. Die Implementierung in diesem Tree ist eine Demo: /sysroot read-write neu einhängen, /root/HELLO.TXT schreiben, NICs hochfahren, DHCP, dann wget auf ifconfig.me (5s-Budget). Das DHCP-Lease und die Resolver-Datei bleiben im initrd (/tmp/udhcpc.*.lease, /etc/resolv.conf); sie werden nicht auf das echte Root geschrieben. Ein Netzwerkfehler blockiert kexec nicht.
Stage 1 hat das echte Root unter /sysroot (typischerweise XFS, rw neu eingehängt). /boot ist /sysroot/boot. Zusätzliche EBS-Volumes werden nicht eingehängt, es sei denn, der Hook hängt sie ein. Das schlanke initrd enthält busybox udhcpc und wget. ip(8) ist das Binary des echten Roots, ausgeführt über den initrd-Loader.
Der Runtime-Host ist das Ziel (die EC2-Instanz, die deploy ausführt und dann in das Bootkit neu startet).
uefi oder uefi-preferred unterstützen/boot/efi (systemd-Automount ist in Ordnung; deploy löst ihn aus)libefivar und libefiboot (deploy ist dynamisch gelinkt; beide sind im Standard-OS enthalten)ARM64 / Graviton ist nicht getestet und daher nicht unterstützt (noch?).
Amazon Linux 2023 x86_64.
./install-dependencies.sh/boot/vmlinuz-$(uname -r) und /boot/initramfs-$(uname -r).img des laufenden Kernels (diese Dateien werden in das UKI gepackt)cc, make, pkg-config, grub2-mkimage, objcopy, kexec, openssl, xxd./install-dependencies.sh ist der Bootstrap. Es installiert die oben genannten dnf-Pakete (plus grub2-efi-x64-modules, systemd-boot-unsigned, efivar-devel, dracut) und lädt die gepinnten busybox-Binaries udhcpc und wget herunter.
Auf dem Build-Host:
./install-dependencies.sh
make
Ein bloßes make schreibt uki.efi, BOOTX64.EFI und deploy. Es schreibt weder die ESP, noch /var/lib/systemd/boot, noch NVRAM. Trailer-Magic und SOURCE_DATE_EPOCH sind in ARCHITECTURE.md beschrieben.
Kopiere das mitgelieferte deploy-ELF auf das Ziel. Kein Compiler. uki.efi und BOOTX64.EFI sind bereits im Trailer enthalten.
scp deploy user@target-host:~/
Auf einer colocated AL2023-Instanz ist die Kopie optional; führe ./deploy aus dem Build-Baum aus.
Beim nächsten Neustart lädt die Firmware Boot0002 das ESP-PE, das PE lädt das UKI nach, die Payload wird ausgeführt, dann startet kexec den Stock-BLS-Kernel (ARCHITECTURE.md). Wenn deploy die Meldung EFI variables are not supported on this system ausgibt, ist dieser Boot ein BIOS-Boot; siehe Requirements.
deploy erfordert Root-Rechte. Ohne Argumente gibt es Trailer-Offsets und NVRAM aus und schreibt nichts. -y platziert die Images und NVRAM und löscht anschließend diese ausführbare Datei und hebt deren Verknüpfung auf. Jedes andere Argument gibt die Usage aus.
./deploy # dump only: trailer offsets and NVRAM; no writes
./deploy -y # plant, then wipe and unlink this binary
reboot
Bei einem erfolgreichen -y-Lauf plant der Prozess nach seinem Beenden das Löschen seiner eigenen ausführbaren Datei (/dev/urandom, Truncate, Unlink), sodass ls deploy fehlschlagen sollte. Die platzierte UKI und das Bootkit-GRUB-Image bleiben erhalten.
-y schreibt /var/lib/systemd/boot/uki.efi (root:root, 0500) und /boot/efi/EFI/BOOT/.BOOTX64.EFI (root:root, nach bestem Bemühen 0700 auf VFAT) und erstellt dann NVRAM Boot0002 und setzt es an die erste Stelle der BootOrder. Das originale BOOTX64.EFI bleibt Boot0001.
make
Das baut die drei Produkte. Es gibt keine In-Tree-Testsuite. Ein kolokalisiertes make auf einer AL2023-Instanz, die später ./deploy -y ausführen wird, ist kein Beweis für eine saubere Laufzeitumgebung.