Wazuh 5.0.0 Beta4 - Windows Security Event ID 6416 (USB Device) Not Indexed or Available in Threat Hunting

46 views
Skip to first unread message

Jack Martin

unread,
Aug 6, 2026, 10:10:40 AM (4 days ago) Aug 6
to Wazuh | Mailing List

Hello Wazuh Team,

I am currently evaluating Wazuh 5.0.0 Beta4 in a lab environment and have encountered what appears to be an issue with the processing of Windows Security Event ID 6416 (Plug and Play Events / USB Device Detection).

Environment

  • Wazuh Version: 5.0.0 Beta4
  • Deployment: Single-node installation
  • Manager OS: Ubuntu 22.04
  • Windows Agent Version: 5.0.0
  • Windows OS: Windows 10 Pro

Issue Summary

Windows Security Event ID 6416 is successfully generated by the operating system when a USB storage device is connected. However, the event is not available in Wazuh Threat Hunting and cannot be found by searching:

event.code:6416

No results are returned.

Verification Performed

1. Windows Event Generation

Using Event Viewer and PowerShell, I confirmed that Event ID 6416 is generated successfully.

Example:

Event ID: 6416
Message:
A new external device was recognized by the system.

The event contains USB storage information including:

Device ID:
USBSTOR\Disk&Ven_&Prod_USB_DISK_3.0...

Device Name:
USB DISK 3.0 USB Device

Class Name:
DiskDrive

It also generates an associated event for:

Device Name:
USB Mass Storage Device

Class Name:
USB

2. Windows Audit Policy

The following audit policy is enabled:

Advanced Audit Policy Configuration
→ Detailed Tracking
→ Audit PNP Activity = Success

3. Wazuh Agent

The Windows agent is configured to monitor the Security Event Log:

<localfile>
    <location>Security</location>
    <log_format>eventchannel</log_format>
</localfile>

The agent log confirms:

Analyzing event log: 'Security'

4. Working Events

Other Windows Security events are successfully processed by Wazuh.

Examples include:

  • Event ID 4625 (Failed Logon)
  • Event ID 4672 (Special Privileges Assigned)

These events are:

  • Indexed
  • Visible in Threat Hunting
  • Successfully matched by custom Security Analytics rules and detectors

5. Observed Behavior

Searching for:

event.code:6416

returns no results.

Searching for USB-related fields (USBSTOR, USB DISK, VID/PID) also returns no results.

Expected Behavior

I expected Event ID 6416 to be:

  1. Collected by the Windows agent
  2. Processed by the manager
  3. Indexed
  4. Available in Threat Hunting
  5. Usable for Security Analytics detections

Question

Is Event ID 6416 currently supported in Wazuh 5.0.0 Beta4?

If not, is this a known limitation of the current beta, or does additional configuration need to be enabled to ingest and normalize Plug and Play (6416) Security events?

I would appreciate any guidance or confirmation regarding the expected behavior.

Thank you for your assistance.

Best regards,

jack

Olamilekan Abdullateef Ajani

unread,
Aug 6, 2026, 4:04:26 PM (4 days ago) Aug 6
to Wazuh | Mailing List
Hello Jack,

I tested this in Wazuh 5.0.0 with a Windows agent, and Event ID 6416 is collected and indexed successfully.

It appears in wazuh-events* with:

event.code: 6416
event.dataset: security

So Event ID 6416 is not blocked from ingestion.

The difference is that it may not appear in Threat Hunting/findings unless there is a matching rule or detector for it. I would first search in wazuh-events*, not only in findings, using: event.code: 6416

or simply: 6416 USBSTOR

If it appears there, the collection is working. The next step is to create a detection for USB device connection events so it becomes visible as a security finding.

Please let me know if you require further clarification.

wazuh-5.png

Jack Martin

unread,
Aug 9, 2026, 4:24:04 AM (yesterday) Aug 9
to Wazuh | Mailing List

Dear Wazuh Team,

I have successfully configured and tested USB storage device detection in our Wazuh 5.0.0 environment.

The Windows agent is generating Event ID 6416, and the events are being successfully collected and indexed. I created a custom Security Analytics rule named “USB Storage Device Connected” and configured a detector using the appropriate Wazuh events data source.

The detector is now generating findings successfully in Threat Hunting with the following details:

  • Wazuh Version: 5.0.0
  • Windows Event ID: 6416
  • Custom Rule: USB Storage Device Connected
  • Severity: Critical
  • Detector: USB Storage Device Detector
  • Status: Active
  • Result: USB connection events are successfully generating findings

The remaining requirement is whitelisting/exception handling.

For example, in a production environment we may want to alert when an unauthorized USB storage device is connected, while allowing approved devices or approved USB storage identifiers without generating a critical finding.

Could you please confirm:

  1. Does Wazuh 5.0.0 support whitelisting/exceptions for Security Analytics Sigma rules?
  2. What is the recommended method for excluding an approved USB device from the USB Storage Device Connected detection?
  3. Can we whitelist based on a specific field such as DeviceId, VendorIds, or another normalized field?
  4. Is there a recommended approach for maintaining an approved USB device allowlist without modifying the original detection rule?
  5. If this functionality is available in Wazuh 5.0.0, could you provide an example configuration for this use case?

I have attached the current detection results for reference.

Thank you for your assistance.

Best regards,
jack


Olamilekan Abdullateef Ajani

unread,
9:57 AM (9 hours ago) 9:57 AM
to Wazuh | Mailing List
Hello Jack,

I checked this further on a Wazuh 5.0 instance, and I need to clarify one thing.

Event ID 6416 is not specific to USB storage. For example, I generated a 6416 event with:

DeviceDescription: VMware USB Device
ClassName: USB
DeviceId: USB\Vid_0E0F&Pid_0001\071C536BABA30232

So a detection based only on event.code: 6416 can also match non-storage USB devices. In your original USB storage example, ClassName was DiskDrive, which is better for separating storage devices from other PnP events.

The issue is that fields such as DeviceId, ClassName, ClassId, DeviceDescription and VendorIds are still inside event.original rather than being available as individual normalized fields, you can check the json break down of the detection.

I would recommend creating a custom decoder that extracts the relevant USB fields into WCS fields first. Then the detection can be made more specific:

detection:
  selection:
    event.code: '6416'
    <class_name_field>: 'DiskDrive'

  approved_devices:
    <device_id_field>|contains:
      - 'approved-device-serial'

  condition: selection and not approved_devices

This gives you two separate controls, ClassName determines whether it is actually a storage device, while DeviceId or the unique device serial can determine whether that particular device is approved.

You should normalize the USB fields first, then build the storage detection and allowlist on top of those fields.
6416.png
Reply all
Reply to author
Forward
0 new messages