Windows Forensics 105: USB Devices & Persistence: Who Plugged What Where, and Why Won’t This Malware Leave?

Series: Windows Forensics | Author: Tech Corsair | Published: techcorsair.co.uk

This article covers two topics that sound unrelated but share a common theme: things that show up uninvited and leave traces behind. USB devices are the physical version -- someone plugs in a thumb drive, and Windows writes down everything short of the person's shoe size. Persistence mechanisms are the digital version -- malware moves in, changes the locks, and forwards its post.

Both are staples of forensic investigations, and both generate the kind of evidence trail that makes analysts genuinely happy. Well, as happy as someone gets whilst staring at registry keys at midnight. Let's call it "professional satisfaction."

Part 1: USB Device Forensics -- The Complete Audit Trail

When a USB device is connected to a Windows system, the operating system reacts like a particularly anxious customs officer: it logs everything. Device type, serial number, first connection time, last connection time, assigned drive letter, the user who connected it, and more. This information is scattered across multiple locations -- because Windows doesn't do "centralised" when "distributed across six different artefacts" is an option.

Where Windows Records USB Activity

1. USBSTOR Registry Key

Location: SYSTEM\CurrentControlSet\Enum\USBSTOR

The primary registry location for USB mass storage device records. Each connected USB storage device creates a subkey containing:

SYSTEM\CurrentControlSet\Enum\USBSTOR\Disk&Ven_SanDisk&Prod_Ultra_USB_3.0&Rev_1.00\
  4C530001140818109154
    FriendlyName = SanDisk Ultra USB 3.0
    ContainerID  = {a1b2c3d4-e5f6-7890-abcd-ef1234567890}

2. USB Registry Key

Location: SYSTEM\CurrentControlSet\Enum\USB

Records the USB vendor ID (VID) and product ID (PID) for all USB devices -- not just storage. This lets you identify the exact make and model:

SYSTEM\CurrentControlSet\Enum\USB\VID_0781&PID_5581\
  4C530001140818109154

VID 0781 = SanDisk. PID 5581 = Ultra USB 3.0. Cross-reference with the USB ID database at https://devicehunt.com or https://the-sz.com/products/usbid/ for manufacturer lookup.

3. MountedDevices

Location: SYSTEM\MountedDevices

Maps drive letters and volume GUIDs to device signatures. This answers the question "what drive letter was assigned to that USB device?"

\DosDevices\E: = {binary data containing device signature}
\??\Volume{guid}  = {binary data containing device signature}

Cross-referencing the binary data with USBSTOR entries links a specific USB device to a specific drive letter. This is essential when you need to prove that "the files on E:\ came from this specific SanDisk device."

4. MountPoints2

Location: NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Per-user record of volumes mounted by that user. This is the critical artefact for user attribution -- it proves which user account was logged in when a specific device was connected.

NTUSER.DAT\...\MountPoints2\{volume-GUID}
  Key Last Write Time: 2024-03-15 14:22:33 UTC

The GUID here matches the volume GUID from MountedDevices, creating a chain: USB device (USBSTOR) -> Drive letter (MountedDevices) -> User who connected it (MountPoints2). It's a forensic relay race, and the baton is a GUID.

5. setupapi.dev.log

Location: C:\Windows\INF\setupapi.dev.log

The setup API log records device installation events with timestamps. This is often the most reliable source for the first connection time of a USB device.

>>>  [Device Install (Hardware initiated) - USBSTOR\Disk&Ven_SanDisk&Prod_Ultra_USB_3.0&Rev_1.00\4C530001140818109154]
>>>  Section start 2024/03/15 14:22:15.789
     dvi: {Build Driver List} 14:22:15.801
     dvi: {Build Driver List - exit(0x00000000)} 14:22:15.823
     ...
     dvi: Install complete.
<<<  Section end 2024/03/15 14:22:16.234
<<<  [Exit status: SUCCESS]

That timestamp -- 2024/03/15 14:22:15.789 -- is the moment Windows first saw this device. It's precise, it's reliable, and it's sitting in a plain text log file that many forensic analysts overlook. Don't be one of them.

6. Event Logs

Several event log sources record USB activity:

The USB Forensic Chain: Putting It All Together

To fully document a USB device connection, forensic practitioners trace through multiple artefacts:

1. USBSTOR         -> Device make, model, serial number
2. USB (VID/PID)    -> Manufacturer and product identification
3. setupapi.dev.log -> First connection timestamp
4. MountedDevices   -> Assigned drive letter / volume GUID
5. MountPoints2     -> User who connected it (per NTUSER.DAT)
6. Shellbags        -> Folders browsed on the device
7. LNK files        -> Files opened from the device
8. Event logs       -> Connection/disconnection events

This chain answers the fundamental question: Who connected what device, when was it connected, what drive letter was it assigned, and what did the user do with it?

USB Analysis Tools

# Eric Zimmerman's Registry Explorer - browse USBSTOR keys
# RECmd with batch file for automated extraction
RECmd.exe -f "C:\Evidence\SYSTEM" --bn BatchExamples\RECmd_Batch_MC.reb --csv "C:\Output"

# USB Detective (free/commercial) - comprehensive USB analysis
# Correlates all USB artefacts into a unified timeline

# RegRipper USB plugins
rip.exe -r "C:\Evidence\SYSTEM" -p usbstor
rip.exe -r "C:\Evidence\SYSTEM" -p usbdevices
rip.exe -r "C:\Evidence\NTUSER.DAT" -p mountpoints2

Part 2: Persistence Mechanisms -- The Malware That Overstays Its Welcome

Persistence is the art of ensuring that malware survives a reboot. It's the digital equivalent of a house guest who unpacks, puts their things in the drawers, changes the Netflix password, and casually mentions they've redirected their post to your address. Removing them requires more effort than you'd expect and usually involves finding things hidden in places you didn't know existed.

Windows offers an embarrassment of riches when it comes to persistence locations. The MITRE ATT&CK framework lists dozens under the Persistence tactic (TA0003), but the following are the greatest hits -- the ones that appear in the majority of real-world investigations.

1. Registry Run Keys -- The Front Door

Locations:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

The most straightforward persistence mechanism: add an entry, and it runs at logon. The HKLM versions run for all users; HKCU versions run for the specific user. RunOnce keys are deleted after execution -- a one-shot persistence used for initial setup or self-deleting payloads.

Key:   HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Name:  WindowsSecurityUpdate
Value: C:\ProgramData\Microsoft\svchost32.exe -k netsvcs

Malware authors love naming their payloads after legitimate Windows processes. svchost32.exe is not a real Windows binary -- the legitimate version is svchost.exe (no "32"). It's like wearing a fake moustache to a crime scene and hoping nobody looks too closely.

Additional Run key locations often missed:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute

2. Scheduled Tasks -- The Alarm Clock

Location (files): C:\Windows\System32\Tasks\

Location (registry): SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\

Event Log: Event ID 4698 (Security), Event IDs 106/140/200/201 (TaskScheduler Operational)

Scheduled tasks are the second most popular persistence mechanism because they offer precise control over execution timing and can run under different user contexts, including SYSTEM.

<!-- C:\Windows\System32\Tasks\MicrosoftEdgeUpdate -->
<Task>
  <Triggers>
    <CalendarTrigger>
      <StartBoundary>2024-03-15T03:00:00</StartBoundary>
      <Repetition>
        <Interval>PT1H</Interval>
      </Repetition>
    </CalendarTrigger>
  </Triggers>
  <Actions>
    <Exec>
      <Command>C:\ProgramData\packages\updater.exe</Command>
      <Arguments>-enc aQBlAHgAIAAoAG4AZQB3AC0...</Arguments>
    </Exec>
  </Actions>
  <Principals>
    <Principal>
      <UserId>S-1-5-18</UserId>  <!-- SYSTEM -->
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
</Task>

A "MicrosoftEdgeUpdate" task that runs from ProgramData with Base64-encoded arguments under SYSTEM? That's malware wearing a very thin disguise. The -enc flag is PowerShell's -EncodedCommand parameter, which is about as subtle as a brick through a window.

# List all scheduled tasks and export
schtasks /query /fo CSV /v > scheduled_tasks.csv

# RegRipper plugin
rip.exe -r "C:\Evidence\SOFTWARE" -p tasks

# Autoruns (Sysinternals) - comprehensive persistence scanner
autorunsc.exe -a * -c -h -s -v -vt > autoruns_output.csv

3. Services -- The Lodger

Location: SYSTEM\CurrentControlSet\Services\

Event Log: Event ID 7045 (System) -- new service installed

Services are attractive for persistence because they start automatically, run under privileged accounts (often LocalSystem), and blend in with the hundreds of legitimate services on any Windows system.

Key:        SYSTEM\CurrentControlSet\Services\WinDefHealthSvc
ImagePath:  C:\Windows\System32\drivers\windefhealth.sys
Start:      2 (Auto Start)
Type:       1 (Kernel Driver)

Kernel-level persistence via a fake Defender service. This is the persistence equivalent of buying a house next door to the police station -- hiding in plain sight.

Red flags in service entries:

• Services with binary paths pointing to Temp, ProgramData, or user profile directories
• Services with no Description value
• Service names mimicking legitimate Windows services with slight variations
• Start value of 0 (Boot) or 1 (System) for non-driver services

4. WMI Event Subscriptions -- The Invisible Hand

Location: C:\Windows\System32\wbem\Repository\

Components: Event Filter + Event Consumer + Filter-to-Consumer Binding

WMI event subscriptions are the persistence mechanism that most administrators don't know exists and most monitoring tools don't check. They're composed of three parts that together create a trigger-action pair:

# Detecting WMI persistence
Get-WMIObject -Namespace root\Subscription -Class __EventFilter
Get-WMIObject -Namespace root\Subscription -Class __EventConsumer
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding

# Or using the newer CIM cmdlets
Get-CimInstance -Namespace root/subscription -ClassName __EventFilter
Get-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer
Get-CimInstance -Namespace root/subscription -ClassName ActiveScriptEventConsumer
Get-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding

WMI persistence is particularly insidious because it doesn't appear in the registry Run keys, isn't visible as a scheduled task, and doesn't show up as a service. It's the forensic equivalent of hiding behind the sofa -- you have to know to look there.

Sysmon Event IDs 19, 20, and 21 capture WMI event filter, consumer, and binding creation respectively. Yet another reason to deploy Sysmon.

5. Startup Folders -- The Welcome Mat

Locations:

C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\

The oldest trick in the book. Drop a shortcut or executable in the Startup folder, and it runs at logon. It's so straightforward that sophisticated threat actors tend to avoid it -- but it still shows up regularly because, well, it works.

# Check startup folders
dir "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\"
dir "C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\"

6. DLL Hijacking & Side-Loading -- The Impersonator

DLL hijacking exploits Windows' DLL search order to load a malicious DLL instead of (or alongside) a legitimate one. The attacker places a malicious DLL in a location that's searched before the legitimate DLL's location.

Common techniques:

Legitimate app:    C:\Program Files\TrustedApp\app.exe
Expected DLL:      C:\Program Files\TrustedApp\helper.dll
Malicious DLL:     C:\Program Files\TrustedApp\helper.dll  (replaced)

DLL hijacking is particularly effective because the malicious code runs within the context of a legitimate, often signed, application. EDR tools see TrustedApp.exe loading a DLL from its own directory and think nothing of it. The attacker gets execution within a trusted process -- a win-win situation for everyone except the defenders.

Persistence Detection: The Systematic Approach

Autoruns: The Swiss Army Knife

Sysinternals Autoruns remains the single best tool for comprehensive persistence detection. It checks every known autostart location and can compare results against VirusTotal.

# Command-line version with all the bells and whistles
autorunsc.exe -a * -c -h -s -v -vt -nobanner > autoruns.csv

# Flags:
#   -a *   All autostart locations
#   -c     CSV output
#   -h     Show file hashes
#   -s     Verify digital signatures
#   -v     Verify with VirusTotal
#   -vt    Accept VirusTotal terms

The Persistence Checklist

For systematic investigation, check these locations in order:

[ ] Registry Run/RunOnce keys (HKLM and HKCU)
[ ] Scheduled tasks (file system and registry)
[ ] Services (SYSTEM hive)
[ ] Startup folders (per-user and all-users)
[ ] WMI event subscriptions
[ ] Winlogon keys (Shell, Userinit, Notify)
[ ] Boot Execute (Session Manager)
[ ] DLL search order in key applications
[ ] Browser extensions (yes, really)
[ ] COM object hijacking (InprocServer32 modifications)
[ ] Image File Execution Options (debugger persistence)
[ ] AppInit_DLLs (loaded into every user-mode process)
[ ] Office add-ins and templates
[ ] Screensaver executable (HKCU\Control Panel\Desktop\SCRNSAVE.EXE)

That last one always raises eyebrows. Yes, the screensaver setting is a legitimate persistence vector. Attackers point it at their payload, set the timeout to something reasonable, and wait for the user to go for a cup of tea. The malware literally executes because someone walked away from their desk. It's almost elegant.

Timeline Integration

USB events and persistence mechanisms should be correlated on a timeline to understand the full attack narrative:

14:22:15 - USB device first connected (setupapi.dev.log)
14:22:33 - User 'jdoe' accessed USB volume (MountPoints2)
14:23:01 - suspicious.exe executed from E:\ (Prefetch)
14:23:15 - New service installed: WinDefHealthSvc (Event ID 7045)
14:23:22 - Registry Run key modified (NTUSER.DAT last write time)
14:23:30 - Scheduled task created (Event ID 4698)
14:25:00 - USB device disconnected (DriverFrameworks event)

In under three minutes: device connected, payload executed, three persistence mechanisms established, device removed. The attacker (or the malware) was efficient, thorough, and considerate enough to leave a complete evidence trail. How thoughtful.

What's Next in the Series

This is part of the Windows Forensics series on techcorsair.co.uk:

• WF-101: The Registry -- Where Windows keeps its diary. Every hive, every secret.
• WF-102: Execution Artifacts -- Prefetch, Shimcache, Amcache, and proving someone was here.
• WF-104: Event Logs -- The world's most boring novel that could save your job.
• WF-105: USB Devices & Persistence -- You are here. The uninvited guests and the ones who won't leave.

This series has covered the core pillars of Windows forensics: the registry's comprehensive record-keeping, the artefacts that prove program execution, the event logs that provide narrative context, and the physical device connections and persistence mechanisms that tie investigations together. With these foundations in place, you're equipped to tackle the vast majority of Windows forensic investigations -- or at least to look like you know what you're doing until the coffee kicks in.

Tech Corsair -- Evicting digital squatters since the registry was a single file.