Qihoo 360's Hypervisor Driver Ships a BYOVD Kill Switch: Now in LOLDrivers

By John Rodriguez (CyberDagger LLC) and Jonathan Reiter (Titan Code Solutions, LLC).

Qihoo 360 Total Security bundles a kernel driver called 360hvm64.sys that manages the product’s hardware-virtualization-based protection engine. When loaded inside the full 360 suite, it is a legitimate component. When loaded standalone, which is what happens in a Bring Your Own Vulnerable Driver attack, a single IOCTL call disables VT-x or AMD-V across every logical processor on the machine. No authentication check stops you, because the authentication gate fails open.

We reverse-engineered this driver independently using different toolchains, arrived at the same conclusion, and contributed it to the LOLDrivers catalog. The entry merged on June 16, 2026 thanks to MHaggis and the LOLDrivers maintainer team.

This post documents the finding, the joint analysis, and the detection guidance. It also credits the cross-team work that made the contribution stronger than either side’s analysis alone.

The primitive

Driver: 360hvm64.sys v2.0.0.1207 Signer: Qihoo 360 Software Co., Ltd. (valid Authenticode) SHA256:

f89d5d95b8a59e6d5e50a49217f83d080e4eaf4bb77b80d8f38cd915640ba124

Device object: \\.\360Hvm. No explicit SDDL, so default Object Manager security gives Administrators and SYSTEM full access.

IOCTL dispatch: IRP_MJ_DEVICE_CONTROL handler at sub_123f0 exposes 10 IOCTLs, all BUFFERED.

The IOCTL that matters: 0x0022240c. It routes to sub_136cc, which performs:

1. Acquire a FastMutex
2. Set a “disabling-in-progress” flag
3. Broadcast a DPC to every logical processor, invoking VMXOFF (Intel) or VMSKINIT (AMD)
4. Clear the “HVM active” flag

After that sequence, 360’s VM-level monitoring is gone across all CPUs. Any subsequent driver load or rootkit operation is invisible to 360’s hypervisor layer.

The auth gate fails open

Every user-mode IOCTL goes through sub_121f4 first. This function delegates the access decision to \Device\360SelfProtection, a device created by a separate 360 driver, via IoBuildDeviceIoControlRequest. If 360SelfProtection says no, the IOCTL is denied.

The problem: when \Device\360SelfProtection does not exist, which is the definition of a BYOVD scenario where the attacker loads 360hvm64.sys alone without the rest of the suite, the auth function returns 1. Permitted.

The exploitation outline is four lines of sc.exe and one DeviceIoControl call:

sc.exe create 360hvm64 binPath="C:\Windows\Temp\360hvm64.sys" type=kernel
sc.exe start 360hvm64

CreateFileW("\\\\.\\360Hvm", GENERIC_READ|GENERIC_WRITE, ...);
DeviceIoControl(hDev, 0x0022240c, &dword0, 4, &out, 4, &returned, NULL);

The MITRE ATT&CK technique is T1562.001, Impair Defenses: Disable or Modify Tools.

Joint analysis: two toolchains, one conclusion

This was a joint effort between CyberDagger LLC and Titan Code Solutions, LLC. We want to be specific about what each side brought.

CyberDagger’s contribution was the initial 2026-04-14 deep analysis. Dagger Forge’s headless reverse-engineering automation identified the IOCTL dispatch, the auth-fail-open mechanism, the VMXOFF/VMSKINIT broadcast, and produced the YARA rule and LOLDrivers YAML. This is breadth via automation. The pipeline examines many binaries quickly and flags the interesting ones.

Jonathan Reiter’s contribution (Titan Code Solutions) was the 2026-04-15 cross-driver analysis that substantially broadened the picture. Working from his own analysis toolchain, Jonathan:

• Cross-validated CyberDagger’s 360hvm64 IOCTL set independently and confirmed the same dispatch entry, auth mechanism, and primary BYOVD primitive.
• Surfaced two additional IOCTLs (0x222418 and 0x222420) that the CyberDagger automated pass had not identified, with handler RVAs at 0x12aa8 and 0x4086c respectively. These were folded into the LOLDrivers YAML.
• Mapped the full cross-driver communication topology across nine 360 drivers: device objects, DOS symlinks, Filter Communication Ports (\Safe360Port, \Safe360BoxPort, \360_File_Counter_Miniport_Commport). This established which drivers depend on which, and where the same fail-open auth-proxy pattern recurs.
• Performed an independent deep on DsArk64_win10.sys, documenting its FltMgr minifilter footprint, named IOCTL handlers, and high-privilege ntoskrnl imports. DsArk64 is already on LOLDrivers via PR #308 by @weezerOSINT; Titan’s analysis adds minifilter structural detail.
• Cataloged setup.exe’s cloud touchpoints (download, update, telemetry, and DoH endpoints on *.360safe.com, *.360.cn, and doh.360.cn), directly useful for SOC allowlisting and incident-response detection.
• Authored the detection guidance section: Sysmon EID 6 driver-load signatures, ETW kernel callbacks, minifilter port monitoring via FilterConnectCommunicationPort, and network indicators for distinguishing full-suite install from standalone driver load.
• Identified two follow-up BYOVD candidates: 360Box64.sys (same fail-open auth-proxy pattern via \Safe360BoxPort) and 360AntiSteal64.sys (partial gate with conditional fail-open). Both are under continued analysis for separate LOLDrivers submissions.

The two methodologies are intentionally orthogonal. CyberDagger’s headless pipeline produces breadth. Titan’s GUI workflow with MCP-assisted analysis produces depth. The joint output is more durable than either side alone. In this case, Titan’s cross-driver context transformed what would have been a single-driver submission into a documented attack-surface map of the full 360 kernel stack.

The LOLDrivers PR journey

For posterity, because open-source contribution timelines are part of the record:

• PR #342, initial submission, withdrawn 2026-05-07 due to YAML formatting issues.
• PR #349, corrected submission, opened 2026-05-20 under the cyb3rh0und GitHub account. Joint credit in the YAML: CyberDagger LLC and Titan Code Solutions, LLC.
• Bump on 2026-06-09 got a heart reaction from MHaggis, who confirmed the SHA256 match and thanked us for the contribution.
• PR #365, MHaggis opened this PR to handle the LFS binary upload on the maintainer side, incorporating our YAML and metadata. Merged 2026-06-16.

The entry is now live in the LOLDrivers catalog.

Detection

YARA

rule loldrivers_360hvm64 {
    meta:
        author      = "CyberDagger LLC + Titan Code Solutions, LLC"
        description = "Qihoo 360 hypervisor enforcement driver - IOCTL 0x22240c disables VT-x/AMD-V; auth fails open in BYOVD"
        MitreID     = "T1562.001"
        SHA256      = "f89d5d95b8a59e6d5e50a49217f83d080e4eaf4bb77b80d8f38cd915640ba124"
    strings:
        $dev1  = "\\Device\\360Hvm" wide
        $dev2  = "\\DosDevices\\360Hvm" wide
        $dev3  = "\\Device\\360SelfProtection" wide
        $dat   = "360HVM64.DAT" wide
        $ioctl = { 0c 24 22 00 }
    condition:
        uint16(0) == 0x5A4D and (all of ($dev*) or ($ioctl and $dat))
}

Behavioral indicators

• Driver load without full suite: Sysmon EID 6 or EDR driver-load event for 360hvm64.sys without corresponding loads for 360FsFlt.sys, 360SelfProtection.sys, and the other suite drivers. A standalone load is the BYOVD signal.
• Device object creation: \Device\360Hvm appearing without \Device\360SelfProtection. The latter’s absence is what makes the auth gate fail open.
• IOCTL 0x22240c issued: ETW or kernel callback instrumentation catching DeviceIoControl to \Device\360Hvm with this code.
• Network absence: A real 360 installation phones home to down.360safe.com, update.360safe.com, and s.360.cn. A BYOVD load will not generate this traffic. Its absence alongside a 360hvm64.sys load is a negative indicator worth correlating.

WDAC / driver blocklist

Organizations that do not run Qihoo 360 Total Security can blocklist 360hvm64.sys by hash or by Authenticode signer. Organizations that do run it should evaluate whether the standalone-load risk warrants moving the driver behind HVCI enforcement.

What’s next

Two follow-up BYOVD candidates from the same driver suite are under continued analysis:

1. 360Box64.sys, sandbox minifilter that communicates via \Safe360BoxPort. Same fail-open auth-proxy pattern as 360hvm64.sys. IOCTL surface deep is in progress; a separate LOLDrivers PR is planned once complete.
2. 360AntiSteal64.sys, file-counter minifilter on \360_File_Counter_Miniport_Commport. The gate checks SeTokenIsAdmin and proxies to 360SelfProtection. It is conditionally fail-open when the SP device is absent but only reachable by admin callers. Lower priority, but worth documenting.

Detection rules (dedicated YARA and Sigma for the full 360 driver set, beyond the single 360hvm64 rule above) are planned for the detections/ directory in the LOLDrivers repo.

Acknowledgments

Jonathan Reiter, CEO, Titan Code Solutions, LLC (@reiterjr). Jonathan’s cross-driver analysis and detection guidance are co-equal contributions to this work. The LOLDrivers YAML carries joint credit, and so does this post. His custom analysis tooling turned what would have been a per-driver exercise into a systematic inventory of the full 360 kernel stack.

MHaggis and the LOLDrivers maintainer team for reviewing the submission, running their validation pipeline, and handling the LFS binary upload.

CyberDagger LLC publishes coordinated disclosure under the policy at cyberdagger.com/responsible-disclosure. The LOLDrivers entry for 360hvm64.sys is live at loldrivers.io. Technical questions: contact us.