"Shortcut Virus": How Its Spreads, How to Detects and Removes It

Malware family: USB autorun/shortcut worm ("Shortcut Virus")
Detection name: Shortcut Virus (heuristic, path-based)
Vector: removable/USB drives, autorun.inf, VBScript relaunchers


Summary

Despite being one of the oldest tricks in the book, the so-called "Shortcut Virus" (also known as the LNK worm, or the "USB folder virus") remains one of the most commonly encountered infections on removable media, especially in environments where USB flash drives are passed between shared computers — internet cafes, school computer labs, print shops, and offices with lax USB policies. It doesn't rely on any exploit or vulnerability. Instead, it abuses ordinary, well-documented Windows features: file attributes, autorun.inf, Windows Script Host, and the registry Run keys.

This post breaks down exactly how the malware behaves on an infected drive, then walks through the heuristic indicators a scanner can use to catch it and the concrete steps needed to reverse the damage.

1. How the infection works

The "Shortcut Virus" pattern is less a single piece of malware and more a reusable playbook that many low-sophistication VBScript/batch worms implement almost identically. The typical infection chain looks like this:

  1. Initial execution — the user double-clicks what looks like their own USB drive/folder icon, or an autorun.inf silently triggers execution on drive mount (on older/misconfigured systems). The actual payload is usually a .vbs, .exe, or .bat file hidden with the Hidden + System attributes.
  2. Hiding the user's real files — every real file and folder on the drive is re-flagged with FILE_ATTRIBUTE_HIDDEN, FILE_ATTRIBUTE_SYSTEM, and often FILE_ATTRIBUTE_READONLY. Because Windows Explorer hides "protected system files" by default, the user's actual documents/photos effectively disappear.
  3. Planting decoy shortcuts — for every hidden item, the malware drops a .lnk shortcut with the same name and a folder-like icon. The shortcut's target isn't the real file — it's a command that (a) silently re-launches the hidden payload via wscript.exe/cscript.exe, and (b) opens the real hidden item as a side effect, so the user sees their file open normally and suspects nothing.
  4. The hidden " " (single space) folder variant — some variants instead move all of the user's real files into one folder literally named " " (a single space) and hide it, so the drive root looks empty except for a shortcut or two.
  5. Spreading further — an autorun.inf at the drive root (with an open=, shellexecute=, or run= directive) is used to auto-launch the payload on drives that still honor autorun, and the payload copies itself onto any other removable drive it sees plugged into the same machine.
  6. Persistence on the host PC — once run, the payload typically persists itself via:
    • the HKCU/HKLM ...\CurrentVersion\Run and RunOnce registry keys, pointing at wscript/cscript plus a .vbs/.ps1 file;
    • a dropped .vbs/.bat/.exe relauncher in %APPDATA%, %LOCALAPPDATA%, or the user's/all-users' Startup folder;
    • a Task Scheduler task (on more persistent variants) referencing wscript/cscript;
    • occasionally, hiding a copy of itself inside System Volume Information, banking on the fact that folder is normally locked to SYSTEM/TrustedInstaller and most users (and some scanners) never look there.
  7. Defensive tampering — to make itself harder to remove, many variants flip the same Group Policy registry values IT administrators use to lock down a machine: DisableTaskMgr, DisableCMD, DisableRegistryTools, and NoFolderOptions (which also hides the "show hidden files" toggle from the victim). Some also set HideFileExt so a payload like Photos.jpg.exe displays as Photos.jpg.

None of this requires a software vulnerability — it is purely social engineering plus abuse of legitimate OS features, which is exactly why it has survived essentially unchanged for well over a decade and still circulates widely on removable media today.

2. Detecting it: heuristic indicators worth checking

Because this pattern doesn't correspond to a single file hash or byte signature, it's best caught heuristically rather than by signature match. Every removable and fixed drive can be checked against two independent, hard-to-fake signals — either one alone is enough to raise a "Suspicious" verdict:

  • Shadowed items: a .lnk file at the drive root whose name (minus .lnk) matches a hidden file or folder of the same name sitting right next to it. This is the core mechanism of the attack — a legitimate drive essentially never produces this combination by accident.
  • The hidden " " folder: a folder literally named a single space, hidden, at the drive root.

A third signal — the presence of autorun.inf — is recorded as supporting context in the log line if one of the two signals above already fired, but it never triggers a detection by itself. That's deliberate: plenty of legitimate removable media (camera memory cards, printer installer USB sticks, some driver/installation discs) ship with a harmless autorun.inf, so treating it alone as malicious would make the scanner noisy and erode trust in its verdicts.

Because this is a heuristic rather than a hash match, a well-behaved scanner should report the result as "Suspicious" rather than a hard "Infected" label, and should never auto-quarantine or auto-delete the affected drive without a separate, explicit cleanup step — a heuristic is a strong hint, not proof.

The diagram below traces the full infection chain, from the moment a USB drive is inserted to the point it starts spreading to other removable media:

1. USB drive inserted / opened User double-clicks the drive icon in "This PC" 2. Hidden payload executes autorun.inf (legacy) or the shortcut itself launches wscript/cscript 3. Real files & folders re-flagged Hidden+System Or moved into a hidden " " (single-space) folder 4. Decoy .lnk shortcut dropped per hidden item Same name, folder-like icon, target = relaunch payload + open real file 5. Victim clicks the fake shortcut Real file opens normally — nothing looks wrong 6a. Persists on the host PC Run/RunOnce registry keys, Startup folders, scheduled tasks 6b. Defensive tampering Disables Task Manager, cmd, regedit, Folder Options; hides file extensions 7. Spreads to every other removable drive plugged in Same hide-and-shortcut pattern is written to the new drive cycle repeats on next drive 8. Detection point .lnk shadowing a hidden same-name item, or a hidden " " folder

Figure 1 — The Shortcut Virus infection chain, from initial execution through persistence, defensive tampering, and spread to other removable drives. The two boxes in green mark the artifacts a heuristic scan should key on.

3. Remediation: what the cleaner actually does

Once a drive is confirmed infected, a thorough cleanup should run as a best-effort, multi-stage pass — each step independent and logged, so a failure in one step never blocks the rest:

  1. Reclaim System Volume Information (NTFS drives only). Elevate via UAC and run takeown.exe /F followed by icacls.exe ... /grant Everyone:(F) against that folder, in case the malware hid a payload copy there.
  2. Kill relaunch-host processes. Terminate wscript.exe, cscript.exe, cmd.exe, and powershell.exe (leave conhost.exe alone — it's console infrastructure, not something the payload itself runs as).
  3. Un-hide the hidden " " folder at the drive root, if present, by renaming it to RECOVERED so the user's files are immediately visible again.
  4. Walk the entire drive and strip the Hidden/System/ReadOnly attributes from every file and folder that has them, restoring the user's original content to a normal, visible state.
  5. Remove the autorun mechanism: if autorun.inf is present, its open=/shellexecute=/run= target (checked in that priority order, matching how Windows itself resolves it) is deleted first, then autorun.inf itself.
  6. Delete every remaining .lnk file on the drive. By this point any legitimate hidden item has already been restored to visible, so a .lnk still sitting on the drive is almost certainly one of the decoy shortcuts, not something the user created.
  7. Clear dropped relaunchers from %APPDATA%, %LOCALAPPDATA%, the user's Startup folder, and the All Users Startup folder — top-level .vbs/.bat/.exe files only.
  8. Clean the registry Run/RunOnce keys (HKCU always; HKLM too if the process is running elevated), removing any value whose data references wscript, cscript, a .vbs, or a .ps1 file.
  9. Remove malicious scheduled tasks (elevated only): every task definition under %WINDIR%\System32\Tasks is inspected, and any referencing wscript/cscript is deleted both from Task Scheduler and from disk.
  10. Restore the Group Policy restrictions the malware commonly sets — clearing DisableTaskMgr, DisableCMD, DisableRegistryTools, and NoFolderOptions in both HKLM (elevated) and HKCU, and resetting HideFileExt back to visible extensions.

An optional, more aggressive second pass is also available (off by default, confirmed separately by the user): it deletes every file anywhere on the drive with an extension commonly abused by this family — .vbs, .vbe, .scr, .com, .pif, .ps1, .bat, .cmd, .exe. This is intentionally not part of the default cleanup, since it is far more likely to also catch legitimate files — a user's own script, or an installed portable executable stored on the same drive.

4. Why this still matters

It would be easy to assume a threat this old and this "low-tech" has died out. In practice, it remains extremely common wherever USB drives circulate between untrusted machines — and it's a good reminder that not every prevalent infection needs a zero-day or a sophisticated dropper. Abusing hidden file attributes and a shortcut icon is enough, as long as the victim never turns on "show hidden files" and never looks twice at a familiar-looking folder icon.

From a defender's perspective, the interesting part isn't the payload — it's almost always a trivial VBScript relauncher — but the pattern of artifacts it leaves behind on the medium itself. That's exactly why this family is best detected heuristically by drive-level artifacts (shadowed .lnk/hidden-item pairs, the hidden " " folder) rather than by trying to hash-match an endless stream of near-identical script variants.

Indicators of Compromise (IOCs)

ArtifactLocationNotes
Hidden " " folderDrive rootSingle-space folder name, Hidden attribute
Decoy .lnk shortcutsDrive root (and subfolders in some variants)Same base name as a hidden file/folder
autorun.infDrive rootSupporting signal only; not malicious alone
Run/RunOnce registry valuesHKCU/HKLM ...\CurrentVersion\Run(Once)References wscript, cscript, .vbs, or .ps1
Dropped relauncher%APPDATA%, %LOCALAPPDATA%, Startup folders.vbs/.bat/.exe
Scheduled task%WINDIR%\System32\TasksReferences wscript/cscript
Policy tampering...\Policies\System, ...\Policies\ExplorerDisableTaskMgr, DisableCMD, DisableRegistryTools, NoFolderOptions

Recommendations for users

  • Enable "Show hidden files, folders, and drives" and disable "Hide extensions for known file types" in Explorer — both settings this malware family relies on staying off.
  • Never double-click an unfamiliar drive icon in "This PC"; open it via the address bar instead, which doesn't trigger autorun-style shell execution behaviors.
  • Scan removable media with an up-to-date antivirus before opening it, especially on shared or public computers.
  • If a drive shows 0 bytes free but looks empty, or a Recycle Bin-style shortcut appears where a folder used to be, treat it as a strong indicator of this infection and scan before opening anything.