ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Endpoint Security • USB Investigation • Microsoft Defender XDR

The USB Drive Was Never Meant To Be Found

It was lying in the staff car park.

No label. No owner. Just a black USB drive beside the driver's door. Someone picked it up. Someone plugged it in. Windows Defender stayed quiet, and nothing obvious appeared to happen.

Five minutes later PowerShell started. A scheduled task was created. Persistence had begun.

Agent Foskett was not interested in the USB drive itself. He wanted to know everything that happened after it was inserted.

Discuss endpoint security Back to briefings
Agent Foskett Microsoft Defender XDR USB drive investigation
Briefing summary

A suspicious USB drive does not need to drop obvious malware to create risk. The real evidence appears in the timeline: removable media activity, process execution, file writes, registry changes and persistence.

Unknown USB Device
No Obvious Alert
PowerShell Started
Scheduled Task Created

The USB was not the attack

The device was only the delivery mechanism. The investigation starts with the behaviour that followed.
Curiosity did the work Attackers rely on helpful people, curious people and busy people. A USB drive in a car park creates a simple human decision point.
Nothing happened At least nothing obvious happened on screen. That does not mean the endpoint was quiet.
The timeline mattered The key question was not whether the USB looked suspicious. The key question was what the device did next.

What Defender XDR can show

A strong USB investigation normally moves across several endpoint tables rather than relying on a single alert.
DeviceEvents Look for removable media, storage, PnP and device connection events that explain when the device appeared.
DeviceProcessEvents Review every process that started after the USB was connected, especially script interpreters and LOLBins.
DeviceFileEvents and DeviceRegistryEvents File writes, autorun locations, registry run keys and persistence changes can reveal what the attacker left behind.

Find USB related events

Use the query as a starting point, then adjust the time window, device name and account filters for your own environment.
find-usb-related-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType has_any (
    "Usb",
    "Removable",
    "PnP",
    "Storage",
    "Drive"
)
| project
    Timestamp,
    DeviceName,
    ActionType,
    InitiatingProcessAccountName,
    InitiatingProcessFileName,
    AdditionalFields
| order by Timestamp desc

Follow the first five minutes

The first few minutes after insertion are often where the story becomes clear.
USB inserted Record the device, endpoint, user, timestamp and any fields that identify the removable media.
PowerShell started PowerShell, cmd, mshta, rundll32, wscript, cscript and regsvr32 all deserve attention after removable media activity.
Persistence appeared Scheduled tasks, registry run keys and startup folder writes can show the attack moved from initial execution to persistence.

Look for PowerShell after USB activity

Use the query as a starting point, then adjust the time window, device name and account filters for your own environment.
look-for-powershell-after-usb-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe")
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    FileName,
    ProcessCommandLine
| order by Timestamp desc

Persistence rarely announces itself

If the USB only had to run once, the attacker needed another way to come back.
Scheduled Tasks A task can quietly relaunch a script, binary or command after logon, reboot or at a set time.
Registry Run Keys Run keys remain a simple persistence method and should be reviewed after suspicious execution.
Startup folders A copied script or shortcut in a startup path can survive the original USB being removed.

Review scheduled task creation

Use the query as a starting point, then adjust the time window, device name and account filters for your own environment.
review-scheduled-task-creation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType has_any ("ScheduledTaskCreated", "ScheduledTaskUpdated")
    or InitiatingProcessCommandLine has_any ("schtasks", "Schedule.Service")
| project
    Timestamp,
    DeviceName,
    ActionType,
    InitiatingProcessAccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    AdditionalFields
| order by Timestamp desc

Hunt for registry persistence

Use the query as a starting point, then adjust the time window, device name and account filters for your own environment.
hunt-for-registry-persistence.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has_any (
    @"\Software\Microsoft\Windows\CurrentVersion\Run",
    @"\Software\Microsoft\Windows\CurrentVersion\RunOnce",
    @"\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run"
)
| project
    Timestamp,
    DeviceName,
    ActionType,
    RegistryKey,
    RegistryValueName,
    RegistryValueData,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

What investigators should ask

A USB case should not stop at the device. It should reconstruct the whole endpoint story.
Was anything executed? Focus on child processes, command lines and script execution after removable media activity.
Was anything copied? Look for files written from removable paths into user profile, temp, program data or startup locations.
Did it survive reboot? Persistence determines whether the compromise continues after the USB is removed.

Look for suspicious file writes

Use the query as a starting point, then adjust the time window, device name and account filters for your own environment.
look-for-suspicious-file-writes.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType in~ ("FileCreated", "FileModified", "FileRenamed")
| where FolderPath has_any ("\Users\", "\AppData\", "\Temp\", "\ProgramData\", "\Startup\")
| where FileName has_any (".ps1", ".vbs", ".js", ".lnk", ".bat", ".cmd", ".exe", ".dll")
| project
    Timestamp,
    DeviceName,
    ActionType,
    FolderPath,
    FileName,
    SHA256,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine
| order by Timestamp desc

Build the endpoint timeline

Use the query as a starting point, then adjust the time window, device name and account filters for your own environment.
build-the-endpoint-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
let InvestigationDevice = "DEVICE-NAME-HERE";
let StartTime = ago(1d);
union isfuzzy=true
(
    DeviceEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="DeviceEvent", ActionType, Detail=tostring(AdditionalFields), InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceProcessEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="Process", ActionType, Detail=ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceFileEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="File", ActionType, Detail=FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
),
(
    DeviceRegistryEvents
    | where Timestamp > StartTime
    | where DeviceName =~ InvestigationDevice
    | project Timestamp, DeviceName, EvidenceType="Registry", ActionType, Detail=strcat(RegistryKey, " ", RegistryValueName, " ", RegistryValueData), InitiatingProcessFileName, InitiatingProcessCommandLine
)
| order by Timestamp asc

The attacker wanted behaviour, not magic

This case was never about a mysterious USB. It was about execution, persistence and evidence.
No alert does not mean no case A quiet endpoint can still contain suspicious activity. The absence of a detection is not the absence of behaviour.
The process tree told the story A USB insertion followed by script execution, file writes and task creation becomes a defensible investigation timeline.
Remove the mystery Good incident response turns strange events into evidence: who, what, when, where and what happened next.

Related investigations

Continue the investigation through process trees, PowerShell, LOLBins, network activity and timeline reconstruction.
The Timeline Told The Story Use timeline reconstruction to explain the order of events across Defender XDR evidence.
The Child Process Shouldn't Have Existed Follow suspicious parent-child process relationships after initial execution.
The Certutil Command Downloaded Something At 2:17AM Investigate living-off-the-land behaviour when a trusted Windows binary is abused.
The PowerShell Command Was Base64 Encoded Decode suspicious PowerShell activity and understand why attackers hide commands.
The Process Tree Told The Real Story Use process lineage to separate normal activity from attacker execution.
The Device Was Talking To Something It Shouldn't Pivot from endpoint execution into suspicious outbound network connections.
Need help investigating endpoint behaviour?
GEMXIT helps organisations understand Microsoft Defender XDR evidence, endpoint telemetry, KQL hunting and practical incident response.
Contact GEMXIT

Final thought

The USB drive may never reveal who planted it. The endpoint still recorded what happened next.
At GEMXIT We help organisations investigate Microsoft Defender XDR, endpoint security, process execution, persistence and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.
Agent Foskett mindset Do not chase the object. Chase the behaviour. The removable drive is only the start of the timeline.
Develop IT. Protect IT. The USB drive was small. The evidence trail was not. GEMXIT PTY LTD | GEMXIT UK LTD

The USB Drive Was Never Meant To Be Found

This Agent Foskett investigation explains how a suspicious USB drive can lead to PowerShell execution, scheduled task persistence, registry changes and endpoint compromise.

Microsoft Defender XDR USB Investigation

DeviceEvents, DeviceProcessEvents, DeviceFileEvents and DeviceRegistryEvents can help defenders reconstruct removable media investigations and identify suspicious endpoint behaviour.

KQL Hunting For USB Malware And Endpoint Persistence

Defenders can use KQL to hunt for USB activity, suspicious PowerShell, scheduled tasks, registry run keys, file writes, LOLBins and post-compromise persistence in Microsoft Defender XDR.

ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026