SentinelOne - Triaging Driver Blocking Alerts After a USB Wireless or Bluetooth Device Is Inserted

Purpose

Use this when SentinelOne produces a burst of Driver Blocking detections immediately after a USB wireless, Bluetooth, or combined radio adapter is inserted into a Windows endpoint.

The goal is to avoid treating a hardware-enumeration event as malware by default, while still proving the affected Windows drivers are genuine and unmodified.

Diagnostic pattern

A hardware-related pattern is worth considering when several of these show up together:

• Alerts begin immediately after a USB wireless or Bluetooth device is inserted.
• Detected files are under C:\Windows\System32\drivers.
• The detections come from SentinelOne's driver-blocking engine, not a user-mode process chain.
• The first affected drivers are Windows USB or Bluetooth components such as hidusb.sys, bthenum.sys, bthpan.sys, Microsoft.Bluetooth.Legacy.LEEnumerator.sys, or rfcomm.sys.
• Later detections may include unrelated Microsoft driver files as Windows keeps loading or checking kernel components.
• The alert data has no suspicious originating process, command line, dropped executable, scheduled task, or obvious user-mode child process.

This pattern is not proof of a false positive. Treat it as a strong troubleshooting branch. Validate the files before you dismiss the detections.

Validation procedure

Disconnect the newly inserted device first. Keep it for testing. Do not leave it in place during triage.

Check signatures, hashes, version information, and timestamps for the drivers SentinelOne flagged:

$Drivers = @(
    'hidusb.sys',
    'bthenum.sys',
    'bthpan.sys',
    'Microsoft.Bluetooth.Legacy.LEEnumerator.sys',
    'rfcomm.sys'
)

$Results = foreach ($Driver in $Drivers) {
    $Path = Join-Path $env:windir "System32\drivers\$Driver"

    if (Test-Path $Path) {
        $File = Get-Item $Path
        $Sig  = Get-AuthenticodeSignature $Path
        $Hash = Get-FileHash $Path -Algorithm SHA256

        [pscustomobject]@{
            Driver          = $Driver
            Exists          = $true
            SHA256          = $Hash.Hash
            SignatureStatus = $Sig.Status
            Signer          = $Sig.SignerCertificate.Subject
            Company         = $File.VersionInfo.CompanyName
            Product         = $File.VersionInfo.ProductName
            FileVersion     = $File.VersionInfo.FileVersion
            LastWriteTime   = $File.LastWriteTime
        }
    }
    else {
        [pscustomobject]@{
            Driver = $Driver
            Exists = $false
        }
    }
}

$Results | Format-Table -AutoSize
$Results | Format-List

Enumerate the USB, Bluetooth, network, and HID hardware that is actually present:

Get-PnpDevice -PresentOnly |
    Where-Object {
        $_.Class -in 'Bluetooth','Net','USB','HIDClass'
    } |
    Sort-Object Class,FriendlyName |
    Format-Table Status,Class,FriendlyName,InstanceId -AutoSize

What to compare in SentinelOne

For each detection, compare:

• Detection engine and classification.
• Full file path.
• File hash against the file currently on disk.
• Signature state and signer.
• Originating process or process tree, if present.
• Detection timestamp relative to the hardware insertion time.
• Whether the alerts stay confined to kernel drivers or extend into suspicious user-mode activity.

Escalation indicators

Treat the event as more suspicious if any of the following appear:

• A driver is stored outside expected Windows or vendor driver locations.
• The on-disk hash does not match the detected file or a known-good copy.
• A Microsoft-named driver is unsigned, signed by an unexpected party, or has inconsistent version or company metadata.
• A suspicious user-mode process such as PowerShell, cmd.exe, mshta.exe, a script interpreter, or an unknown executable is tied to the event.
• Persistence, scheduled tasks, Run keys, services, or outbound network activity appear near the same time.
• The problem continues after the newly inserted hardware is removed and the endpoint is rebooted.

Catches / gotchas

• A burst of Windows driver detections can look much worse than a single-device event. Hardware insertion makes Windows enumerate several dependent driver stacks.
• No parent process on a driver-blocking alert is useful context. It does not, by itself, prove the driver is safe.
• Do not globally allowlist a set of drivers because the filenames look like Microsoft. Validate signatures, hashes, and context first.
• Do not change SentinelOne agent versions or broad security policy during initial triage. That can destroy the original test condition.

Key lesson

When a SentinelOne alert storm starts immediately after a USB wireless or Bluetooth device is inserted, and the detections are confined to Windows kernel drivers, hardware enumeration or driver-control interoperability is a credible first hypothesis. Validate the files and the process context before you call it compromise or a false positive.