Malware Hunting Reveals a Stealthy Universal Rootkit Loader

Summary

A newly discovered Microsoft-signed rootkit loader enables attackers to deploy unsigned kernel modules on compromised systems. The malware uses a first-stage driver to communicate with C2 infrastructure and load second-stage plug-ins directly into memory. This stealthy execution model helps bypass disk-based detection while maintaining highly privileged kernel-level access.

Investigation

Researchers identified a cluster of signed drivers abusing the Windows Hardware Compatibility Program (WHCP) to obtain legitimate Microsoft signatures. The investigation uncovered a two-stage execution model in which a signed loader handles the injection of customized, unsigned kernel drivers. Code and infrastructure analysis also revealed similarities to the previously documented FiveSys rootkit.

Mitigation

Organizations should monitor for suspicious or unauthorized kernel-mode driver loading and unexpected registry modifications affecting security services. Deploying endpoint detection capable of identifying memory-only module loading is critical for detecting this activity. Limiting the use of WHCP-signed drivers from unknown or untrusted vendors can further reduce exposure.

Response

When this activity is detected, isolate affected systems to disrupt C2 communication and prevent lateral movement. Perform memory forensics to identify injected kernel modules that may never be written to disk. Review registry integrity, with particular attention to Image File Execution Options and unauthorized changes to security policies.

Simulation Execution

• Attack Narrative & Commands: The adversary intends to deploy a rootkit component that masks its presence by communicating with a malicious driver. To bypass traditional file-based detection, the attacker utilizes a “Living-off-the-Land” approach, using a PowerShell script to interact with a driver that has been sideloaded into the kernel. The script specifically targets the IRP_MJ_DEVICE_CONTROL handler by sending a crafted IOCTL (I/O Control) code, mimicking the communication pattern of the identified rootkit loader to establish a command-and-control channel and disable security features.

• Regression Test Script:

  # Simulation script to mimic rootkit loader driver communication
  # Note: This requires a driver to be present that responds to these specific patterns 
  # or simulates the IRP handler calls via a mock driver.
  
  $SymbolicName = "x1cx1c??x1ceae971b87"
  Write-Host "[+] Simulating driver interaction with Symbolic Name: $SymbolicName"
  
  # In a real scenario, this would involve calling DeviceIoControl via P/Invoke
  # For simulation/testing purposes, we simulate the telemetry trigger
  $signature = @{
      SymbolicName = "x1cx1c??x1ceae971b87"
      IOControlHandler = "IRP_MJ_DEVICE_CONTROL"
      ShutdownHandler = "IRP_MJ_SHUTDOWN"
  }
  
  Write-Host "[+] Sending crafted IOCTL to trigger detection..."
  # Logic to simulate the kernel event generation for the specific SymbolicName
  # This part is conceptual for the BAS agent to trigger the specific log entry
  New-EventLog -LogName "Microsoft-Windows-Sysmon" -Source "Sysmon" # Mocking trigger

• Cleanup Commands:

  # Remove any temporary files or simulated driver artifacts
  Remove-Item -Path "$env:TEMProotkit_sim.tmp" -ErrorAction SilentlyContinue
  Write-Host "[+] Cleanup complete."