Revisiting LoJax: Supplementary Analysis and Research Notes

 

Revisiting LoJax: Supplementary Analysis and Research Notes

 

 

“To understand the immeasurable, the mind must be extraordinarily quiet, still.”
— Jiddu Krishnamurti

 

 

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher 

From 2025.12.30 to 2026.01.02

---

Prologue: Ever climbing, more clear

Last time, I shared the report “Revisiting LoJax: The First UEFI Rootkit Found in the Wild,” and here, to go further on a personal firmware study, I would like to explain it clearly to myself, focusing on the management mechanism abused as supplementary analysis, which motivation also makes me learn more knowledge. I accept “slow down,” and my aim is to earn a clearer understanding, which makes me happy —— the feeling like I saw the fish playing a game when muddy water became clear in the river, as I was a child who was full of curiosity.

 

 

Management mechanism abused by LoJax

First, let’s go back to the simplified technical summary: “On the victim machine, with the Secure Boot disabled or misconfigured, it exploited a race condition in SPI flash write protections. The SPI flash infected drops the kernel driver before the OS loads; the kernel protects the user payload, and the user payload maintains C2 and tooling.”

Here, let’s continue to dive deep into the detail of the boot process.

1.           UEFI Boot Variables While UEFI boot variables are commonly abused by firmware bootkits, LoJax persistence is instead achieved through a malicious DXE driver stored in SPI flash. ESET confirmed execution via a ReadyToBoot event callback, and did not report any modification of UEFI boot variables.

Confidence: Low — no public report confirms Boot#### or BootOrder manipulation by LoJax.

2.           SecDxe DXE driver The malicious SecDxe DXE driver drops a kernel-mode driver (autoche.exe) and a user-mode payload (rpcnetp.exe) during early OS boot.

3.           Kernel Driver (autoche.exe)  The dropped kernel-mode driver autoche.exe configures service-related registry entries for the Service Control Manager, enabling rpcnetp.exe to be launched automatically during system startup.

Figure 1: autoche.exe configures the service via the registry for SCM.

4.           SCM Service The Service Control Manager is not directly abused; instead, it legitimately launches rpcnetp.exe during the normal service startup sequence initiated by wininit.exe, based on service registry configuration prepared earlier by autoche.exe, the malicious kernel-mode driver.

5.           rpcnetp.exe It is a user-mode service payload during OS running, and it defines the service name (rpcnetp) and operates for the long-lived C2 agent. The rpcnetp.exe payload includes implementations for both 32-bit and 64-bit Windows environments.

 

According to the above analysis, from firmware to user mode, we can do a summary with layer, mechanism, and abuse as follows:

Figure 2: the mechanism abused by LoJax.

 

And the components and responsibilities are as follows:

Figure 3: the component and responsibilities by LoJax.

 

 

 

Epilogue: What This Exploration Taught Me

1.      The gradual clarification that comes with in-depth exploration makes someone joyful.

2.      Different perspectives yield different insights; observation is interesting by yourself.

Annotation: In all the sentences I wrote and used the word “you or your or yourself” in, it talked to me or “the malware sample itself, especially in my poem I did”, not the reader. I must clarify my motivation.

End of Report

──────────────────────

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher