Source: Malware Analysis Space (blog de Seeker/李标明). Contexte: notes de recherche publiées le 28 janvier 2026, centrées sur une revisite technique de MoonBounce et ses mécanismes d’inline hooking au cœur du DXE Core, en s’appuyant sur les rapports de Kaspersky et Binarly.

L’auteur rappelle que MoonBounce est un implant firmware UEFI associé à APT41 (Winnti) et se concentre sur le binaire CORE_DXE (DXE Core/Foundation). L’étude met en évidence que l’implant ne se contente pas d’un driver séparé mais patch le code exécutable du DXE Core, installant des hooks inline très précoces qui s’exécutent « sous » l’ensemble des drivers DXE.

Sur le plan technique, l’implant détourne les EFI_BOOT_SERVICES via des hooks sur AllocatePool, CreateEventEx et ExitBootServices, en pointant vers un dispatcher commun. Le hook AllocatePool restaure le prologue original puis met en place et copie une shellcode en mémoire. Le hook CreateEventEx enregistre un callback sur gEfiEventLegacyBootGuid pour activer la chaîne en mode Legacy/CSM. Pour les systèmes UEFI purs, MoonBounce implante un hook au moment d’ExitBootServices : il scanne winload.efi par signature d’instructions (ex. motif 0xCB485541), copie une shellcode en mémoire basse et hooke OslArchTransferToKernel au point exact de transition firmware→noyau.

Une fois au seuil du noyau, la shellcode résout la base de ntoskrnl.exe, résout des APIs noyau par hachage, modifie des permissions de sections, déploie une shellcode résidente et installe un hook sur ExAllocatePool pour l’exécution furtive en mode noyau. L’ensemble révèle une chaîne d’infection adaptée aux deux chemins de boot (CSM et UEFI), avec un design minimaliste mais précis, fondé sur des comparaisons d’opcodes et des hooks inline soigneusement restaurés.

L’article est une publication de recherche personnelle, limitée au CORE_DXE et à la logique de hooks, et renvoie pour les détails complets aux analyses de Kaspersky et Binarly. Il met l’accent sur la compréhension du flux interne DXE, des frontières de confiance UEFI, et la puissance d’un implant qui prend le contrôle avant le chargement des composants DXE et à la transition vers le noyau. 🔬

IOCs:

  • MD5 CORE_DXE: d94962550b90ddb3f80f62bd96bd9858
  • SHA1 CORE_DXE: 6bfb3634f6b6c5a114121fe53279331ff821ee1e
  • Chaîne recherchée (contexte d’image firmware): “E7846IMS.M30”

TTPs (extraits clés):

  • Patch du DXE Core et inline hooking des EFI_BOOT_SERVICES: AllocatePool, CreateEventEx, ExitBootServices
  • Dispatcher unique pour les hooks via comparaison d’opcodes
  • Usage de gEfiEventLegacyBootGuid (callback) pour l’activation en CSM
  • Scan par signature d’instructions dans winload.efi; hook d’OslArchTransferToKernel à ExitBootServices
  • Déploiement de shellcode noyau; résolution d’APIs par algorithme de hachage de noms
  • Modification de permissions de sections noyau; hook d’ExAllocatePool

Conclusion: article de type publication de recherche/notes techniques visant à exposer le design et le fonctionnement des hooks de MoonBounce dans le DXE Core et à la transition firmware→noyau.

🧠 TTPs et IOCs détectés

TTP

Patch du DXE Core et inline hooking des EFI_BOOT_SERVICES: AllocatePool, CreateEventEx, ExitBootServices; Dispatcher unique pour les hooks via comparaison d’opcodes; Usage de gEfiEventLegacyBootGuid (callback) pour l’activation en CSM; Scan par signature d’instructions dans winload.efi; hook d’OslArchTransferToKernel à ExitBootServices; Déploiement de shellcode noyau; résolution d’APIs par algorithme de hachage de noms; Modification de permissions de sections noyau; hook d’ExAllocatePool

IOC

MD5 CORE_DXE: d94962550b90ddb3f80f62bd96bd9858; SHA1 CORE_DXE: 6bfb3634f6b6c5a114121fe53279331ff821ee1e; Chaîne recherchée (contexte d’image firmware): “E7846IMS.M30”

🔗 Source originale : https://malwareanalysisspace.blogspot.com/2026/01/revisiting-moonbounce-research-notes.html