cenobyte-vincit/slot2بوتكيت UEFI GRUB2 يثبّت غرسة شبكية قبل الإقلاع عبر خيار إقلاع NVRAM، ويقوم بتحميل تسلسلي (chainload) لصورة نواة موحدة (UKI)، وينفّذ حمولة dracut، ثم يستخدم kexec للإقلاع إلى النواة الأصلية.
slot2: برنامج إقلاع خفي (bootkit) ثنائي المراحل لـ UEFI GRUB2 يُبقي على برمجية مزروعة (implant) شبكية تعمل قبل نظام التشغيل على Amazon Linux 2023 على AWS EC2 UEFI x86_64.
بواسطة cenobyte [email protected] 2026
https://github.com/cenobyte-vincit/slot2
slot2 هو برنامج إقلاع خفي (bootkit) لـ Amazon Linux 2023 على EC2. تُحمّله برمجية AWS EC2 UEFI الثابتة (firmware) أولاً. تعمل برمجية مزروعة مضمّنة داخل UKI الخاص بالبرنامج الخفي (Unified Kernel Image: ملف EFI واحد يحتوي على نواة bootkit وinitrd) قبل إقلاع نظام التشغيل الأصلي، بما في ذلك الشبكة، ثم يُستخدم kexec لتشغيل النواة الأصلية التي كان الإقلاع الطبيعي سيستخدمها. نظام التشغيل الذي يبدأ هو النظام الحقيقي الأصلي.
تتم الاستدامة (persistence) عبر خيار تحميل في UEFI NVRAM وملفَّين، ملف bootkit ESP وملف bootkit UKI؛ لا يُستخدم/يُطلب أي مساعد أو خدمة rootkit في مساحة المستخدم (userspace)، وليس محلّلاً محلّ محمّل إقلاع البائع (vendor bootloader). في slot2، يُعدّ 98-payload.sh هو البرمجية المزروعة المستخدمة لـ C2/التسلل/التسريب قبل الإقلاع والكتابات التعسفية على القرص لإدراج حمولات مثل RATs أو rootkits قائمة على النواة على أنظمة ملفات الهدف. البرمجية المزروعة في هذه الشجرة هي عرض توضيحي: تكتب /root/HELLO.TXT وتُشغّل الشبكة لإنشاء اتصال بالإنترنت/الشبكة، والذي قد يكون في عملية ما تسللاً أو تسريباً شبكياً.
لا تختار برمجية UEFI الثابتة نواة بنفسها. بل تمرّ عبر BootOrder من خيارات تحميل NVRAM، كل منها فتحة مرقّمة (Boot0001، Boot0002، ...) تشير إلى ملف EFI تنفيذي واحد على ESP. على EC2، يكون Boot0001 موجوداً دائماً: مدخل Amazon EBS الذي يبدأ \EFI\BOOT\BOOTX64.EFI الأصلي. يضيف slot2 المدخل Boot0002، مشيراً إلى ملف ثانٍ على نفس ESP، ويضع Boot0002 أولاً في BootOrder. تظل البرمجية الثابتة تملك Boot0001 كخيار احتياطي.
يجب أن يكون ذلك الملف الثاني شيئاً يمكن للبرمجية الثابتة تنفيذه، ويجب أن يصل إلى bootkit UKI على نظام ملفات الجذر، وهو ما لا تستطيع البرمجية الثابتة رؤيته. يُستخدم GRUB لأنه يستطيع قراءة GPT وXFS، والعثور على UKI، وتحميله بالتسلسل (chainload). الصورة هي grub2-mkimage مخصّصة، وليست GRUB الخاص بـ Amazon المعبّأ؛ يبقى BOOTX64.EFI الأصلي حيث وضعه البائع. مهمة GRUB الوحيدة هنا هي تسليم الأمر إلى UKI.
ثم تشغّل نواة UKI السكربت 98-payload.sh، ثم يستخدم 99-kexec-stock.sh الأمر kexec لتشغيل النواة الأصلية وinitrd التي كان إقلاع BLS الطبيعي سيستخدمها.
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
إذا فشل kexec، تستمر المرحلة 1 على نواة UKI. يبقى الجهاز قابلاً للإقلاع.
البرنامج المزروع هو 98-payload.sh، وهو خطاف dracut pre-pivot داخل bootkit UKI. وهو ليس خدمة فضاء مستخدم بعد الإقلاع. تنفيذ هذه الشجرة هو عرض توضيحي: إعادة تركيب /sysroot للقراءة والكتابة، وكتابة /root/HELLO.TXT، وإحضار واجهات الشبكة (NICs) إلى وضع التشغيل، ثم DHCP، ثم wget لـ ifconfig.me (ميزانية 5 ثوانٍ). يبقى عقد DHCP وملف المحلل (resolver) في الـ initrd (/tmp/udhcpc.*.lease، /etc/resolv.conf)؛ ولا يُكتبان على الجذر الحقيقي. فشل الشبكة لا يعيق kexec.
لدى المرحلة 1 الجذر الحقيقي عند /sysroot (عادةً XFS، معاد تركيبه rw). و/boot هو /sysroot/boot. لا تُركَّب أحجام EBS الإضافية إلا إذا ركّبها الخطاف. يشحن الـ initrd النحيف busybox udhcpc وwget. أما ip(8) فهو ثنائي الجذر الحقيقي، يُشغَّل عبر محمّل الـ initrd.
مضيف التشغيل هو الهدف (نسخة EC2 التي تشغّل deploy ثم تعيد الإقلاع إلى bootkit).
uefi أو uefi-preferred/boot/efi (التركيب التلقائي systemd مقبول؛ سيُفعّله deploy)libefivar وlibefiboot (deploy مرتبط ديناميكيًا؛ وكلاهما يأتي مع نظام التشغيل الافتراضي)ARM64 / Graviton غير مُختبَر وبالتالي غير مدعوم (حتى الآن؟).
Amazon Linux 2023 x86_64.
./install-dependencies.sh/boot/vmlinuz-$(uname -r) و/boot/initramfs-$(uname -r).img الخاصين بالنواة قيد التشغيل (تُحزَم هذه الملفات في UKI)cc، make، pkg-config، grub2-mkimage، objcopy، kexec، openssl، xxd./install-dependencies.sh هو أداة التهيئة الأولية. يثبّت حزم dnf المذكورة أعلاه (إضافةً إلى grub2-efi-x64-modules، systemd-boot-unsigned، efivar-devel، dracut) ويجلب ثنائيات busybox udhcpc وwget المثبّتة على إصدار محدد.
على مضيف البناء:
./install-dependencies.sh
make
make المجرد يكتب uki.efi وBOOTX64.EFI وdeploy. لا يكتب ESP ولا /var/lib/systemd/boot ولا NVRAM. توجد سحرية الذيل (trailer magic) وSOURCE_DATE_EPOCH في ARCHITECTURE.md.
انسخ ملف deploy ELF المُرفَق إلى الهدف. لا حاجة إلى مُصرِّف. إن uki.efi وBOOTX64.EFI موجودان بالفعل داخل الذيل.
scp deploy user@target-host:~/
على نسخة AL2023 الموجودة في نفس الموقع، تكون عملية النسخ اختيارية؛ شغّل ./deploy من شجرة البناء.
عند إعادة التشغيل التالية، تُحمّل البرامج الثابتة Boot0002 ملف ESP PE، ثم يقوم PE بتحميل UKI بشكل متسلسل، ثم تُنفَّذ الحمولة، وبعد ذلك يبدأ kexec نواة BLS الأصلية (ARCHITECTURE.md). إذا طبعت deploy الرسالة EFI variables are not supported on this system، فإن هذا الإقلاع يتم عبر BIOS؛ راجع Requirements.
يتطلب deploy صلاحيات الجذر. عند تشغيله دون وسائط، فإنه يطبع إزاحات trailer وNVRAM ولا يكتب شيئًا. تقوم -y بزرع الصور وNVRAM، ثم تمسح هذا الملف التنفيذي وتحذف رابطه. أي وسيطة أخرى تطبع رسالة الاستخدام.
./deploy # dump only: trailer offsets and NVRAM; no writes
./deploy -y # plant, then wipe and unlink this binary
reboot
عند تشغيل -y بنجاح، تقوم العملية بجدولة محو لملفها التنفيذي الخاص (/dev/urandom، ثم الاقتطاع، ثم إلغاء الربط) بعد خروجها، لذا يجب أن يفشل ls deploy. تبقى صورة UKI المزروعة وصورة GRUB الخاصة بالـ bootkit.
يكتب -y الملف /var/lib/systemd/boot/uki.efi (root:root، 0500) والملف /boot/efi/EFI/BOOT/.BOOTX64.EFI (root:root، بأفضل جهد 0700 على VFAT)، ثم ينشئ NVRAM Boot0002 ويضعه أولاً في BootOrder. يبقى BOOTX64.EFI الأصلي هو Boot0001.
make
هذا يبني المنتجات الثلاثة. لا توجد مجموعة اختبارات داخل الشجرة. تشغيل make في نفس المكان على نسخة AL2023 التي ستشغّل لاحقًا ./deploy -y ليس دليلًا على بيئة تشغيل نظيفة.
بعد إعادة التشغيل يجب أن تكون في مساحة مستخدم stage-2 الأصلية: النواة، و/proc/cmdline، ومسار initrd التي كان إقلاع BLS العادي سيستخدمها.
cat /root/HELLO.TXT
# expect: stage-1 cmdline with BOOTKIT_MARKER, 98-payload.sh banner,
# pre-OS network breadcrumbs (NIC up, DHCP/udhcpc, default route),
# wget / external_ip=... / result, then
# 99-kexec-stock: resolve=bls:..., kexec -l ok, kexec -e
grep BOOTKIT_MARKER /proc/cmdline || echo "no marker (stage-2 ok)"
# expect: no marker
dmesg | head -3
# expect: stock-style cmdline (BLS options), not BOOTKIT_MARKER=1
uname -r
# expect: the dnf/grubby default on disk