T1062

Hypervisor

Persistence Last updated:

Adversaries may install a type-1 hypervisor below the operating system to achieve persistent, stealthy access that survives reboots and is hidden from the guest OS. A malicious hypervisor intercepts hardware-level operations and can conceal its presence from all software running above it, including security tools and the OS kernel. This technique has been deprecated by MITRE ATT&CK but remains relevant for detection engineering due to its theoretical use by sophisticated threat actors and nation-state groups targeting high-value environments. Practical implementations include Blue Pill-style subvirt attacks, malicious Xen-based hypervisors, or abuse of legitimate hypervisor platforms (Hyper-V, VMware) as persistence anchors. Detection relies on pre-installation indicators (hypervisor binary drops, boot configuration changes, driver installs) since post-installation detection from inside the guest OS is unreliable.

What is T1062 Hypervisor?

Hypervisor (T1062) maps to the Persistence tactic — the adversary is trying to maintain their foothold in MITRE ATT&CK.

This page provides production-ready detection logic for Hypervisor, covering the data sources and telemetry it touches: Process: Process Creation, File: File Creation, Windows Registry: Registry Key Modification, Driver: Driver Load, Microsoft Defender for Endpoint. The queries below are rated critical severity at low confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Persistence
Canonical reference
https://attack.mitre.org/techniques/T1062/
Microsoft Sentinel / Defender
kusto 
let HypervisorTools = dynamic([
  "xen", "bluePill", "vmmkit", "subvirt", "bluepill",
  "hvloader", "hypervisor", "vmm.exe", "hv.exe"
]);
let SuspiciousBcdeditArgs = dynamic([
  "hypervisorlaunchtype", "hypervisordebugtype", "hypervisordebugport",
  "hypervisorbaudrate", "hypervisorloadoptions", "hypervisorschedulertype",
  "testsigning on", "nointegritychecks on", "loadoptions hypervisor"
]);
let SuspiciousDriverNames = dynamic([
  "xen.sys", "xenbus.sys", "xennet.sys", "xenvbd.sys", "xenvif.sys",
  "hvax64.exe", "hvix64.exe", "hvloader.exe", "winhvr.sys", "hvload"
]);
// Branch 1: Suspicious bcdedit invocations modifying hypervisor boot settings
let BcdeditHypervisor = DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "bcdedit.exe"
| where ProcessCommandLine has_any (SuspiciousBcdeditArgs)
| extend DetectionBranch = "BcdeditHypervisorConfig"
| extend RiskIndicator = "Boot configuration modified for hypervisor loading";
// Branch 2: Suspicious driver files associated with hypervisors dropped to disk
let HypervisorDriverDrop = DeviceFileEvents
| where Timestamp > ago(24h)
| where ActionType in ("FileCreated", "FileModified")
| where FolderPath has_any ("\\System32\\drivers\\", "\\SysWOW64\\drivers\\", "\\EFI\\", "\\Boot\\")
| where FileName has_any (SuspiciousDriverNames)
| extend DetectionBranch = "HypervisorDriverDrop"
| extend RiskIndicator = "Hypervisor-associated driver written to system directory";
// Branch 3: Service creation installing hypervisor-related drivers
let HypervisorServiceInstall = DeviceRegistryEvents
| where Timestamp > ago(24h)
| where ActionType in ("RegistryKeyCreated", "RegistryValueSet")
| where RegistryKey has @"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services"
| where RegistryValueData has_any (SuspiciousDriverNames) or RegistryKey has_any (HypervisorTools)
| extend DetectionBranch = "HypervisorServiceInstall"
| extend RiskIndicator = "Registry service entry created for potential hypervisor driver";
// Branch 4: Process creating or accessing EFI/boot sector files (pre-install staging)
let BootSectorAccess = DeviceFileEvents
| where Timestamp > ago(24h)
| where FolderPath has_any ("\\EFI\\Microsoft\\Boot\\", "\\EFI\\Boot\\", "\\Boot\\BCD", "\\bootmgfw.efi", "\\bootmgr")
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where not (InitiatingProcessFileName has_any ("TrustedInstaller.exe", "wuauclt.exe", "svchost.exe", "MoUsoCoreWorker.exe"))
| extend DetectionBranch = "BootSectorModification"
| extend RiskIndicator = "EFI or boot file modified by non-trusted process";
union BcdeditHypervisor, HypervisorDriverDrop, HypervisorServiceInstall, BootSectorAccess
| project Timestamp, DeviceName, AccountName,
         FileName, ProcessCommandLine, FolderPath, RegistryKey, RegistryValueData,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         DetectionBranch, RiskIndicator
| sort by Timestamp desc

Detects indicators of malicious hypervisor installation or boot-level persistence across four detection branches: (1) bcdedit commands modifying hypervisor launch settings such as enabling test signing or setting hypervisorlaunchtype, (2) known hypervisor driver files dropped to system driver directories or EFI partition paths, (3) registry service entries created for hypervisor-associated binaries, and (4) unauthorized modification of EFI boot files by non-trusted system processes. Since detection from within a guest OS after a type-1 hypervisor installs is unreliable, this detection focuses on pre-installation and installation-time artifacts available in Defender for Endpoint telemetry.

critical severity low confidence

Data Sources

Process: Process Creation File: File Creation Windows Registry: Registry Key Modification Driver: Driver Load Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents DeviceFileEvents DeviceRegistryEvents

False Positives

  • Legitimate Hyper-V or Windows Hypervisor Platform enablement via Windows Features — generates bcdedit hypervisorlaunchtype changes during install
  • VMware Workstation or VirtualBox installation on developer machines that install kernel-mode drivers to system directories
  • Windows Subsystem for Android or WSL2 enabling Hyper-V hypervisor support via bcdedit commands during feature activation
  • Enterprise virtualization products (Citrix, Parallels, Nutanix AHV agents) installing Xen-compatible PV drivers to System32\drivers
  • Windows Update or Windows Recovery Environment modifying EFI and BCD files during cumulative update installation

Sigma rule & cross-platform mapping

The detection logic for Hypervisor (T1062) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1062 Sigma rules on detection.fyi

Platform-specific guides for T1062

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-16 Research depth: deep
References (10)

Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Enable Hyper-V Hypervisor via bcdedit (Boot Configuration Change)

    Expected signal: Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine containing '/set hypervisorlaunchtype auto'. Security Event ID 4688 (if command line auditing enabled). Parent process will be the test runner (cmd.exe or PowerShell).

  2. Test 2Disable Driver Signature Enforcement via bcdedit (Prerequisite for Unsigned Hypervisor)

    Expected signal: Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine='bcdedit /set nointegritychecks on'. Security Event ID 4688 with same command. Microsoft-Windows-CodeIntegrity/Operational may log subsequent policy change at next boot.

  3. Test 3Create Fake Hypervisor Driver Service Registry Entry

    Expected signal: Security Event ID 7045 (Service Control Manager: new service installed) with ServiceName=ArgusTestHV, ServiceType=kernel driver, StartType=boot start, ServiceFileName=C:\Windows\System32\drivers\argus_hv_test.sys. Sysmon Event ID 13 (Registry value set) for HKLM\SYSTEM\CurrentControlSet\Services\ArgusTestHV entries including ImagePath, Start (value 0 = boot), and Type.

  4. Test 4Drop Suspicious Driver File to System32\drivers (Staging Simulation)

    Expected signal: Sysmon Event ID 11 (File Create) with TargetFilename=C:\Windows\System32\drivers\xentest.sys and Image=cmd.exe or powershell.exe. The file will be created but is a renamed benign executable — SHA256 will match notepad.exe.

  5. Test 5Enable Test Signing Mode (Unsigned Driver Loading Prerequisite)

    Expected signal: Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine='bcdedit /set testsigning on'. Security Event ID 4688 with same content. Windows boot splash screen will show 'Test Mode' watermark after next reboot. Microsoft-Windows-CodeIntegrity/Operational logs policy change.

Response Playbook

Triage

  1. Identify the exact command or binary that triggered the alert — for bcdedit alerts, decode the full argument string and determine which hypervisor setting is being changed (e.g., hypervisorlaunchtype auto enables Hyper-V; nointegritychecks on disables driver signature enforcement)
  2. Check whether Hyper-V, WSL2, Windows Sandbox, or Windows Subsystem for Android is legitimately installed on the host — run: `Get-WindowsOptionalFeature -Online | Where State -eq Enabled | Select FeatureName` and verify against approved software baseline
  3. For driver drop alerts, compute the SHA256 of the dropped file and check against VirusTotal, internal threat intel, and your organization's known-good driver inventory: `Get-FileHash -Algorithm SHA256 -Path <driver_path>`
  4. For bcdedit alerts spawned from unexpected parent processes (e.g., Office, browser, script interpreter, non-admin shell), treat as critical — legitimate hypervisor configuration does not originate from user-mode applications
  5. Check the signing status of any suspicious driver: `Get-AuthenticodeSignature -FilePath <driver_path>` — unsigned or self-signed drivers on a production host are high-confidence indicators of malicious activity
  6. Review the full process tree of the initiating process — pivot from the alert's InitiatingProcessCommandLine back through parent processes to identify the original execution source (e.g., phishing attachment, exploit, remote script)
  7. Check recent boot configuration changes: `bcdedit /enum all` and compare against a known-good baseline stored at onboarding time; look specifically for added hypervisorlaunchtype, testsigning, or nointegritychecks entries
  8. Query UEFI Secure Boot status and recent EFI variable modifications: `Confirm-SecureBootUEFI` and review System Event Log for Event ID 1796 (Secure Boot policy change)

Containment

  1. If unsigned or malicious hypervisor driver is confirmed: immediately isolate the host from the network using EDR isolation — do NOT simply reboot, as a type-1 hypervisor may survive and persist across reboots at the firmware level
  2. Preserve the host in its current state before any remediation — capture a full memory image and disk image for forensic analysis: hypervisor-level artifacts may not survive OS-level tools
  3. If boot configuration was modified: revert bcdedit changes from a trusted recovery environment (WinPE), not from within the potentially compromised OS: `bcdedit /set hypervisorlaunchtype off` and `bcdedit /set nointegritychecks off`
  4. Block the SHA256 hash of any identified malicious hypervisor binary across your EDR and file integrity monitoring platforms
  5. If compromise is confirmed, do NOT trust the running OS for forensics — any process listing, file enumeration, or network connection data visible from within the guest OS may be falsified by a functioning hypervisor
  6. Escalate to firmware/hardware team for UEFI inspection — a persistent hypervisor may have modified EFI variables or implanted a malicious EFI application that re-installs across OS reinstalls
  7. For domain-joined systems: immediately rotate Kerberos service account credentials (krbtgt twice) and review for lateral movement — a host under hypervisor control may have had its memory read to extract credentials

Evidence Collection

  1. Boot Configuration Data (BCD): `bcdedit /enum all > bcd_dump.txt` — document all boot entries and their hypervisor-related settings before any remediation
  2. Driver inventory: `driverquery /v /fo csv > drivers.csv` — full list of installed drivers with paths, versions, and signature status
  3. Sysmon Event ID 6 (Driver Load): query for all driver load events in the timeframe around the alert — reveals the exact moment a hypervisor driver was loaded into kernel space
  4. Security Event ID 7045 (New Service Installed): correlate with the alert timeframe to identify when the hypervisor service was registered
  5. Windows Event Log — Microsoft-Windows-Hyper-V-Worker/Admin and Microsoft-Windows-Hyper-V-Hypervisor channels: check for unexpected VM creation or hypervisor state changes
  6. UEFI/EFI partition contents: mount EFI partition (`mountvol X: /s`) and enumerate files — look for unexpected EFI applications outside of Microsoft and vendor-signed entries
  7. Physical memory acquisition: use WinPmem or similar trusted tool from external media to capture full RAM — hypervisor code and configuration may exist only in memory
  8. Prefetch files: `C:\Windows\Prefetch\BCDEDIT.EXE-*.pf` — timestamps indicate when bcdedit was last run, revealing configuration change timing
  9. CPUID hypervisor leaf output: a type-1 hypervisor present below Windows will set CPUID leaf 0x40000000 with a vendor string — capture this from a trusted bootable OS for comparison

Escalation Criteria

  • ! Any confirmed unsigned or self-signed driver matching known hypervisor binary names loaded on a production or high-value host
  • ! bcdedit changes to hypervisorlaunchtype, nointegritychecks, or testsigning initiated by a non-administrative or unexpected parent process (script interpreter, browser, Office application)
  • ! CPUID query from a trusted external OS returns an unexpected hypervisor vendor string indicating a foreign hypervisor is running below Windows
  • ! Modifications to EFI partition files or EFI variables by non-Microsoft, non-OEM signed processes — indicates potential UEFI-level persistence
  • ! Detection occurs on a system holding highly privileged credentials (domain controller, PKI server, secrets management host, HSM-adjacent system) — hypervisor persistence on these targets is critical-severity regardless of confidence level
  • ! Multiple hosts in the same subnet or OU showing the same hypervisor driver drop or bcdedit modification within a short time window — indicates automated lateral spread

Investigation Guide

Forensic Artifacts

  • > Registry: HKLM\BCD00000000 — Boot Configuration Database as a registry hive; mount offline for analysis of hypervisor boot entries
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services — service entries for any hypervisor-related drivers including ImagePath and Start type (0=Boot, 1=System, both predate OS init)
  • > File System: C:\Windows\System32\drivers\*.sys — newly created or modified driver files; compare timestamps against Windows Update history
  • > File System: EFI partition (typically 100-260MB FAT32 volume) — EFI\Microsoft\Boot\BCD is the active boot config; EFI\Boot\bootx64.efi is the default boot loader; unexpected files here indicate implantation
  • > Event Log: Microsoft-Windows-Kernel-PnP/Configuration — Device installation events including driver loads at boot time
  • > Event Log: Microsoft-Windows-CodeIntegrity/Operational — Event ID 3001 (unsigned driver blocked), 3004 (image not authorized), 3023 (boot critical driver load) — absence of block events for a known-bad driver confirms Secure Boot or HVCI was disabled
  • > Event Log: System — Event ID 7045 (Service Control Manager: new service installed), Event ID 7000/7001 (service start failures that may indicate failed hypervisor load attempts)
  • > WMI: Win32_SystemDriver — enumerate all kernel drivers with PathName, State, and StartMode; cross-reference with known-good baseline
  • > CPUID Leaf 0x40000000: if a hypervisor is present, this returns a 12-character vendor string; Microsoft Hyper-V returns 'Microsoft Hv', VMware returns 'VMwareVMware' — unexpected values indicate a foreign hypervisor

Tuning Guidance

This technique is deprecated and extremely rare in the wild — treat any alert as a high-priority investigation rather than routine triage. The primary tuning challenge is distinguishing legitimate hypervisor activity (Hyper-V, VMware, VirtualBox, WSL2) from malicious implantation. Build an approved hypervisor inventory for your environment and create allowlist entries based on exact file paths, SHA256 hashes, and Authenticode signatures from known-good vendors. For bcdedit alerts, allowlist the specific argument combinations used during Windows Feature enablement (hypervisorlaunchtype auto from TrustedInstaller is benign). For driver drop alerts, never allowlist by filename alone — always require a matching vendor signature. Organizations running VDI environments with Xen PV drivers should build an exhaustive hash inventory of approved Citrix/Nutanix PV driver versions. Suppress alerts from endpoints in your virtualization team's management scope during authorized maintenance windows. Because a successful type-1 hypervisor install may make subsequent OS-level telemetry untrustworthy, consider implementing hardware-based integrity verification (TPM attestation, Measured Boot with remote attestation) as a complementary control — this provides evidence of hypervisor presence even when OS telemetry is compromised. Enable HVCI (Hypervisor-Protected Code Integrity) and Secure Boot across your fleet to significantly raise the bar for hypervisor-level attacks.

Hunting Queries

Hunt for all bcdedit executions that modify boot integrity or hypervisor settings over the past 30 days, grouped by parent process. Legitimate hypervisor enablement always comes from TrustedInstaller or DISM; any other parent (especially scripting engines, Office, or browsers) is highly suspicious. Identifies if the same pattern is recurring across multiple hosts.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "bcdedit.exe"
| where ProcessCommandLine has_any ("testsigning", "nointegritychecks", "hypervisorlaunchtype", "loadoptions")
| summarize Count=count(), Hosts=make_set(DeviceName), Accounts=make_set(AccountName), Commands=make_set(ProcessCommandLine), Earliest=min(Timestamp), Latest=max(Timestamp) by InitiatingProcessFileName
| where Count > 0
| order by Count desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 Image="*\\bcdedit.exe" (CommandLine="*testsigning*" OR CommandLine="*nointegritychecks*" OR CommandLine="*hypervisorlaunchtype*" OR CommandLine="*loadoptions*")
| stats count as Count, values(host) as Hosts, values(User) as Accounts, values(CommandLine) as Commands, earliest(_time) as Earliest, latest(_time) as Latest by ParentImage
| sort - Count

Hunt for image load events involving known hypervisor-associated binaries. Filters out legitimate Hyper-V driver loads from services.exe in System32. Focuses on unusual initiating processes or non-standard paths — a hypervisor binary loaded from a temp directory, user profile, or removable media is a strong indicator of malicious activity. Also surfaces unsigned driver loads.

Hunting — KQL
kql 
DeviceImageLoadEvents
| where Timestamp > ago(30d)
| where FileName has_any ("xen", "hvax64", "hvix64", "winhvr", "xenbus", "xennet", "xenvbd")
| where not (InitiatingProcessFileName has_any ("lsass.exe", "services.exe", "svchost.exe") and FolderPath has "System32")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine, SHA256
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=7 (ImageLoaded="*xen*" OR ImageLoaded="*hvax64*" OR ImageLoaded="*hvix64*" OR ImageLoaded="*winhvr*" OR ImageLoaded="*xenbus*")
| where NOT (Image="*\\services.exe" AND ImageLoaded="*System32*")
| table _time, host, Image, ImageLoaded, Signed, Signature, SignatureStatus
| sort - _time

Hunt for boot-time or system-time kernel driver service registrations (Start type 0 or 1) created by non-standard processes. Legitimate driver installations via Windows Update, MSI, or TrustedInstaller are excluded. A new boot-start driver registered by a script, command shell, or unexpected binary is highly anomalous and warrants immediate investigation as a potential hypervisor or rootkit component.

Hunting — KQL
kql 
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where ActionType in ("RegistryKeyCreated", "RegistryValueSet")
| where RegistryKey has @"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services"
| where RegistryValueName =~ "Start" and RegistryValueData in ("0", "1")
| join kind=inner (
    DeviceRegistryEvents
    | where RegistryKey has @"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services"
    | where RegistryValueName =~ "ImagePath"
    | where RegistryValueData has_any (".sys", "driver")
    | project DriverServiceKey=RegistryKey, ImagePath=RegistryValueData
) on $left.RegistryKey == $right.DriverServiceKey
| where not (InitiatingProcessFileName has_any ("TrustedInstaller.exe", "MsiExec.exe", "setup.exe", "wusa.exe"))
| project Timestamp, DeviceName, AccountName, RegistryKey, ImagePath, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=13 TargetObject="*\\CurrentControlSet\\Services\\*" (Details="0" OR Details="1") NOT (Image="*\\TrustedInstaller.exe" OR Image="*\\MsiExec.exe" OR Image="*\\wusa.exe")
| join type=inner TargetObject [search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=13 TargetObject="*\\CurrentControlSet\\Services\\*ImagePath" Details="*.sys" | rename TargetObject as ServiceKey | eval ServiceKey=replace(ServiceKey, "\\\\ImagePath", "") | table ServiceKey, Details]
| table _time, host, User, TargetObject, Details, Image
| sort - _time

Atomic Red Team Tests

Test 1 Enable Hyper-V Hypervisor via bcdedit (Boot Configuration Change)
windows

Simulates the boot configuration change an adversary would make to enable a hypervisor at boot time. Sets hypervisorlaunchtype to Auto using bcdedit, which is the same command a malicious hypervisor installer would run to ensure it loads before the OS. This requires administrator privileges. Revert with cleanup command.

Command

powershell 
bcdedit /set hypervisorlaunchtype auto

Cleanup

powershell 
bcdedit /set hypervisorlaunchtype off

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine containing '/set hypervisorlaunchtype auto'. Security Event ID 4688 (if command line auditing enabled). Parent process will be the test runner (cmd.exe or PowerShell).

Expected Detection

KQL BcdeditHypervisorConfig branch fires on 'hypervisorlaunchtype' in ProcessCommandLine. SPL Branch 1 matches on bcdedit with hypervisorlaunchtype pattern. Alert severity: critical.

Test 2 Disable Driver Signature Enforcement via bcdedit (Prerequisite for Unsigned Hypervisor)
windows

Disables kernel driver signature enforcement — a required prerequisite for loading any unsigned type-1 hypervisor driver on a standard Windows system. Adversaries must disable code signing checks before their malicious hypervisor driver can load. This is a strong pre-attack indicator. Requires admin privileges. Immediately reverted in cleanup.

Command

powershell 
bcdedit /set nointegritychecks on

Cleanup

powershell 
bcdedit /set nointegritychecks off

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine='bcdedit /set nointegritychecks on'. Security Event ID 4688 with same command. Microsoft-Windows-CodeIntegrity/Operational may log subsequent policy change at next boot.

Expected Detection

KQL BcdeditHypervisorConfig branch fires on 'nointegritychecks'. SPL Branch 1 matches. This is a particularly strong indicator when combined with subsequent driver creation events — correlate with file drop events for maximum fidelity.

Test 3 Create Fake Hypervisor Driver Service Registry Entry
windows

Simulates the registry modifications an adversary makes when installing a hypervisor driver as a boot-time kernel service. Creates a registry service entry pointing to a non-existent driver file, mimicking how malicious hypervisors register themselves to load before the OS. Uses sc.exe to create the service entry. Requires administrator privileges.

Command

powershell 
sc create ArgusTestHV type= kernel start= boot binPath= C:\Windows\System32\drivers\argus_hv_test.sys DisplayName= "Argus HV Test Driver"

Cleanup

powershell 
sc delete ArgusTestHV

Expected Telemetry

Security Event ID 7045 (Service Control Manager: new service installed) with ServiceName=ArgusTestHV, ServiceType=kernel driver, StartType=boot start, ServiceFileName=C:\Windows\System32\drivers\argus_hv_test.sys. Sysmon Event ID 13 (Registry value set) for HKLM\SYSTEM\CurrentControlSet\Services\ArgusTestHV entries including ImagePath, Start (value 0 = boot), and Type.

Expected Detection

KQL HypervisorServiceInstall branch detects registry key creation under Services. SPL Branch 5 detects via Security EventCode=7045 with kernel driver type. Hunting query 3 surfaces the boot-start driver registration by a non-trusted process.

Test 4 Drop Suspicious Driver File to System32\drivers (Staging Simulation)
windows

Simulates the file staging step of hypervisor implantation by copying an existing benign system file to System32\drivers with a name matching Xen paravirtualization driver conventions. In a real attack, this would be a malicious hypervisor binary. Uses a benign file (notepad.exe renamed) to test file creation telemetry without executing malicious code.

Command

powershell 
copy C:\Windows\System32\notepad.exe C:\Windows\System32\drivers\xentest.sys

Cleanup

powershell 
del C:\Windows\System32\drivers\xentest.sys

Expected Telemetry

Sysmon Event ID 11 (File Create) with TargetFilename=C:\Windows\System32\drivers\xentest.sys and Image=cmd.exe or powershell.exe. The file will be created but is a renamed benign executable — SHA256 will match notepad.exe.

Expected Detection

KQL HypervisorDriverDrop branch fires on file creation in System32\drivers with name matching SuspiciousDriverNames (xentest.sys matches 'xen' pattern). SPL Branch 2 matches EventCode=11 with xen in filename and drivers path. Analyst should verify SHA256 against known-good driver hash database.

Test 5 Enable Test Signing Mode (Unsigned Driver Loading Prerequisite)
windows

Enables Windows test signing mode, which allows loading of self-signed and unsigned kernel drivers without a valid WHQL or EV signature. This is the most common technique used in proof-of-concept hypervisor implantations and by researchers developing hypervisor rootkits. When combined with subsequent driver drops, this is a strong hypervisor installation signal. Requires administrator privileges.

Command

powershell 
bcdedit /set testsigning on

Cleanup

powershell 
bcdedit /set testsigning off

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=bcdedit.exe, CommandLine='bcdedit /set testsigning on'. Security Event ID 4688 with same content. Windows boot splash screen will show 'Test Mode' watermark after next reboot. Microsoft-Windows-CodeIntegrity/Operational logs policy change.

Expected Detection

KQL BcdeditHypervisorConfig branch fires on 'testsigning' in ProcessCommandLine. SPL Branch 1 matches. When this event is followed within minutes by a driver file drop (Sysmon Event ID 11) or service creation (Event ID 7045), escalate to critical — the combination represents a complete hypervisor installation workflow.

Related Detections

Tactic Hub

TA0003Persistence

Related Techniques

T1014RootkitT1542.001System FirmwareT1542.003BootkitT1543.003Windows ServiceT1547.001Registry Run Keys / Startup FolderT1553.006Code Signing Policy ModificationT1574.010Services File Permissions WeaknessT1497Virtualization/Sandbox Evasion

Same Tactic: Persistence

Popular Detections