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