Attached, lettered, refused: what USB evidence does not prove

The external drive on this laptop was the investigator's, not the subject's. A client asked me to investigate the laptop of an employee suspected of leaking data. The client's investigator acquired it on site, with my remote support, by plugging a 1 TB USB hard drive into the running laptop and imaging onto it. The drive showed a letter at once, and then refused every attempt to open it for an evening and a night.

When I examined the laptop afterwards, it held a complete record of that acquisition. Read with the published USB material, the record says something else: a drive connected 29 times over three days, opened in Explorer seconds after insertion, privileged accounts logging on around the time access began, command-line work against the volume and Defender settings, and about 139 GB written out, a memory dump included. On a leakage case, that is the shape of exfiltration.

Almost every part of that reading is wrong, and each wrong part rests on an artifact that is read correctly. The drive letter was real, the Explorer click was real, the 29 arrivals were real. What the published material has no place for is the layer between them and the data: an endpoint policy that let Windows attach and letter the drive, then denied every read.

This Field Note sets the standard reading against the evidence that corrects it, source by source, with the exact records. Most of those sources do not appear in any USB write-up I could find, and one of them records the access decision itself.

The short version

A USB record proves that a device was attached, not that its file system was usable. Between "plugged in" and "used" there are six separate layers, and each one can succeed while the next one fails. On this laptop the first three succeeded 29 times, and the fourth refused every attempt for 15 hours 25 minutes.

• The refusal is recorded in Microsoft Defender's Device Control support log, per device and per arrival, as the set of access rights granted and denied.
• The release is recorded in Defender/Operational event 5007, which keeps the full XML of the removed policy as its old value: a rule denying all removable media, a rule allowing a list of approved devices, and the list itself. The Device Control log grants access 166 ms later.
• The file system's side is recorded in Microsoft-Windows-Ntfs/Operational: event 305 for each refused mount with its NTSTATUS, event 4 for the first real mount, and event 142, whose free-space samples measure the data written, hour by hour.
• None of the accounts unlocked the drive, although two of them looked as if they had.
• A second drive on the same laptop fails the other way. It survives only in a pre-upgrade migration snapshot, with no letter, user, file or access decision, and the standard reading either misses it or reports it as used.

The practical window for proving any of this from event logs is months, not years. A feature upgrade closes it overnight, as it had done on this laptop six weeks before the acquisition.

What was examined

One BitLocker-protected laptop running Windows 11 25H2 (build 26200), acquired as an E01 image after the events described here, and examined with the AlexSta Velociraptor fork, through a dead-disk remap of the encrypted volume. The host runs at UTC+3; all times below are UTC. The three days of the acquisition are called day 1, day 2 and day 3.

The clock is trustworthy. The System log shows synchronization with a domain controller on day 2 and no time step afterwards; the only step that morning is a resume from sleep.

Two readings of the same laptop

The published USB material would lead a careful examiner to a confident and wrong account of this laptop. The table below takes each observation in the order an examiner meets it, the reading the published material supports, and what the evidence shows instead. The sources in the second column are credited in the references.

The standard account reads: connected on day 1 and browsed at once, reconnected repeatedly, used for three days, privileged accounts involved as access appeared, logs cleared, volume unknown. The evidence reads: attached and lettered but refused by endpoint policy for 15 hours, released by a cloud policy change rather than by any account, first written to on the evening of day 2, and about 139 GB written by a forensic imaging tool.

The investigator's own recollection held on every point about the refusal and was one day off on first use. The drive mounted on day 2 and was first written to that evening, local time; most of the bytes were written on day 3, which is the day the investigator remembered.

Six layers between "plugged in" and "used"

Each layer answers a different question, and published work treats the first three as proof of use. The fourth, permission, sits below the file system: Device Control acts on the disk device when it arrives, so the volume and the letter still appear while every read is refused.

The absence of layer 5 on day 1 is evidence, because the channel was live: it holds 65 events for other volumes between 17:30 and 21:00 that evening, and none of any ID for this drive.

The refusal, in Defender's own words

The Device Control support log is the only host source I found that names the access decision for a specific device and the moment it changed. It sits at C:\ProgramData\Microsoft\Windows Defender\Support\MPDeviceControl-<date>-<time>.log, is written in UTF-16 with UTC timestamps, and on this laptop ran continuously for 197 days: 28.8 MB, 138,380 lines, with no rotation.

At each Defender start it records the feature state and whether a policy is present, and at each device arrival it writes one decision line. The first arrival of the investigator's drive, as the disk device (serial masked):

2026-..-.. 18:07:25.417 [DC] DoDevicePresenceNotification: PresenceType[1]
  InstancePathId[USBSTOR\DISK&VEN_TOSHIBA&PROD_EXTERNAL_USB_3.0&REV_0\2015092700XXXXX&0]
  VID[0480] PID[A200]
  CurrentGrantedAccess[None] MaximumPossibleGrantedAccess[None]
  CurrentDeniedAccess[Read, Write, Execute, FsRead, FsWrite, FsExecute, Print]

The log recorded every blocked device for six months, not only this one. Logging began six and a half months before the acquisition and the policy was present from the next day. Five weeks before the acquisition a different USB stick was denied in exactly the same way. One flag in the log, fForceDeviceControlEnabled, still read 0 at that point; I first took that to mean enforcement was off, and the denial refutes it.

Every arrival of the investigator's drive over the next 15 hours repeats the line above. After each reboot the log records "DefaultEnforcement has changed from 0 to 1" with the policy present, which is why nothing the investigator tried on day 1, restarts included, changed the outcome. The last denial is at 09:11:08 on day 2.

The volume node and the disk node disagree, and only the disk node matters. The same log carries lines for the drive's Windows Portable Devices volume node, and those show full access throughout. An examiner who searches the log for the drive letter or volume, and not for the USBSTOR disk instance, would conclude the drive was allowed.

The PresenceType values are not documented, and I report them as observations: 1 and 3 accompany an arrival, 2 follows 1 on some arrivals, 4 appeared once when the policy changed with the drive present, and 5 accompanies removal.

The log has no published forensic treatment that I could find. One DFIR post lists it by name among Defender's support logs; Microsoft's documentation tells administrators to collect it in a support package without describing it; the exact strings above return no published page. An administrators' monitoring tool may parse it, which is why the claim here is limited to forensic writing.

The release: a rule that vanished

Access began 166 milliseconds after a cloud-delivered USB policy was removed, and Defender kept a copy of the whole policy. Defender/Operational event 5007, "configuration has changed", records the old and new value of each setting. At 09:32:52.290 on day 2, six 5007 events carried the Device Control policy groups, rules and last valid package as old values, each with an empty new value. Read together, they give the complete policy:

The access mask decodes to exactly what the log printed. The bits are Read 1, Write 2, Execute 4, FsRead 8, FsWrite 16, FsExecute 32 and Print 64. Mask 127 is all seven, which is the denied set in every refusal line for the investigator's drive; mask 91 is the same set without the two execute rights. The bit values are in Microsoft's device control documentation; what the host adds is a recovered policy that decodes to exactly the set the log printed.

The policy explains the outcome device by device. An approved device would have been readable and writable, and every other removable drive was refused. None of the USB storage devices recorded on this laptop is on the list, the investigator's drive included. One serial on the list has a Western Digital format, but it appears on the host only inside the policy text; it was never attached here.

The sequence that follows is causal and measured to the millisecond:

The removal came through device management, not a local edit. The key sits under the Policy Manager path where cloud management writes Defender settings, and in the same second every other managed Defender setting reverted to its default: script scanning, archive scanning, threat default actions. The MDM diagnostic logs place a device sync one minute earlier, and the MDM sync client ran from 09:31:48 to 09:32:56. That pattern fits a policy or assignment being withdrawn in Intune.

Who withdrew it is not on the host. 364 MDM Admin events across the three days name neither Defender nor Device Control. The actor, and whether the change was an unassignment or an exclusion, live in the tenant's audit log.

Why neither account switch was the fix

The investigator believed access came after changing accounts, first to the security lead's domain account, then to a scanner service account. Both beliefs were reasonable at the time, and the evidence rules out both.

• The security lead's account logged on at 09:27:06, five minutes before the release, and its logon triggered an Intune user sync. But the domain GPOs it received concern baselines and a proxy, not storage, and the device sync that removed the rule is a separate session. That profile shows D: opened at 09:33:17 and nothing below the root: no LNK file, no jump list entry, no subfolder shellbag, no command naming the drive.
• The scanner service account first logged on at 18:33:56, nine hours after access was granted, and it was the account under which FTK Imager ran for the acquisition.

What the NTFS channel records

Microsoft-Windows-Ntfs/Operational is the only event log that separates "letter assigned" from "file system usable". Published USB work uses it for the drive letter (event 142 and 145) and for mount and eject (events 4, 300 and 303). Four more of its events carry most of the answer here.

Event 305 separates a refusal from a loss. Both refusals on day 2 carry Error 3221225506, which is 0xC0000022, and the same MountStageSourceTag. The day 3 failure carries 0xC000000E and a different tag, because by then the device had dropped off the bus. The refused mounts also carry an empty volume label, because the label is read during the mount that failed, and the letter D:, because the letter already existed.

Why day 1 produced no 305 while day 2 produced two is not established. One explanation fits the timing: on day 1 Device Control denied the disk before NTFS attempted a mount. I leave it as open.

Event 142 as a meter of data written

Free space sampled about hourly turns into net bytes written per hour. Event 142 carries the minimum and maximum free space in each interval, the volume size and the cluster size. The investigator's drive fell from 931.22 GB free at the first mount to 792.37 GB free at the last sample: 138.85 GB of net writes, in Windows' binary gigabytes, confirmed by the investigator as the acquisition.

The meter measures writes minus deletions, not content, and it stops at every standby. Within those limits it answers a question the published material treats as unanswerable from the host: how much went onto the drive, and when. Nothing else on this laptop measured it.

The first file on the drive predates the meter's first movement. D:\hh.txt, a zero-byte file, was created at 17:38:40 on day 2, eight seconds after the evening mount, recorded by an LNK file and two jump lists carrying the drive's volume serial. It is the test file of someone checking that the drive finally worked.

Keeping the drive's identity across 29 arrivals

The published way to tie a volume serial to a USB device no longer works on this build. Earlier Windows 10 and 11 versions of Partition/Diagnostic event 1006 carried the first sectors of each partition in fields named Vbr0 to Vbr3, from which the NTFS volume serial can be read, and several write-ups use exactly that to link LNK files to a device. On Windows 11 25H2 the event is version 7, and its field list ends at Ebr3. There is no VBR field to read. Ilya Kobzar noticed in 2021 that Vbr0 stopped being recorded after updates; on 25H2 the reason is visible in the event's own field list.

Two other threads hold the identity together instead:

• The MBR in event 1006 hashed identically on all 29 arrivals, which proves the disk was readable every time and its partition table never changed.
• One GUID ties the volume across sources. Ntfs VolumeCorrelationId, the MountPoints2 subkey and the event 142 VolumeGuid are all {XXXXXXXX-0000-0000-0000-100000000000}: the MBR disk signature, followed by the partition offset of 0x100000 (1 MiB). It stays constant while \Device\HarddiskVolumeN changed from 5 to 9 across the arrivals.

The binary MountedDevices value has long been documented as disk signature plus offset. Its string form in these GUIDs, and its appearance as the Ntfs correlation id, I have not found described. I first took the prefix for the NTFS volume serial; the LNK files' serial, a different value, refuted that.

A drive letter identifies the latest holder only. MountedDevices and Windows Portable Devices show D: held by a SanDisk stick, then a card reader slot, then the USB stick denied five weeks earlier, then the investigator's drive, over 18 months. The Search volume cache entry for D: and the This PC\D: shellbag each keep one record per letter, so on this laptop they describe the investigator's drive and nothing before it. Cyberengage and Hats Off Security had already noted that MountedDevices and the Search volume cache keep only the last device per letter; the shellbag behaves the same way. Tie evidence to the volume GUID or serial, not to the letter.

A drive's class depends on who is asking. The LNK LinkInfo records DriveType 3, a fixed disk, because a USB hard drive presents itself that way to Explorer. Device Control matched the same drive through its RemovableMediaDevices group. An examiner who reads "fixed" in the LNK and concludes a removable-media policy could not have applied is reasoning from the wrong classification.

The second drive: present, and nothing more

The same laptop holds a drive that the standard reading gets wrong in the opposite direction. The investigator's drive has every layer up to use, and the literature places it correctly as attached. A 1 TB WD Elements drive, volume label IMAGING, has one layer: a record that it was present. The standard reading either misses it or reports it as used.

Six USB storage identities appear on the host: a SanDisk stick, a two-slot card reader, the WD, the USB stick denied five weeks before the acquisition, the investigator's drive and a phone. Only the investigator's drive remains in the live device tree. The others survive in MountedDevices, Windows Portable Devices, the third-party agent's logs and the pre-upgrade migration snapshot, and every storage device except the WD also left a volume or letter record somewhere.

Everything the host knows about the WD

Nothing on the host names a letter, a user, a file or an access decision for it. The live USBSTOR and USB keys, the Properties timestamps, MountedDevices (including its transaction logs and deleted space), the Search volume cache, MountPoints2 in all eight profiles, the agent's logs, which reach back 19 months, the Device Control log and the allow-list were all searched, and none holds it. The 2,736 LNK and automatic jump-list entries from all eight profiles, and the shellbags of the three active profiles, reference no volume other than C: and the investigator's drive. A byte search for the WD's partition GUID and disk GUID across every hive, upgrade log and event log found only its own partition cache.

Its last presence falls four minutes before Defender started that morning. LastPresentDate is read here as the last time Windows saw the device; Microsoft does not document it. The Device Control log, which recorded every other blocked device, has no line for the WD; its last line before that moment is from the previous day, and when Defender started it reported that the filter was not connected. Booting from the drive, or attaching it during start-up, would both fit. The host cannot say which, and no source on it can place a user on the laptop that day: the profile load times, the hives' creation times and the Security log have all been overwritten since.

Two wrong readings and one defensible one

1. A review of the live device tree reports no WD drive on this laptop. That is a false negative.
2. A review that also applies the upgrade literature on DeviceMigration reports that the subject connected a WD drive on that morning. The timestamp is right; the attribution and the implied use are not supported by anything on the host.

The defensible wording states what the host holds and stops there: a WD Elements drive labelled IMAGING was first seen during the laptop's installation and last present on that morning; no artifact ties it to a user account, a drive letter or a file; it was not on the allow-list, and from the day the policy arrived it would have been refused. The host cannot show that it was ever usable.

The investigator's drive and the WD are the same lesson from opposite ends. One drive has abundant records of attachment and was refused; the other has one migrated timestamp and would be reported as used. In both, the question that decides the case sits in layers 4 to 6, and the standard reading stops at layer 1.

How long the answers survive

Every event log on this laptop was six weeks old, because a Windows 11 feature upgrade had recreated them all. The log files, the oldest record in every channel that had not wrapped, and the install date all fall on one morning, and the Source OS key names the previous build. The Field Note on feature updates describes what such an upgrade does to every source. Here it set a floor: nothing about this drive could have been older than that morning, and nothing from before it survives.

Within those six weeks, each channel's size decides how far back it reaches, and every channel overwrites its oldest events by 64 KiB chunk when full:

The refusal outlives the Ntfs channel, and the volume of data does not. Without Ntfs/Operational, the Device Control log and event 5007 still prove the refusal and its cause, and user artifacts naming a file on the drive's volume serial still prove the file system was once usable. The exact mount times, the dismount reasons and the hour-by-hour volume of data exist only in Ntfs events 4, 300, 303 and 142.

Shadow copies do not reach behind the upgrade either. The system volume holds two stores, both created after it: one 21 seconds before the oldest surviving Security record, and one on day 2, two minutes before the first refused mount.

An examiner arriving a week after the acquisition would already have lost every Security 4688 record of the day 1 troubleshooting. The PSReadLine history and the Device Control log would still carry it.

Rules for an examiner

1. Treat a USB record, a drive letter and an Explorer click as proof of attachment only. Use of the file system needs layer 5 or 6 evidence: an Ntfs mount, or an artifact naming a file on that volume.
2. Look for the permission layer before reading repeated arrivals as use. Collect C:\ProgramData\Microsoft\Windows Defender\Support in full, search the Device Control log by the USBSTOR disk instance, not the volume, and read Defender/Operational 5007 for removed rules.
3. Read Ntfs 305 and its Error field. 0xC0000022 is a refusal; 0xC000000E is a device that went away. Search failures by device path and correlation id too, because a refused mount lacks the volume label you might filter on.
4. Use event 142 as a meter when the question is how much was written, and state it as net bytes between samples.
5. Do not rely on event 1006 for volume serials on 25H2. Tie volumes through the MBR hash and the disk-signature GUID.
6. Test every account-based explanation against the moment access changed. The logon closest to it is a candidate, not a cause.
7. Establish the log floor first. A feature upgrade, a small channel or a large Security log can each put the answer out of reach, and an absence counts only where the source was live and covered the period.

Traps I hit on the way

Each of these cost time on this case, and each will cost time on the next one.

• A third-party endpoint agent launched its device-control component on every arrival and looked like the blocker. Its own log says it had no policy at all.
• Two sweeps returned silent zeros: an invalid query expression, then a misnamed YARA argument. A sweep that finds nothing proves nothing until it has found something it should.
• A filter on the vendor name missed both refused mounts at first. Search failures by device path and correlation id as well.
• The agent writes two timestamp formats, one of them DD-MM-YYYY HH.MM.SS, so a grep for ISO dates skipped a whole log.
• The USBSTOR Properties subkey name contains braces, which Velociraptor's glob reads as alternation; a literal glob returns nothing. Glob Properties\* and filter.
• The first search for the WD, by vendor strings in the live tree and the Device Control log, found nothing. It lives only in the migration snapshot and the upgrade log.
• Exporting LNK files and jump lists out of the image with Velociraptor's copy() into a folder that did not exist returned 579 rows and wrote nothing, with no error in the output I captured. After creating the folder, a re-run with a slightly adjusted file set wrote 528 files, which LECmd and JLECmd parsed into 2,736 LNK and jump-list entries.
• The libbde library rejected this laptop's BitLocker metadata version, so the shadow copy catalog was read through the bde accessor of the AlexSta Velociraptor fork instead.
• A double time conversion in PowerShell put the first mount two hours early. Rebuild times from the raw epoch field.

References

Every finding here came from the case itself, starting with a drive that would not open. The sources below published parts of it first, and each is credited for that. Together they are also the standard reading this Field Note is set against; each is accurate about what it covers.

USB forensics

• SANS, Windows Forensic Analysis poster, External Device/USB Usage
• ElcomSoft, USB Device Forensics on Windows 10 and 11 (2026)
• Harlan Carvey, USB Devices Redux (2022): Ntfs/Operational 142 and 145
• Harlan Carvey, HowTo: USB Thumb Drives (2012)
• Thomas Diot, ETW: Devices and USB activity (artefacts.help)
• Magnet Forensics, Artifact Profile: USB Devices
• Compass Security, Investigating data leakage via external storage devices (2019)
• Vestige, Can you determine if someone has copied or taken data? (2024)
• Cyberengage, Drive letter identification and volume GUID to user mapping (2024)
• Hats Off Security, USB forensics part 5: determine the drive letter (2014)
• B!n@ry z0ne, Investigating USB drives using mount points, not drive letters (2020)
• Elite Digital Forensics, USB Device Forensics
• NXLog, USB device auditing on Windows (2026): event 6423

Partition/Diagnostic and volume identity

• df-stream, USB device tracking using the Partition/Diagnostic event log (2018)
• DFIR Review, Recover more volume serial numbers with the Partition/Diagnostic event log
• libyal libvshadow, Volume Shadow Snapshot format
• libyal winreg-kb, MountedDevices: disk signature and partition offset

Event logs and upgrades

• Hacking Exposed Computer Forensics Blog, Windows, now with built-in anti-forensics (2017)
• Ilya Kobzar, Windows updates and anti-forensics (2021): DeviceMigration, and Vbr0 no longer recorded after updates
• AlexSta Field Notes, What a Windows 11 feature update does to forensic evidence

Microsoft

• Device control in Microsoft Defender for Endpoint
• Device control policies: access mask values and groups
• Device control report and advanced hunting events
• System error codes: ERROR_ACCESS_DENIED