BdApiUtil64.sys: Weaponized Baidu Driver in Arsenal-237 Toolkit

A Comprehensive, Evidence-Based Guide for Security Decision-Makers

Campaign Identifier: Arsenal-237-New-Files-109.230.231.37

Last Updated: January 26, 2026

BLUF (Bottom Line Up Front)

BdApiUtil64.sys is a legitimately-signed but vulnerable Baidu antivirus kernel driver weaponized as a Bring-Your-Own-Vulnerable-Driver (BYOVD) component in the Arsenal-237 malware toolkit. This Ring-0 kernel driver provides unrestricted kernel-level access, enabling attackers to terminate security products, create persistent backdoors, and steal protected data with complete bypass of user-mode security controls. Discovery of this driver on any system represents a critical kernel-level compromise requiring immediate isolation and complete system rebuild.

Quick Reference
Executive Summary
What is BdApiUtil64.sys?
Arsenal-237 Toolkit Context
BYOVD Technique: Weaponizing Legitimate Drivers
Primary Capabilities - IOCTL Code Analysis
Advanced Evasion Techniques
Attack Chain Integration
Target Security Products
Historical Campaign Context
MITRE ATT&CK Mapping
Detection Opportunities
Threat Assessment & Risk Scoring
Remediation Guidance
Response Priorities & Action Items
FAQ - Common Questions
Key Takeaways

Quick Reference

Detections & IOCs:

Related Reports:

killer.dll BYOVD Module - Primary BYOVD implementation
killer_crowdstrike.dll Variant - CrowdStrike-specific variant
Arsenal-237 Executive Overview - Full toolkit analysis

Executive Summary

The Threat in Clear Terms

When BdApiUtil64.sys loads on a Windows system, it grants attackers Ring-0 kernel privileges-the highest privilege level in Windows. This is equivalent to giving an attacker a master key to every door in your computer. Using these privileges, the driver can:

Instantly terminate any running security product (antivirus, EDR, firewalls)
Create hidden persistent backdoors that survive restarts
Access protected credential stores and steal passwords directly from system memory
Read and exfiltrate any file on the system, including encrypted data
Hide itself and malware from all user-mode detection tools
Manipulate security product registry configurations to prevent restoration

This is not a vulnerability that needs specific conditions to exploit-every system running this driver is immediately and completely compromised at the kernel level.

Business Risk Assessment

Risk Factor	Score (10pt)	Business Impact
Overall Risk Rating	9.7/10	CRITICAL - Complete kernel-level compromise
System Compromise Severity	10/10	Unrestricted kernel-level access enables complete system control
Data Breach Risk	9.5/10	Direct access to credentials, encryption keys, sensitive files
Defense Evasion Capability	10/10	All user-mode and kernel-mode security controls bypassed
Persistence Difficulty	9/10	Multiple persistence mechanisms resistant to standard removal
Remediation Complexity	10/10	Complete system rebuild is only reliable remediation method

Key Risk Factors

Organizational Guidance

For Executive Leadership:

Treat discovery of BdApiUtil64.sys as a CRITICAL INCIDENT (Priority 1) triggering emergency response protocols
Assume affected systems are completely compromised at kernel level and all security controls are circumvented
Immediate system isolation is mandatory to prevent lateral movement
Budget for complete system rebuilds as only reliable remediation
Prepare for potential data breach notification requirements (credentials, sensitive files may be compromised)
Activate incident response team and legal/compliance stakeholders immediately
Consider mandatory credential rotation for all users with any access to affected systems

For Technical Teams:

Isolate affected systems from network immediately (physically disconnect or network block)
Preserve forensic evidence (memory dump, disk image) before shutdown
Search for Arsenal-237 toolkit components on the same system (lpe.exe, killer.dll, rootkit.dll, enc_*.exe)
Hunt across network for other systems with identical IoCs (file hashes, registry artifacts, service names)
Plan immediate system rebuild from clean installation media
Deploy Windows Vulnerable Driver Blocklist on all systems post-remediation
Implement enhanced EDR monitoring for BYOVD techniques (driver loading, IOCTL calls, service creation)

Primary Threat Vector

The driver is typically deployed through:

Initial Compromise: Malware drops driver file (BdApiUtil64.sys) to C:\Windows\System32\drivers\ and registry configuration
Service Installation: Malware creates Windows service “Bprotect” pointing to driver (via IOCTL 0x80002324 or sc.exe)
Driver Load: Service starts, Windows kernel loads BdApiUtil64.sys with signature validation bypassed (legitimate Baidu certificate)
Ring-0 Activation: Driver initializes device object (\Device\BdApiUtil) and symbolic link (\DosDevices\BdApiUtil)
Defense Suppression: Malware uses driver IOCTLs to terminate security products within 5-15 seconds
Unrestricted Execution: All subsequent malware execution occurs with no security product interference

Assessment Basis: This analysis is based on direct reverse engineering of the BdApiUtil64.sys binary, IOCTL interface analysis, and integration mapping with Arsenal-237 toolkit components. Risk ratings reflect confirmed capabilities rather than theoretical threat models.

What is BdApiUtil64.sys?

File Identification & Classification

Attribute	Value	Confidence
Filename	BdApiUtil64.sys	CONFIRMED
File Size	116,800 bytes (114 KB)	CONFIRMED
MD5	ced47b89212f3260ebeb41682a4b95ec	CONFIRMED
SHA1	148c0cde4f2ef807aea77d7368f00f4c519f47ef	CONFIRMED
SHA256	47ec51b5f0ede1e70bd66f3f0152f9eb536d534565dbb7fcc3a05f542dbe4428	CONFIRMED
File Type	PE64 Kernel Driver (Windows 64-bit)	CONFIRMED
Digital Signature	Baidu Online Network Technology (Beijing) Co., Ltd	CONFIRMED
Certificate Authority	VeriSign Class 3 Code Signing 2010 CA	CONFIRMED
Signature Validity	April 24, 2012 to April 24, 2015 (EXPIRED)	CONFIRMED
Driver Version	5.0.3.84333	CONFIRMED
PDB Path	D:\jenkins\workspace\bav_5.0_workspace\BavOutput\Pdb\Release\BdApiUtil64.pdb	CONFIRMED
Original Purpose	Baidu Antivirus Kernel Utility Driver	CONFIRMED

ANALYST NOTE: D:\jenkins\workspace\: This indicates the code was compiled on a Jenkins build server. Jenkins is a very common automation server used for Continuous Integration/Continuous Deployment (CI/CD), which points to a professional software development environment. bav_5.0_workspace: This is the name of the specific Jenkins project or “workspace.” BavOutput\Pdb\Release: This shows the build configuration. It could be a Release build, meaning it was optimized for distribution, not a debug test build.

Why This Driver Is Critical

BdApiUtil64.sys is not a malicious driver-it’s a legitimate component of Baidu Antivirus. However, it contains vulnerabilities that allow unrestricted IOCTL-based kernel access. The combination of:

Legitimate Digital Signature - Windows allows kernel driver loading only from digitally-signed drivers. The expired Baidu certificate, while expired, is still accepted by Windows driver signature enforcement
Vulnerable IOCTL Interface - The driver implements IOCTLs without proper access control, allowing unprivileged user-mode processes to invoke kernel-level operations
No Process Validation - IOCTLs don’t verify the caller’s identity or purpose before executing privileged operations
Powerful Kernel Capabilities - Available operations include process termination, service creation, file system access, and registry manipulation

This combination makes it an ideal choice for BYOVD attacks. Attackers weaponize the driver not by modifying it, but by leveraging its vulnerable legitimate functionality.

Arsenal-237 Toolkit Context

Discovery & Infrastructure

HIGH CONFIDENCE (85%) - BdApiUtil64.sys was discovered on an open directory at 109.230.231.37 as part of the comprehensive Arsenal-237 attack toolkit. This IP address hosts a complete attack orchestration platform with 11 deep-dive analysis samples.

The Arsenal-237 toolkit represents a professional-grade, organized threat with sophisticated attack automation and defense evasion. The toolkit contains:

Component	File Type	Purpose	Role in Chain
lpe.exe	Executable	Privilege Escalation	Initial SYSTEM-level access
killer.dll	DLL	Security Product Terminator	First-stage defense suppression
killer_crowdstrike.dll	DLL	CrowdStrike-Specific Terminator	EDR-specific evasion
BdApiUtil64.sys	Kernel Driver	Kernel Privilege & Defense Bypass	Second-stage defense suppression
rootkit.dll	DLL	Additional kernel-level access	Redundant persistence mechanisms
enc_*.exe	Executables	Ransomware Payloads	Final attack payload (encryption)

Toolkit Sophistication Indicators

HIGH CONFIDENCE (90%) - Arsenal-237 demonstrates professional threat actor development:

Targeted Security Product Lists: Dedicated killer DLLs for Microsoft Defender, CrowdStrike Falcon, and other major EDR products (see Target Security Products section)
Redundant Defense Bypass: Multiple independent driver-based and DLL-based termination methods for defense-in-depth evasion
Infrastructure Professionalism: Organized toolkit with modular components, explicit naming conventions, coordinated attack flow
Privilege Escalation Integration: Custom lpe.exe wrapper for controlled privilege escalation prerequisite
Ransomware Payload Variants: Multiple enc_*.exe variants suggesting A/B testing or sector-specific encryption customization

This is not opportunistic malware-this is organized, sophisticated attack infrastructure suggesting either advanced APT operations or a professional malware-as-a-service platform.

BYOVD Technique: Weaponizing Legitimate Drivers

What Is BYOVD?

BYOVD (Bring Your Own Vulnerable Driver) is a modern evasion technique where attackers exploit vulnerabilities in legitimate, digitally-signed drivers rather than deploying custom malicious drivers. The technique provides kernel-level privileges while evading detection systems that may flag “suspicious” drivers.

Key Advantages:

Legitimate digital signature bypasses Driver Signature Enforcement (DSE)
Reduced detection rates (legitimate software, legitimate certificate)
No custom rootkit development required
Proven, well-documented attack pattern (reduces operational risk)
Kernel Ring-0 privileges despite user-mode compromise origin

Why BdApiUtil64.sys Was Chosen

Arsenal-237 selected BdApiUtil64.sys for specific technical reasons:

Factor	Assessment
Signature Status	Valid Baidu certificate (expired 2015, still accepted by Windows)
Vulnerability Severity	Complete lack of IOCTL access control (HIGH)
Operational Simplicity	Standard IOCTL interface, no exploitation required
Functional Coverage	All required kernel operations (process termination, service creation, file access)
Detection Evasion	Limited detection of legitimate Baidu driver file
Historical Validation	Successfully used in BlackByte, Cuba, ALPHV/BlackCat campaigns (known reliable)

Driver Installation & Activation

The typical Arsenal-237 attack flow uses BdApiUtil64.sys through these stages:

Stage 1: Initial Compromise
|
lpe.exe (Privilege Escalation Wrapper)
|
Achieves SYSTEM-level access
|
Stage 2: Driver Deployment
|
Drops BdApiUtil64.sys to C:\Windows\System32\drivers\BdApiUtil64.sys
Creates registry service entry: HKLM\SYSTEM\CurrentControlSet\Services\Bprotect
Sets StartType to 2 (automatic) or 3 (manual)
|
Stage 3: Driver Loading
|
Invokes sc.exe start Bprotect or kernel API (NtLoadDriver)
Windows kernel validates Baidu signature (legitimate, loads)
Driver initializes device objects and IOCTL interface
|
Stage 4: Defense Suppression
|
Malware sends IOCTLs to \Device\BdApiUtil
Terminates security processes via IOCTL 0x800024b4/0x800024b8
Creates backdoor services via IOCTL 0x80002324
Exfiltrates credentials via IOCTL 0x80002648
|
Stage 5: Unrestricted Execution
|
All security controls disabled, malware executes freely
Ransomware payload (enc_*.exe) executes with no interference

Primary Capabilities - IOCTL Code Analysis

BdApiUtil64.sys implements four primary IOCTL codes that provide attackers with complete system control. Each represents a distinct capability essential to the Arsenal-237 attack chain.

Capability Overview Matrix

IOCTL Code	Capability	Impact	Detection Difficulty	Confidence
0x800024b4	Direct Process Termination	Critical	Standard Termination - Can be monitored	CONFIRMED
0x800024b8	EDR-Evading Process Termination	Critical	Advanced Evasion - Defeats most EDR	CONFIRMED
0x80002324	Service Creation & Manipulation	Critical	Kernel-level - Hard to detect	CONFIRMED
0x80002648/0x8000264c	File System Access & Data Theft	Critical	Kernel-level - Bypasses ACLs	CONFIRMED

IOCTL 0x800024b4: Direct Process Termination

Purpose: Rapidly terminate security product processes using standard kernel APIs

Technical Details

Input Buffer:

Size: 4 bytes minimum
Contents: Target Process ID (DWORD)

Execution Flow:

Process Lookup: PsLookupProcessByProcessId(input_pid) - Converts user-mode PID to kernel EPROCESS structure
Privilege Grant: Kernel context grants PROCESS_ALL_ACCESS to any process (no privilege checks)
Termination: ZwTerminateProcess(process_handle, STATUS_SUCCESS) - Terminates target process
No Return Value Validation: Silently completes regardless of success or failure

Why This Is Effective

Speed: Direct termination via standard kernel API completes in 5-15 milliseconds per process
Legitimacy: Uses official Windows kernel functions, appears legitimate in kernel trace logs
Simplicity: No evasion required for initial deployment, reliable against basic monitoring
Multi-Process Capability: Terminates an entire security product suite (example: Microsoft Defender requires terminating MsMpEng.exe, NisSrv.exe, MpDefenderCoreService.exe simultaneously)

Arsenal-237 Usage

This IOCTL serves as the first-stage defense suppression mechanism. When security products have not yet detected driver loading or when evasion is not yet necessary, BdApiUtil64.sys rapidly terminates running security processes:

[Driver Load] -> [Wait 100ms] -> [Send IOCTL 0x800024b4 for MsMpEng.exe]
                                -> [Wait 50ms] -> [Send IOCTL 0x800024b4 for MpDefenderCoreService.exe]
                                -> [Wait 50ms] -> [Send IOCTL 0x800024b4 for NisSrv.exe]
                                -> [Wait 100ms] -> [Ransomware execution begins]

Detection Baseline

Without EDR: Extremely difficult (kernel-level operation, no user-mode artifact) With EDR: Possible to detect via process termination telemetry (if EDR survives termination attempt)

IOCTL 0x800024b8: EDR-Evading Process Termination (Advanced)

Purpose: Terminate security products even when they install kernel-mode hooks to detect IOCTL calls

Technical Details - The Hook Detection Mechanism

Input Buffer:

Size: 4 bytes minimum
Contents: Target Process ID (DWORD)

Pre-Execution Validation:

1. Examine first instruction of ZwTerminateProcess function
2. Check if first byte == 0xb8 (MOV EAX instruction)
3. IF 0xb8:
     -> EDR hook NOT detected, use IOCTL 0x800024b4 instead
   ELSE:
     -> EDR hook DETECTED, switch to SSDT bypass (IOCTL 0x800024b8)

Why Hook Detection?

Modern EDR products install inline hooks on critical system calls like ZwTerminateProcess. They intercept calls to:

Detect when security products are being terminated
Log and alert on suspicious termination patterns
Block or delay the termination call

By examining the first instruction, the driver can detect whether ZwTerminateProcess has been hooked:

Legitimate (Unhooked): First instruction is MOV EAX, <service_number> (opcode 0xb8), part of the SYSCALL convention
Hooked: First instruction is a JMP to EDR hook code (opcodes 0xE9 or similar), redirecting to monitoring code

SSDT Bypass Technique (The Advanced Evasion)

What Is SSDT?

The System Service Descriptor Table (SSDT) is the kernel’s internal lookup table mapping system call numbers to their implementation functions. It’s the actual “real” function that handles the operation.

User-mode API calls go through this transformation:

User-mode: ZwTerminateProcess()
         | (SYSCALL instruction with service number)
Kernel SSDT: KeServiceDescriptorTable[service_number]
         |
Actual kernel function: NtTerminateProcess()

EDR Hooking Strategy

EDR products hook ZwTerminateProcess by modifying its first few bytes to JMP to their monitoring code:

Original ZwTerminateProcess:     EDR-Hooked ZwTerminateProcess:
  MOV EAX, 0x29               ->  JMP [EDR Hook Address]
  SYSCALL                         [EDR Hook monitors call, then...]
  RET                             [EDR calls SSDT directly or patches it]

BdApiUtil64.sys SSDT Bypass Execution Flow

Dynamic Resolution:

MmGetSystemRoutineAddress("KeServiceDescriptorTable")
-> Returns address of kernel SSDT table

Service Number Extraction:

Read ZwTerminateProcess legitimate implementation
-> Extract service number from MOV EAX instruction
-> Service number for NtTerminateProcess = 0x29 (Windows 7) or varies by Windows version

SSDT Direct Lookup:

SSDT_Function = *(KeServiceDescriptorTable + (service_number << 2))
-> Retrieves actual kernel function pointer
-> Bypasses hooked ZwTerminateProcess wrapper

Direct Function Call:

Call SSDT_Function(process_handle, exit_status) directly
-> Bypasses user-mode and kernel-mode hooks
-> Executes actual process termination

Why This Defeats EDR

Hook Bypass: Doesn’t use ZwTerminateProcess at all, calls SSDT directly
No Interception: EDR hooks installed on ZwTerminateProcess never see the call
Kernel Legitimacy: Uses legitimate kernel data structure (SSDT), appears as valid kernel operation
Near-Guaranteed Success: Works against most EDR hooking strategies (some advanced EDRs may hook SSDT itself, but this is rare)

Arsenal-237 Usage Flow

[Driver Load] -> [Attempt IOCTL 0x800024b4 on security product]
              -> [If security product still running after 200ms...]
              -> [Examine ZwTerminateProcess first byte]
              -> [If hooked (0xb8 != first byte)...]
              -> [Send IOCTL 0x800024b8 with SSDT bypass]
              -> [Process terminated, EDR hook bypassed]

Detection Challenge

This technique is difficult to detect because:

No user-mode call to hooked API
Kernel operation appears legitimate (uses real SSDT)
No anomalous code execution pattern
EDR hooks never see the termination attempt

IOCTL 0x80002324: Service Creation and Manipulation

Purpose: Create persistent Windows services with kernel-level privileges, enabling backdoor installation and malware persistence

Technical Details

Input Buffer:

Size: Exactly 0x224 bytes (548 bytes)
Structure: Custom binary format with Unicode strings and configuration flags

Buffer Layout:

Offset 0x000: [Reserved/Header - 2 bytes]
Offset 0x002: Service Name (Unicode string, 0x41 chars max = 130 bytes)
Offset 0x084: Service Type (1 byte) - Kernel driver, Win32 service, etc.
Offset 0x085: Start Type (1 byte) - Auto-start (2), Demand (3), Disabled (4)
Offset 0x086: Error Control (1 byte) - Ignore, Normal, Severe, Critical
Offset 0x087: Service Tag (1 byte)
Offset 0x088: Desired Access Rights (4 bytes DWORD)
Offset 0x08C: Binary Path (Unicode string, 260 chars)
Offset 0x138: Service DLL Path (Unicode string, 260 chars)
Offset 0x1E4: Service Flags (4 bytes DWORD)
Offset 0x1E8: Service Description (Unicode string, 128 chars)

Execution Flow:

Validate input buffer size == 0x224 (strict validation)
Extract service name and binary path from input buffer
Call sub_147d0() -> internal service creation function
Invoke kernel API ObInsertObject() with service parameters
Register service in HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
Return service creation status

Why This Is Dangerous

Service Impersonation: Arsenal-237 can create services with legitimate-sounding names to hide malware:

Legitimate Service Names Used in Previous Attacks:

“WindowsUpdateService” (appears to be Windows Update, actually malware)
“MicrosoftSecurityAgent” (appears to be defender, actually backdoor)
“NvidiaGraphicsService” (appears to be GPU driver, actually persistence)
“IntelTelemetryService” (appears to be system telemetry, actually C2 beacon)

Kernel-Level Privileges: Service creation through kernel driver bypasses:

User Access Control (UAC) prompts
Service installation validation
User privilege requirements
Audit logging (traditional service creation is logged, kernel-level is not)

Backdoor Installation: Once service is created:

[IOCTL 0x80002324] -> [Service created with malware DLL]
                   -> [Service registered in HKLM]
                   -> [Service starts on next system restart]
                   -> [DLL loads automatically with SYSTEM privileges]
                   -> [Backdoor persistent across reboots]

Arsenal-237 Usage

Arsenal-237 uses IOCTL 0x80002324 to create persistence mechanisms AFTER security products are terminated:

[Driver Load] -> [Terminate security products via IOCTLs 0x800024b4/0x800024b8]
              -> [Use IOCTL 0x80002324 to create service for backdoor DLL]
              -> [Use IOCTL 0x80002648 to install service binary]
              -> [Ransomware executes with persistence mechanisms active]
              -> [If system reboots, backdoor service auto-starts]

Detection Baseline

Without Monitoring: Service creation at kernel level is invisible to standard Windows event logging With EDR: Some EDR products monitor registry modifications for service creation, but kernel-level creation may bypass logging With Behavioral Analysis: Service creation within 30 seconds of unfamiliar driver load is suspicious

IOCTL 0x80002648 & 0x8000264c: File System Access and Data Theft

Purpose: Direct kernel-mode file access bypassing all security restrictions, enabling credential and encryption key theft

Technical Details

Input Buffer:

Size: Minimum 0x208 bytes (520 bytes)
Structure: File path specification and access mode flags

Buffer Layout:

Offset 0x000: [Header/Flags - 24 bytes]
Offset 0x018: File Path (Unicode string, 259 chars maximum)
Offset 0x1XX: [Additional parameters]

File Access Method:

1. Extract file path from input buffer (Offset 0x018)
2. Invoke IoCreateFile() with:
   - DesiredAccess: 0x120089 (Read + Write + Delete + Synchronize)
   - ShareAccess: 0 (Exclusive access, no sharing)
   - OpenOptions: FILE_OPEN (open existing file, fail if not found)
3. Read/write file content directly in kernel context
4. Return file handle or file contents

Alternative Implementations

The driver implements two separate functions for file access:

sub_13bb0: Primary file access implementation (standard path)
sub_13850: Alternative processing method (likely fallback for access denied scenarios)

This redundancy ensures file access succeeds even if initial method fails (example: if file is locked).

What Files Can Be Accessed?

The driver accesses files with kernel-level privileges (SYSTEM context), bypassing:

File-level ACL (Access Control List) restrictions
File locks
EDR file access monitoring
User privilege requirements

Critical Files Arsenal-237 Targets:

File Category	Examples	Sensitive Data
Windows Credential Stores	C:\Windows\System32\config\SAM	User account password hashes
	C:\Windows\System32\config\SYSTEM	DPAPI master keys
	C:\Windows\System32\config\SECURITY	LSA secrets, domain credentials
Browser Credentials	%LOCALAPPDATA%\Google\Chrome\User Data\Login Data	Chrome saved passwords
	%APPDATA%\Mozilla\Firefox[Profile]\logins.json	Firefox stored credentials
Cloud Storage	%LOCALAPPDATA%\Google\Drive\sync_config.db	Drive authentication tokens
Email	%LOCALAPPDATA%\Microsoft\Outlook*.pst	Email archives with secrets
Encryption Keys	%APPDATA%\Microsoft\Protect[SID]	DPAPI keys (if not cached)
Security Configs	C:\Program Files[Security Product]\config.xml	EDR configuration
	HKLM registry hives	All registry settings

Arsenal-237 Credential Harvesting Flow

[Security products terminated via IOCTLs 0x800024b4/0x800024b8]
|
[Malware determines browser installed (Chrome, Firefox, Edge)]
|
[Send IOCTL 0x80002648 with file path: %LOCALAPPDATA%\Google\Chrome\User Data\Login Data]
|
[Driver reads file directly, bypassing browser locks and file permissions]
|
[Malware exfiltrates credential database to attacker C2]
|
[Repeat for additional browsers, email clients, cloud storage]
|
[Complete credential theft with no user awareness]

Two IOCTL Codes: Why 0x80002648 vs. 0x8000264c?

HIGHLY LIKELY (80%) these represent different access modes or return mechanisms:

0x80002648: Likely returns file contents to user-mode buffer (read capability)
0x8000264c: Likely performs write or in-place modification (write capability)

Both provide file system access but through different methods, giving attackers flexibility:

Read credentials -> Use 0x80002648
Delete logs -> Use 0x8000264c
Modify security configs -> Use 0x8000264c
Steal encryption keys -> Use 0x80002648

Advanced Evasion Techniques

Beyond the four primary IOCTLs, BdApiUtil64.sys implements additional kernel-level capabilities that enable sophisticated evasion and anti-forensics.

Additional Kernel Capabilities

Filter Manager API Enumeration (Minifilter Discovery)

Purpose: Detect and enumerate EDR minifilter drivers installed on the system

Kernel APIs Used:

FltEnumerateFilters() - List all loaded minifilter drivers
FltEnumerateInstances() - List instances of each minifilter
FltGetFilterInformation() - Retrieve minifilter properties (name, altitude, instance count)