Revisiting SubVirt & Blue Pill: From Attacker Proof-of-Concepts to Defensive Foundations

 

Revisiting SubVirt & Blue Pill: From Attacker Proof-of-Concepts to Defensive Foundations

How early VM-based rootkit research shaped the architecture of modern system defense

 

 

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

 

 

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher 

From 2025.10.22 to 2025.10.29

---

Prologue: Non-VM-Based and VM-Based Rootkits

Last time, on 2025.10.14, I published a report about “Regin Static Analysis of Its Lightweight VFS Abstraction Layer” and other rootkit reports the day before, they were old classic or legacy rootkits.

 

The legacy rootkits were extremely popular; this era is considered to be the golden age of rootkits. For personal record of study, I might define the golden age as something like “Approximately 2005 to 2014 (±1 year).”

 

So I was very curious about the rootkit’s revolution and what’s happening from 2015 to 2025. I keep seeking and noted both SubVert and Blue Pill, which are modern rootkits called virtual machine-based (VM-based) rootkits. They are surprising me. So here I would like to share my study and personal view.

 

Before beginning, here let’s call the classic or legacy rootkits as non-VM-based. So it is a little bit clear and an intuitive way to categorize them for my study or personal perspective. Now, there are two types of rootkits: non-VM-based and VM-based rootkits.

 

 

Non-VM-Based Rootkit

About this type of rootkit, as we know, they operate within or on top of the OS, without using a hypervisor. Typical targets are like kernel structures, device drivers, MBR or boot sectors, which they do with techniques SSDT hooking, DKOM, file hiding, process hiding, and rootkit loaders in kernel space.

 

Yes, they run in kernel space. Classic rootkits operate in kernel space alongside the OS kernel, sharing the same privilege level and trust boundary. That co‑location is a fundamental design flaw and risk: it makes the kernel a single point of failure, enabling rootkits to fully subvert the OS, hide from in‑guest defenses, and maintain persistent control.

 

Classic or legacy rootkits, non-VM-based rootkits, mainly need deep OS and kernel knowledge; they don’t normally require microarchitecture expertise or hypervisor-level CPU internals.

 

 

VM-Based Rootkit

About this new type of rootkit, like SubVirt and Blue Pill, they operate beneath the OS, using virtualization as a stealth layer, installing a thin or mini hypervisor to control the guest OS, intercepting OS operations from “underneath.”

 

Here, let’s go back to history to have a simple summary about SubVirt and Blue Pill. First to talk about SubVirt and then Blue Pill.

 

SubVirt: Implementing malware with virtual machines

Figure 1: from the original SubVirt report.

 

This new type of malware, called a virtual-machine-based rootkit (VMBR), inserts a minimal host operating system and VMM into the boot process. SubVirt alters the boot chain and forces the original operating system to run as a guest, fully controlled from the underlying hypervisor layer.

 

 

Blue Pill idea

Figure 2: from the original BH-US-06-Rutkowska report.

 

The Blue Pill proof-of-concept demonstrated a different threat vector from SubVirt: rather than re-platforming the boot sequence, Blue Pill showed that it leverages CPU virtualization extensions to start a mini hypervisor that could be launched beneath a running OS, migrating the OS into a guest instead of modifying the boot chain. It is very powerful because it shifts trust below the kernel without obvious boot artifacts.

 

 

The Challenge of Creating a VM-Based Rootkit

However, the implementations in SubVirt and Blue Pill highlight that compromising the system at the hypervisor layer requires a high degree of sophistication and is extremely hard to achieve in practice, because they must master them very well, at least as follows:

1.      Deep CPU or microarchitecture expertise and ability handle CPU virtualization (VMX/SVM).

2.      One must implement a mini host OS and VMM.

3.      Complex memory & device virtualization.

 

Just the above knowledge and techniques to master are very difficult for most people to create that type of VM-based rootkit. In my personal view, it’s not an average APT, but a nation-state-level APT can do it. And to defenders, they also have to raise themselves to the same or higher level.

 

 

VM-Based Rootkit Ideas Finally Become Defense Policy

In 2006, they were both modern proof-of-concept hypervisor rootkits, Today, the ideas behind VM-based rootkits are no longer just theoretical. Modern systems use virtualization to protect critical code, isolate sensitive data, and monitor for malware, after all for defense. Here are just some real-world applications:

1.      Cloud Security – isolate sensitive workloads in protected mini-VMs.

2.      Application Isolation – Qubes OS.

3.      Operating System Protection – protect kernel code and credentials.

 

Yeah, today the idea and perspective are implemented as the main defense policy and trend, with deep implications for modern OS (Windows & Linux): as OS vendors and security products incorporate virtualization-based security (VBS, HVCI, and VM introspection).

 

In order to further understand what the core change inside is, I think it is important. Let’s extend to explain them simply as follows:

1.      VBS (Virtualization-Based Security): It creates a mini-OS via hypervisor. The purpose is to isolate critical Windows processes & secrets.

2.      HVCI (Hypervisor-Protected Code Integrity): It is a part of VBS and blocks unsigned drivers; the purpose is to enforce kernel code integrity.

3.      VM Introspection (VMI): It is used for stealth malware detection; the purpose is to monitor the VM from outside.

Figure 3: Modern Virtualization-Based Security Stack.

After all, VBS, HVCI, and VM introspection are different mechanisms that leverage virtualization to build a foundation for modern system security.

In other words, a classic rootkit is a big challenge to live and persist in in this type of environment.

 

 

Conclusion

The VM-based rootkit idea, like SubVirt and Blue Pill, came from a completely new structure design mindset in modern system defense, which makes defensive policy a very high-level evolution in the modern cybersecurity field; it highlights progress on the defensive side and being positive.

 

And until now, we haven’t seen publicly confirmed, widely deployed VM-based rootkits in the wild that match the scale or stealth claims of the early proof-of-concept like SubVirt or Blue Pill.

 

While VM-based rootkits are extremely rare, the attacker mindset they introduced has already materialized in the wild through UEFI firmware bootkits like LoJax (2018), ESPecter (2021), and MoonBounce (2022), The dates above represent approximate timelines, which provide similar stealth advantages by operating beneath the operating system. These look like a practical evolution as the attacker’s perspective.

 

Revisited the SubVirt and Blue Pill and the evolution. Nowadays, a new battle is taking place between attackers and defenders of modern computer systems, and they go forward with mutual promotion, truly incredible!

 

Epilogue: What the SubVirt and Blue Pill Taught Me

1.  The type of VMBRs like SubVirt and Blue Pill taught me too much to learn.

2.  The security field is an area that requires active response. Due to its inherent adversarial nature, learning and practice are continuous.

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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

References

[1]. https[:]//www.microsoft.com/en-us/research/wp-content/uploads/2016/02/subvirt.pdf?msockid=3358b4e5e04c69682295a69be12a689f

[2]. https[:]//theinvisiblethings.blogspot.com/2006/06/introducing-blue-pill.html
[3]. https[:]//en.wikipedia.org/wiki/Blue_Pill_%28software%29

[4]. https[:]//blackhat.com/presentations/bh-usa-06/BH-US-06-Rutkowska.pdf

 

 

 

“Do or do not, there is no try.”
— Master Yoda

 

 

End of Report

 

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher

Regin: Static Analysis of Its Lightweight VFS Abstraction Layer

 

Regin: Static Analysis of Its Lightweight VFS Abstraction Layer

Polymorphic Kernel Interfaces and I/O Abstraction Layer

 

 

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

 

 

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher 

From 2025.9.24 to 2025.10.14

---

Prologue: The Temple and the Kernel

Recently, I still climbed a mountain and visited the temple again, but only a few times; sometimes, I go hiking in the forests. Here, I keep moving on malware research. I notice that quite sophisticated malware Regin, between 2014 and 2015, Symantec and Kaspersky published their report of analysis.

 

According to a Symantec report, “Regin is a multi-staged, modular threat, meaning that it has a number of components, each depending on others, to perform attack operations.”

 

In this report, I would like to do and share limited analysis without getting all components. I was very curious and interested in the VFS design uncovered by the Symantec and Kaspersky report; it needs “stage 2” to run “stage 3,” so personally I just tended to do simple static analysis about the driver named VMEM.sys, which is on stage 3. Table 2 is shown as follows.

Figure 1: Table 2 from Symantec’s report.

 

The following limited analysis about “Virtual file system (VFS) access manager” was done in my own way.

 

Sample choice: Regin

NAME: Stage 3 is internally known as VMEM.sys

MD5: 8486ec3112e322f9f468bdea3005d7b5

 

 

 

Static analysis

---

 

The Concept of VFS

I think we need to know what’s VFS first before staring static analysis. When we say VFS (Virtual File System) in the context of drivers or operating systems, we’re not talking about a “virtual machine file type” like a .vmdk or .vdi.

Instead:

·        VFS = Virtual File System
It’s an abstraction layer that lets software access different storage backends (real disk, network share, encrypted container, memory region, etc.) using the same file API.

 

 

 

Kernel Interface-Based Polymorphism Design

I did a string search and followed the value of Unit(hex), which is 006bh, and finally went to the main function sub_2E40A and then dove deep into the sub-branch sub_2F7C6 and found a series of similar calls that do:

 

push offset sub_2EBB4

push 0x12

push eax

call dword ptr [ecx+24h]

 

Dispatcher pattern:
• Different handlers (sub_xxx) pushed but same [ecx+24h] call → polymorphic dispatch.
• Immediate (0x12) is likely a flag controlling logic flow or acting as a mode selector.

Figure 2: Polymorphic interface dispatch design.

 

 

 

 

 

And from the above pattern of design, it’s very convenient to do functionality extension because of its scalability. It treats the design seriously as professional software engineering architecture thinking and practice, which is a long-term maintenance and mature mindset.

 

 

Polymorphic Dispatch Issue Direct Kernel I/O Calls

When diving deep into polymorphic dispatch, different handlers are supplied to the same dispatcher, like the pattern “push offset sub_xxx”; they issue direct kernel I/O calls under the safety kernel environment, for which they did security initialization and releasing with synchronization logic. Here are several different handlers to pick to demonstrate.

 

1.      About “push offset sub_2EDCC”

kr_sec_init (After Function Rename):

It executes the kernel security initialization operation API (KeGetCurrentIrql, KeEnterCriticalRegion, ExAcquireFastMutexUnsafe, KfAcquireSpinLock, and ExAcquireFastMutex).

 

And in the middle part, the logic branch operation handles routines and issues direct kernel I/O calls (ZwQueryInformationFile, ZwWriteFile).

 

kr_sec_clean (After Function Rename):

And finally, it is to release them that are related to API (ExReleaseFastMutexUnsafe,

KeLeaveCriticalRegion, KfReleaseSpinLock, and ExReleaseFastMutex).

Figure 3: push offset sub_2EDCC logic issue direct kernel I/O calls.

 

 

 

In addition, it uses the standard software CRC32 algorithm implementation for integrity checks, a valid precomputed CRC with reversed polynomial 0xEDB88320 in the lookup table.

Figure 4: snippet for 256 precomputed uint32 values, including the polynomial 0xEDB88320.

 

 

2.       About “push offset sub_2EBB4”

The structure design is very similar to “push offset sub_2EDCC,” which includes a wrapper for “ZwWriteFile” and the part of function sub_2FD2C.

 

3.      About “push offset sub_2F32A”:

The structure has more sub-branches in the logic design. When diving deep into the function sub_30386, the logic branch operation handles routines that issue direct kernel I/O calls (ZwQueryInformationFile, ZwWriteFile, ZwReadFile, ZwClose). Wait on an event or op completion (ZwWaitForSingleObject) before proceeding.

 

Yes, in the function sub_2F7C6, most of the functionality is designed around I/O calls to bridge virtual objects to real files or queries or operate on real file objects, which is polymorphism design with the same interface and different implementations.

 

 

well-designed Kernel Synchronization Wrapper 

In the function sub_2EDCC, kr_acquire_lock and kr_release_unlock perform IRQL-aware lock/unlock routines, including the different lock types: FastMutex Unsafe, SpinLock, and FastMutex. The design is a kernel synchronization security layer, which, combined with file operation, the concurrency control indicates the feature about typical VFS-layer or filesystem object access.

Figure 5：kernel synchronization wrapper with IRQL checks.

 

Figure 6：perform IRQL lock/unlock routines.

 

The implementation's use of IRQL-aware wrappers for local resource protection, in contrast to the complex multi-layer locking architecture required for managing global Index Node, Directory Entry, and superblock caches in a standard VFS, definitively characterizes it as a Light VFS-layer implementation.

According to Kernel Theory Knowledge, Synchronization Expertise, and Security Awareness, this synchronization wrapper indicates a highly sophisticated threat actor with professional kernel development experience.

 

 

Conclusion

Together, these behaviors indicate that the function sub_2F7C6 implements a custom VFS (virtual filesystem) structure, using polymorphic method tables to abstract file access. an abstraction layer that routes all file-like operations (read, write, query, close) through a consistent interface, guarded by a well-designed synchronization security layer, and the code uses IRQL-aware wrappers for local protection. The evidence indicates that it is a Lightweight VFS layer or VFS access manager.

 

 

Epilogue: What the Regin Taught Me

1.      If you want to analyze Regin-class implants, you must reach a high level of Windows kernel competence. its authors deliberately used advanced kernel primitives (VFS-like storage, IRQL-aware locking, Zw* bridging, stealthy persistence).

2.      Malware that is designed with multiple stages and interdependent components makes analysis more challenging and is very difficult to understand completely without all related samples.

3.      Simply being curious and exploring gives people positive abilities to expand on malware research or other fields.

4.     Being humble is not just about recognizing how little you know but also about facing complexity and understanding it takes time and patience.

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.

 

 

 

 

 

References

[1]. https[:]//docs.broadcom.com/doc/regin-top-tier-espionage-tool-15-en

[2]. https[:]//media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/03/08070305/
Kaspersky_Lab_whitepaper_Regin_platform_eng.pdf

“Do or do not, there is no try.”
— Master Yoda

 

 

 

 

End of Report

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

Seeker(李标明) · @clibm079    

China · Independent Malware Analyst & Researcher

Design Intent Exposed: Path Deception in nls_933w.dll

 

Design Intent Exposed: Path Deception in nls_933w.dll
How Equation Group Protects the Embedded Driver Resource from Being Released to Physical Disk Automatically—A Stealth Loading Tactic

 

 

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

 

Seeker(李标明) ·@clibm079    

China · Independent Malware Analyst & Researcher 

From 2025.9.7 to 2025.9.16

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Prologue

 

Recently, I didn’t go to the temple frequently but sometimes walked in the park and watched the trees and flowers and felt the air flowing, which, by the way, let me get close to nature to clear my mind.

Figure 1: One day in the mountains.

The last report, “Analysis of Equation Group’s nls_933w.dll Revealing Core Tactics and Technical Mindset,” took me more than 60 days—too much time and energy, so I had to stop and have a rest and make a balance between life and research work, and then I wrote an article called “Safeguarding the Self” and shared real feelings on the “Poems of Malware Analysis,” and the other thing was to improve my homepage and the repository of GitHub, something like that to release the pressure of research.

In this report, I will narrow the scope of my research and focus on one strategic point. I would like to dive deep into the invalid path tactic, guess and verify, and how the equation group did it like that. I will try to change the invalid path to the valid path for the experiment and check the logic and confirm my personal guess. Here we go.

---

Sample choice: nsl_933w.dll

Yeah, it’s still the nation-state group APT called Equation group.

nls_933w.dll 

md5: 11fb08b9126cdb4668b3f5135cf7a6c5

WIN32M.sys

md5: 2b444ac5209a8b4140dd6b747a996653

 

Technical analysis

 

The invalid path deception tactic

Here, let’s jump to the core title “the invalid path,” directly related to the last report. It uses GetSystemDirectoryA to locate the correct directory “c:\windows\system32” but concatenates the invalid strings. Both the constant “Source” and the “Str” design from the .data segment don’t even plan to decode.

Figure 2: invalid path from concatenating the constant “Source” and the “Str”.

In fact, it was the first time that I had generated an idea of what would happen if they were valid paths, but I just paused not to make them more complex. And weeks passed and the heavy pressure was released, so I think it’s time to verify the guess.

Guess and experimental testing

The first thing to do is change the value of memory directly and then debug with a single step forward.

Figure 3: Change the value of memory to a valid path.

 

I debugged step by step, and it returned the value of EAX as 1.

Figure 4: the process of debugging.

 

The driver WIN32M.sys was successfully released to disk

And then the embedded driver WIN32M.sys in nls_933w.dll was released to the physical disk. The size of the file and the hash of the file are right.

Figure 5: the embedded driver WIN32M.sys in nsl_933w.dll released to the physical disk.

 

Manually modify the nls_933w.dll file, check the logic, and confirm

So from there I thought I should change both constant values in nsl_933w.dll. Yeah, as mentioned above, as follows.

Figure 6: the constant about Source and Str.

 

I tried several times to make it work well, an example as follows.

Figure 7: edited the hex value with HxD Hex Editor and saved it.

 

And the condition of memory was as follows: finally, it successfully released the embedded driver WIN32.sys in nls_933w.dll to physical disk again, like the above Figure-4 shown.

Figure 8: the condition of memory after changing both constants.

 

The path constants changed ≠ driver released

Does it work well after changing path constants and releasing the embedded driver WIN32M.sys in nls_933w.dll to the physical disk automatically?

 

To be honest, “no!” I had to change the logic of the control flow to debug. It should be loaded manually the right way, which is key, but until now I haven’t understood it completely. It is the deception path; it is a smart policy to evade automatic driver file release to disk. In order to implant the malware and run correctly, it needs to know how to load, which is the real intent of the designer. Here there are two things we need to know.

1.      Change the path constant value.

2.      Loading it the right way manually.

 

So from the above analysis and observation, we know equation group design with two layers or multiple layers protects their critical weapon from being loaded.

 

 

Conclusion

In my opinion, the invalid path design is a deception and protection policy to avoid loading automatically to a physical disk; it is a smart and ingenious way to evade anti-analysis and anti-virus. They protect their critical weapon for both sides; one side is anti-analyst, and the other side is anti-machine. The intent implies that the equation group design is very strict and requires a mature mindset and practice. It’s also a serious systematic engineering design.

 

Honestly, I’m documenting what I see—knowing the unseen is vast.
Analysis WIP: still piecing together the full picture.

 

 

Epilogue: What the Firmware Research Taught Me

1.      The background of the elite state-level APT implies they have the best resources, like the top software designer, the best developer, and the elite reverse expert, and so on, to face an adversary like that; too much challenge happens naturally in front of us as analysts or researchers.

2.      In fact, in my opinion, they are not fighting against commercial products but rather taking paths beyond the market's imagination, thereby delaying the possibility of being discovered. In a word, far ahead.

3.      Respect your opponents, maintain curiosity, and continue to explore and practice. In my opinion, profound and systematic theories are equally important, not just emphasizing practical capabilities, especially in the face of the top elite state-level APT, "Only depth reveals intent."

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.

---

“Do or do not, there is no try.”
— Master Yoda

 

End of Report

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

Seeker(李标明) ·@clibm079    

China · Independent Malware Analyst & Researcher