Cruciferra Crypter: Combining BYOVD and Process Ghosting?
Just reviewed the new Proofpoint analysis on the Cruciferra crypter service. It appears a China-linked threat actor is actively utilizing this to target Indian tax professionals and corporate finance teams via tax-related phishing lures. What’s particularly interesting is the evasion stack: they are combining Bring Your Own Vulnerable Driver (BYOVD) with Process Ghosting.
Process Ghosting is a sophisticated file system manipulation technique. By creating a file, marking it for deletion, and then executing it before the transaction is finalized, the malware bypasses standard scanning. The image on disk is effectively 'ghosted' because it’s deleted before the process starts, yet the executable file handle remains valid in memory.
On the driver side, they likely use BYOVD to load a signed but vulnerable driver to terminate security agents.
For detection, purely static analysis is ineffective. We need to look for behavioral indicators. I'm auditing driver loads for anything not signed by Microsoft using this snippet:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kernel-PnP'; ID=6} |
Where-Object { $_.Message -notmatch 'Microsoft Windows' } |
Select-Object TimeCreated, Message
Has anyone seen specific IOCs for this in the wild yet? How are you handling the driver vulnerability blocklist without breaking legitimate software?
We’ve been hunting for similar behavior using Sysmon. Specifically, Event ID 6 (Driver Loaded) is critical here. If you see a driver loading from a user temp directory or a suspicious path, that’s a massive red flag.
C:\Users\*.sys
The trick is tuning this to avoid false positives with legitimate hardware utilities.
The Process Ghosting technique is brutal against legacy AVs that rely solely on disk scans. The file is literally gone by the time the process ID is created. In our red team engagements, we rely on this when EDR is strict. The only reliable defense I've seen clients successfully deploy is HVCI (Memory Integrity/Virtualization-based Security). It forces driver signing checks at the hardware level, which effectively neutres the BYOVD component.
From a Sysadmin perspective, enabling the 'Vulnerable Driver Blocklist' via Group Policy is a no-brainer now, even if it does break some older peripheral software.
# Check HVCI status
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
If `SecurityServicesConfigured` is 0, you're wide open to these driver exploits. It's the first thing I check on new client builds.
Building on Leo's point, verifying Memory Integrity is the strongest defense against BYOVD payloads. Since the snippet got cut off, here is the full command to check the Device Guard status across your endpoints.
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access