// Proyecto: Forense de dispositivos USB en Windows
// Fuente brave://device-log/
// Estado: Actividad USB reconstruida mediante correlación de artefactos
0x00 Introducción
DISCLAIMER
Este análisis tiene finalidad educativa y de práctica profesional. Las evidencias corresponden a un entorno controlado y se utilizan para reforzar metodología DFIR, análisis de logs, correlación de artefactos de Windows y documentación técnica para analistas SOC.
En análisis forense de Windows solemos mirar fuentes clásicas como Event Viewer, Registry, SetupAPI, Prefetch, LNK o artefactos de ejecución.
Sin embargo, hay fuentes menos habituales que pueden aportar muchísimo contexto cuando se capturan a tiempo.
Una de esas fuentes es brave://device-log/, disponible también como chrome://device-log/
En este ejercicio reconstruyo actividad USB a partir de Brave Device Log, la exporto a un archivo .log, la analizo con Loxx y después la correlaciono con artefactos persistentes de Windows.
0x01 Brave Device Log
El punto de partida fue abrir brave://device-log/ y filtrar por eventos USB.
Esta página interna muestra eventos generados por el subsistema de dispositivos que Chromium
/Brave observa
desde Windows.
En la vista aparecen entradas de tipo USBUser y USBError, con timestamps, fichero de origen, línea del componente y mensaje del evento.
Valor forense
Brave Device Log permite ver conexiones y desconexiones USB con timestamps muy precisos, además de campos como VID, PID, vendor, product, serial, driver y GUID.
0x02 Exportación del log y análisis con Loxx
El log de Brave es volátil.
Si se cierra el navegador, la evidencia desaparece.
Por eso el siguiente paso fue capturar el contenido y guardarlo como archivo:
Flujo de trabajo
brave://device-log/ → copiar eventos → guardar como brave device log.log → abrir en Loxx → filtrar patrones.
En Loxx se buscaron los patrones principales:
- USB device added — conexiones.
- USB device removed — desconexiones.
- USBError — errores del proceso de enumeración.
- vid_145f — Trust Wireless Mouse.
- vid_258a — BY Tech Usb Gaming Keyboard.
- serial="" — dispositivos sin número de serie.
0x03 Eventos de conexión y desconexión
El primer filtro fue USB device added.
Este patrón permite localizar cada momento en el que Brave detecta que un dispositivo USB ha sido añadido al sistema.
Después se filtró por USB device removed, lo que permite completar el ciclo de vida de cada dispositivo.
Cambio de enfoque
No basta con saber que hubo actividad USB. El valor aparece cuando separamos conexiones, desconexiones, dispositivos concretos y campos de identificación.
0x04 Identificación por VID, PID y serial
El siguiente paso fue buscar por vid_. Esto permite localizar rápidamente identificadores USB en el log.
Dos dispositivos aparecen como principales durante el análisis:
| Dispositivo | VID/PID | Serial | Driver |
|---|---|---|---|
| BY Tech Usb Gaming Keyboard | VID_258A&PID_0016 | serial="" | usbccgp |
| Trust Wireless Mouse | VID_145F&PID_0302 | b120300001 | usbccgp |
0x05 BY Tech Usb Gaming Keyboard
Al filtrar por vid_258a, Loxx aísla el teclado BY Tech.
El evento muestra vendor=9610 "BY Tech", product=22 "Usb Gaming Keyboard" y serial="".
Limitación forense
El teclado no expone número de serie.
Esto permite identificar el modelo, pero no distinguir de forma fuerte entre dos unidades físicas idénticas con el mismo VID/PID.
0x06 Trust Wireless Mouse
En cambio, el filtro vid_145f permite aislar el Trust Wireless Mouse. En este caso sí aparece un número de serie estable: b120300001.
También hay dispositivos con el serial vacío.
Una línea completa de conexión del Trust Mouse permite ver todos los campos relevantes:
Evidencia fuerte
USBUser[2026/05/13 22:59:29.139898]
USB device added: vid_145f&pid_0302#b120300001
vendor=5215 "YICHIP", product=770 "Trust Wireless Mouse", serial="b120300001", driver="usbccgp"
También se capturó una línea completa de desconexión del mismo dispositivo:
0x07 Timeline reconstruida
A partir de los eventos filtrados, la timeline principal queda así:
| Timestamp | Evento | Dispositivo | Lectura |
|---|---|---|---|
| 2026-05-13 14:43:35 | Added | Trust Wireless Mouse | Conexión previa del ratón. |
| 2026-05-13 14:43:49 | Removed | BY Tech Keyboard + Trust Mouse | Desconexión casi simultánea. |
| 2026-05-13 22:51:49 | Added | BY Tech Keyboard + Trust Mouse | Ambos aparecen juntos en el bus USB. |
| 2026-05-13 22:53:17 | Removed | BY Tech Keyboard + Trust Mouse | Diferencia aproximada de milisegundos. |
| 2026-05-13 22:59:29 | Added | BY Tech Keyboard + Trust Mouse | Reconexión conjunta tras unos 6 minutos. |
| 2026-05-14 10:00:36 | Removed | BY Tech Keyboard | Desconexión aislada del teclado. |
| 2026-05-14 10:03:33 | Added | BY Tech Keyboard | Reconexión tras unos 3 minutos. |
Correlación clave
El teclado BY Tech y el Trust Wireless Mouse se conectan y desconectan con diferencias de milisegundos.
Esto sugiere un evento físico o lógico compartido: hub USB, dongle, reenumeración del bus, suspensión/reanudación o pérdida momentánea de alimentación.
0x08 Errores USBError: ruido o señal
Durante el análisis aparecen múltiples entradas USBError. Loxx muestra 147 coincidencias.
| Código | Significado | Lectura defensiva |
|---|---|---|
| 0x103 | ERROR_NO_MORE_ITEMS | Fin normal de enumeración. No quedan más interfaces que recorrer. |
| 0x490 | ERROR_NOT_FOUND | Windows no encuentra una propiedad concreta del dispositivo. |
Conclusión sobre errores
En este contexto, los errores 0x103 y 0x490 no indican compromiso.
Son compatibles con ruido normal de enumeración USB cuando Brave/Chromium consulta propiedades que el dispositivo no expone.
0x09 Correlación con artefactos de Windows
Para no depender solo de Brave, la evidencia se correlacionó con fuentes persistentes de Windows.
Dispositivos USB conectados actualmente:
Get-PnpDevice -Class USB | Where-Object {$_.Status -eq 'OK'}
Historial USB en Registry:
Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Enum\USB" | Select-Object PSChildName
Registry confirma que el dispositivo existe bajo Enum\USB, pero para obtener timestamps de Last Write, First Install o Last Arrival es preferible usar Registry Explorer, RegRipper, USBDeview o USB Device Tree Viewer.
0x0A SetupAPI y DriverFrameworks
El archivo C:\Windows\inf\setupapi.dev.log permitió confirmar que los dispositivos también aparecen en el historial de instalación y actualización de drivers.
Select-String -Path "C:\Windows\inf\setupapi.dev.log" -Pattern "vid_258a" -Context 2,2
Select-String -Path "C:\Windows\inf\setupapi.dev.log" -Pattern "vid_145f" -Context 2,2
Las interfaces MI_00 y MI_01 encajan con dispositivos USB compuestos. Esto es coherente con el driver visto en Brave: usbccgp.
También se comprobó el canal Microsoft-Windows-DriverFrameworks-UserMode/Operational.
Limitación de la fuente
En este caso DriverFrameworks no aportó eventos útiles para la reconstrucción.
Esto no invalida el análisis: simplemente deja a Brave Device Log, Loxx, Registry y SetupAPI como fuentes principales.
0x0B Hallazgos
- El dispositivo VID_145F&PID_0302 corresponde al Trust Wireless Mouse.
- El Trust Wireless Mouse expone el serial b120300001, por lo que es trazable con más fiabilidad.
- El dispositivo VID_258A&PID_0016 corresponde al BY Tech Usb Gaming Keyboard.
- El teclado BY Tech aparece con serial="", lo que limita su atribución física.
- Ambos dispositivos se conectan y desconectan en varios momentos con diferencias de milisegundos.
- Los errores 0x103 y 0x490 son compatibles con enumeración normal.
- No se observan indicadores directos de compromiso en la evidencia analizada.
La sincronía entre teclado y ratón sugiere un evento compartido: hub USB, dongle, reenumeración del bus, suspensión/reanudación del sistema o desconexión física de un concentrador.
0x0C Conclusión
Este ejercicio demuestra que brave://device-log/ puede ser una fuente útil para enriquecer investigaciones DFIR sobre dispositivos USB en Windows.
Su principal valor está en la precisión temporal y en la exposición de campos como VID, PID, vendor, product, serial, driver y GUID.
Su principal limitación es la volatilidad si no se captura a tiempo, la evidencia puede perderse.
La correlación con Registry y SetupAPI permitió reforzar la identificación de los dispositivos observados, un teclado BY Tech sin serial y un Trust Wireless Mouse con serial estable.
Veredicto
Actividad USB legítima o esperable, con cambios de numeración conjuntas de teclado y ratón.
No hay evidencia directa de compromiso (es mi ratón y teclado)
El valor del caso está en la metodología de correlación entre Brave Device Log, Loxx, Registry y SetupAPI.
0x0D Comandos utilizados
# Listar dispositivos USB conectados actualmente
Get-PnpDevice -Class USB | Where-Object {$_.Status -eq 'OK'}
Ver historial USB en Registry
Get-ChildItem “HKLM:\SYSTEM\CurrentControlSet\Enum\USB” | Select-Object PSChildName
Consultar una clave concreta
Get-Item “HKLM:\SYSTEM\CurrentControlSet\Enum\USB\VID_258A&PID_0016”
Buscar dispositivos en SetupAPI
Select-String -Path “C:\Windows\inf\setupapi.dev.log” -Pattern “vid_258a” -Context 2,2
Select-String -Path “C:\Windows\inf\setupapi.dev.log” -Pattern “vid_145f” -Context 2,2
Comprobar DriverFrameworks
Get-WinEvent -ListLog Microsoft-Windows-DriverFrameworks-UserMode/Operational | Select-Object LogName, Enabled, RecordCount, LogMode
Intentar extraer eventos recientes
Get-WinEvent -LogName Microsoft-Windows-DriverFrameworks-UserMode/Operational -MaxEvents 20 | Select-Object TimeCreated, Id, ProviderName, Message
0x0E Lecciones aprendidas
- Una fuente volátil puede tener mucho valor si se captura a tiempo.
- Brave Device Log no sustituye a los artefactos de Windows, pero puede enriquecer la timeline.
- El serial USB es clave para atribución física del dispositivo.
- Un dispositivo sin serial limita la trazabilidad forense.
- Los errores de enumeración no deben interpretarse automáticamente como compromiso.
- La correlación entre varias fuentes es lo que convierte ruido en evidencia.
[ EOF ]
"Logs do not explain themselves. Correlation does."