# USB Serial Number in file.Ext.device.serial\_number Always Zero or Random one digit Value

**URL:** <https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051>\
**Category:** Endpoint Security\
**Tags:** elastic-stack-security\
**Created:** [September 18, 2025, 11:34am UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051 "2025-09-18T11:34:10Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![alrolo3](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alrolo3/32/140606_2.png) [@alrolo3](https://discuss.elastic.co/u/alrolo3)\
**Post date:** [September 18, 2025, 11:34am UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/1 "2025-09-18T11:34:10Z")

</div>

Hello everyone,

I’m opening this topic because I couldn’t find any solution or open issue related to this problem, either in GitHub or other forums.

We are currently using **Elastic Security as our SIEM** , and one of our most relevant use cases is detecting **data exfiltration to USB devices**.

By default, the **Elastic Defend integration** logs file writes and deletions to removable drives, using the field:

```auto
file.Ext.device.bus_type:"Usb"

```

The logs also include additional USB device information, such as:

- file.Ext.device.product\_id

- file.Ext.device.serial\_number

- file.Ext.device.vendor\_id

However, the most important field — file.Ext.device.serial\_number — is always logged as either a random number or simply 0.

For example, with a Kingston USB drive we tested:

```auto
file.Ext.device.product_id: DataTraveler 3.0
file.Ext.device.serial_number: 0
file.Ext.device.vendor_id: Kingston

```

But the **real serial number** , which can be retrieved from the Windows Registry key USBSTOR, is something like:

```auto
E0D55E62C799176068XXXXX

```

This discrepancy makes it very hard to reliably track specific devices.

Has anyone else experienced this issue?

Is this a known bug or a current limitation?

Is the Elastic engineering team aware of it / working on a fix?

Any ideas, workarounds, or official confirmation would be greatly appreciated.

Thanks in advance,

Best regards

---

<div class="post-metadata">

**Author:** ![lesio](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lesio/32/89323_2.png) [@lesio](https://discuss.elastic.co/u/lesio)\
**Post date:** [September 18, 2025, 12:14pm UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/2 "2025-09-18T12:14:16Z")

</div>

Can you see the expected serial number from Powershell

`Get-WmiObject Win32_DiskDrive |`  
` Where-Object { $_.InterfaceType -eq "USB" } |`  
` Select Model, SerialNumber, PNPDeviceID`

---

<div class="post-metadata">

**Author:** ![alrolo3](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alrolo3/32/140606_2.png) [@alrolo3](https://discuss.elastic.co/u/alrolo3)\
**Post date:** [September 18, 2025, 12:23pm UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/3 "2025-09-18T12:23:50Z")

</div>

PS C:\Windows\system32\> Get-WmiObject Win32\_DiskDrive |

> > Where-Object { $\_.InterfaceType -eq "USB" } |  
> > Select Model, SerialNumber, PNPDeviceI

 ![Captura](https://us1.discourse-cdn.com/elastic/original/3X/d/b/db6f4434f40541f1404068ab206329ad55ab9377.png)

---

<div class="post-metadata">

**Author:** ![alrolo3](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alrolo3/32/140606_2.png) [@alrolo3](https://discuss.elastic.co/u/alrolo3)\
**Post date:** [September 18, 2025, 12:44pm UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/4 "2025-09-18T12:44:11Z")

</div>

Two different devices

 ![Captura](https://us1.discourse-cdn.com/elastic/original/3X/2/a/2ac03790e8c240deb0a512109ff3a3bbbbb7ecae.png)

---

<div class="post-metadata">

**Author:** ![lesio](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lesio/32/89323_2.png) [@lesio](https://discuss.elastic.co/u/lesio)\
**Post date:** [September 18, 2025, 4:42pm UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/5 "2025-09-18T16:42:17Z")

</div>

Thanks for the feedback, so the serial number is not directly passed in the structures where we expect this. It seems it’s the first time we hear about it, and thanks for the hint. I guess it’s worth to cross check with macOS and Linux, if the other way of obtaining the serial number can be trusted. I’m adding a ticket to our backlog.

---

<div class="post-metadata">

**Author:** ![alrolo3](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/alrolo3/32/140606_2.png) [@alrolo3](https://discuss.elastic.co/u/alrolo3)\
**Post date:** [September 18, 2025, 5:11pm UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/6 "2025-09-18T17:11:13Z")

</div>

Thanks for your fast reply. We use to debug the “USBDeview” App and the best workaround we find is to use the PNPDeviceID. As you can see, the last part of the ID is equal to the Real Serial Number.

![Captura de pantalla 2025-09-18 190857](https://us1.discourse-cdn.com/elastic/original/3X/3/7/37b61aaa022181d3a858e0b79a31e9a3f58b52e2.png)

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 16, 2025, 5:12pm UTC](https://discuss.elastic.co/t/usb-serial-number-in-file-ext-device-serial-number-always-zero-or-random-one-digit-value/382051/7 "2025-10-16T17:12:12Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
