Auditing Windows Minifilter Altitudes and Background Antivirus Telemetry Services with PowerShell

When troubleshooting high I/O latency, unexpected background network sockets, or residual services left behind after consumer security suite trials, standard Windows Task Manager views rarely show the full picture. Consumer endpoint suites typically split their footprint across three distinct execution layers:

1. Kernel-Mode File System Minifilter Drivers (fltMgr.sys) operating at assigned filter altitudes.
2. Protected User-Mode Services (PPL / Win32OwnProcess) managing real-time heuristics and cloud definitions.
3. Scheduled Telemetry & Licensing Daemons responsible for heartbeat checks, seat validation, and recurring subscription state synchronization.

In this walkthrough, we will build a repeatable PowerShell and fltmc diagnostic workflow to enumerate active filter drivers, inspect orphaned scheduled tasks, and verify clean service teardown across consumer antivirus stacks.

---

1. Enumerating Kernel File System Minifilter Altitudes

Every file system filter driver registered with the Windows Filter Manager (fltMgr.sys) is assigned a numeric altitude by Microsoft that determines its position in the I/O stack. Per the Microsoft Allocated Filter Altitudes specification, antivirus filter drivers must reside within the FSFilter Anti-Virus group (320000 – 329999).

If two security suites—or an incomplete uninstallation of a previous suite—leave two active minifilters competing in the 320000 range, synchronous IRP_MJ_CREATE callbacks can deadlock or introduce 40–120ms file-open penalties.

Run an elevated PowerShell prompt to inspect all loaded minifilters and map their altitude ranges:

# Enumerate loaded minifilter instances and filter for Anti-Virus / Activity Monitor ranges
$fltmcOutput = fltmc instances | Select-String -Pattern "^\S+\s+\S+\s+(\d{6})"
foreach ($line in $fltmcOutput) {
    $parts = ($line.Line -split '\s+') | Where-Object { $_ -ne '' }
    if ($parts.Count -ge 3) {
        [PSCustomObject]@{
            FilterName = $parts[0]
            Volume     = $parts[1]
            Altitude   = [double]$parts[2]
            Group      = switch ([double]$parts[2]) {
                { $_ -ge 360000 -and $_ -le 389999 } { "Activity Monitor" }
                { $_ -ge 320000 -and $_ -le 329999 } { "FSFilter Anti-Virus" }
                { $_ -ge 260000 -and $_ -le 269999 } { "Content Screener" }
                default { "Other Filter Group" }
            }
        }
    }
}

When auditing third-party OEM engines (such as Avira-derived SAVAPI filters or Bitdefender OEM SDK wrappers deployed by multi-brand consumer suites), verify that WdFilter (328010, Windows Defender) is the sole active filter after removing a third-party product.

---

2. Tracing User-Mode Services and Corporate Vendor Lineages

Consumer security products frequently share underlying detection engines and cloud licensing backends under a parent holding structure. When investigating unfamiliar binaries or certificate signers in C:\Program Files, mapping the binary's Authenticode signature against an independent Protected.net Group Ltd endpoint architecture & vendor telemetry dossier helps distinguish legitimate OEM security daemons from masquerading persistence mechanisms (MITRE ATT&CK T1543.003).

You can audit all non-Microsoft auto-start services and verify their Authenticode publisher chain directly in PowerShell:

Get-CimInstance Win32_Service |
    Where-Object { $_.StartMode -eq 'Auto' -and $_.PathName -notmatch 'Windows\\System32' } |
    ForEach-Object {
        $exePath = ($_.PathName -replace '^"([^"]+)".*$', '$1' -split '\s+')[0]
        $sig = if (Test-Path $exePath) { Get-AuthenticodeSignature -FilePath $exePath } else { $null }
        [PSCustomObject]@{
            ServiceName = $_.Name
            State       = $_.State
            BinaryPath  = $exePath
            Signer      = $sig.SignerCertificate.Subject
            Status      = $sig.Status
        }
    } | Format-Table -AutoSize

---

3. Auditing Residual Scheduled Tasks and Subscription Heartbeats

Even after the primary kernel driver and Win32_Service entries are stopped, many consumer security installers register user-session scheduled tasks or background updater stubs that continue polling licensing endpoints. Equally important, uninstalling the local MSI/EXE binary on the endpoint does not send an API revocation call to the vendor's cloud billing processor.

To inspect and clean up orphaned scheduled tasks and reconcile local endpoint removal with account-level billing states:

1. Query Non-Microsoft Scheduled Tasks:

Get-ScheduledTask |
    Where-Object { $_.TaskPath -notlike "\Microsoft\*" -and $_.State -ne "Disabled" } |
    Select-Object TaskName, TaskPath, State, @{N='Execute';E={$_.Actions.Execute}}

1. Verify Complete Teardown & Account State: Before wiping residual AppData\Local or registry keys (HKLM\SYSTEM\CurrentControlSet\Services), cross-check the TotalAV service uninstallation, kernel driver cleanup, and subscription lifecycle audit hub to ensure cloud seat de-provisioning, auto-renewal termination, and driver unregistration are executed in the proper order.

---

Key Takeaways for Systems Engineers

• Always check fltmc: An uninstalled GUI does not guarantee the kernel minifilter (320000–329999) was unloaded from fltMgr.sys.
• Validate Authenticode Signers: Multi-brand security conglomerates sign binaries under parent corporate entities rather than retail product names.
• Separate Local Removal from Cloud Licensing: Local service removal and cloud subscription state operate on completely independent planes—audit both during endpoint decommissioning.